When defining a new FormElement plugin, or if your constraints are only relevant for a single element, you can use the #element_validate property of an individual element to specify additional validation callbacks.

In this tutorial we'll:

• Add an #element_validate callback to a single element in a form to perform validation of just that element.

By the end of this tutorial you should know how to add #element_validate callbacks to any form element in Drupal.

How do you figure out what hooks are available to implement? How do you know which hook to implement to accomplish a task?

The list of hooks that are available to implement in your custom Drupal module varies depending on the modules enabled for a site. Each module can optionally invoke new hooks. There are also some hooks invoked by Drupal core subsystems like Form API that are always present. This can make it a little bit tricky sometimes to figure out what hooks are available, and which one to implement.

In this tutorial we'll look at:

• Different ways to get a list of available hooks
• Where to find the documentation for a hook so you can know if it's the one you want to implement

By the end of this tutorial you should be able to browse a list of hooks and their related documentation.

Hooks allow module developers to execute custom code at key moments during Drupal's request processing life cycle. They can be used to react to actions or conditions, alter forms and existing configuration, and extend Drupal in various ways. Knowing how to implement a hook is an essential skill for any Drupal developer.

In this tutorial we'll walk through the process of locating the documentation for a specific hook, and then implementing it. All hooks are implemented in the same way, so once you know how to implement one, you'll be able to implement any.

As a module developer you should define and invoke new hooks in your module in order to allow other developers -- or even future you -- to extend your module's functionality without hacking your module's code. This requires:

• Creating a new, unique, name for your hook
• Providing documentation for your hook
• Invoking the hook at critical points in your code

By the end of this tutorial you should have a better idea of when to define a new hook and know how to invoke a hook from your code.

Hooks allow modules to alter and extend the behavior of Drupal core, or another module. They are one of the various ways that code components in Drupal can communicate with one another. Using hooks a module developer can change how core or another module works -- without changing the existing code. As a Drupal developer, understanding how to implement and invoke hooks is essential.

In this tutorial we'll:

• Define what hooks are and the types of hooks that exist
• Understand the use case for hooks

In this tutorial, we'll examine one the first files you'll need in order to create a Drupal module: the info file. Each module is required to have a MODULE.info.yml file to help Drupal identify that a bundle of code is a unique module. This specially-formatted YAML file tells Drupal about the module and provides other useful metadata. In this tutorial, we'll walk through both required and optional information you put in a module's info file.

Modules can provide action links to make common operations more readily available within a particular context. For example, a site administrator visiting the content management page may be interested in adding content. If you've ever noticed the Add content button on this page, that's an example of an action link. In this tutorial we'll take a look at how custom modules can provide these action links to make it easier for users to interact with our site.

Contextual links provide yet another method for Drupal module developers to add helpful links for site administrators to quickly navigate to commonly used tasks. In this tutorial we'll learn how to implement and render contextual links from a custom module. We will also look at a pair of alter hooks that can be used to tweak existing contextual links.

Local task links are the tabs you see when logged in as an administrator viewing a node on a Drupal site. In this tutorial we'll take a look at how local tasks are added within a custom module. We'll also see how to alter local tasks provided by other modules via hook_menu_local_tasks_alter().

In this tutorial we will learn how to add menu links using a custom Drupal module. We will also look at the options available for configuring our new menu link. Lastly, we'll learn about using hook_menu_links_discovered_alter() that can be used to add new menu links, or alter the behavior of existing ones.

Drupal provides module developers several different methods for creating the different types of links we see on a typical page. In this tutorial we'll see how these different types of links relate to each other, and when you might want to make use of them.

In this tutorial we'll provide an overview of the following concepts:

• Menu links
• Action links
• Local tasks
• Contextual links

If you've ever built or administered a Drupal site, the permissions page (/admin/people/permissions) is probably quite familiar.

If you're new to module development, you may wonder where these permissions come from, and how you can specify your own permissions. In this tutorial we'll answer those questions.

First, we'll look at how to define permissions from within a custom module. We'll examine techniques that enable you to provide specific (static) permissions as well as dynamic permissions, which depend on another piece of data, such as the name of a content type. By the end of this tutorial you will understand how to add both static and dynamic permissions to a custom module.

Knowing how to define a new plugin type will allow you to write modules that are more extensible, and more configurable. In doing so you'll learn more about best practices in decoupling code within your module, and get an in-depth look at how the plugin system works. Even if you're not defining a new plugin type in your own module, understanding how the system works will give you more insight into how many parts of Drupal work. This is essential knowledge for anyone developing modules for Drupal.

By the end of this tutorial you should be able to determine if defining a new plugin type is the right solution to your problem, and then understand the steps involved in doing so.

Knowing which plugin types exist and the use case for each is important when it comes to writing modules that extend Drupal's existing functionality. If you want to add additional functionality, you need to first know which plugin type provides that functionality.

In this tutorial, we'll list some of the more commonly-used plugin types and their use case, show where you can find a more complete list of plugin types provided by core, and provide several methods for discovering existing plugins in your Drupal codebase.

Drupal uses plugins for a lot of different scenarios. Blocks, field types, menu items, breakpoints, and migrations are all examples of plugins. There are a couple of different types of plugins. Before you can create a new plugin of any type, you'll need to figure out where the plugin implementation and its metadata should live in the code base, so that the plugin manager can find plugins, and examine what functionality instances of the plugin type are expected to provide.

In this tutorial we'll:

• Demonstrate how to figure out what type of plugin you're dealing with.
• Point to additional resources showing how to implement the specific plugin type once it has been determined.

By the end of this tutorial you should have a better understanding of how to figure out the details required to implement any given plugin type.

Plugin derivatives allow a single plugin to dynamically generate multiple plugin instances based on configuration or other data. This is useful for situations where user-entered data, or other dynamic configuration, might have an impact on available plugins. Or, put another way, any time you need to be able to dynamically generate plugin definitions.

In this tutorial we'll:

• Define what plugin derivatives are
• Understand the use case for derivatives
• Examine how core uses derivatives in order to demonstrate how you could write your own plugin deriver class

In order for a plugin manager to locate instances of individual plugins within the Drupal code base it needs to know where to look, and how to interpret the data that it finds. This process is called plugin discovery and can be accomplished in several ways.

In this tutorial, we'll look at what plugin discovery is doing at a high level, and then talk about the plugin discovery methods you can choose from when defining a new plugin type.

Learn how the Plugin API takes a given plugin ID and uses it to instantiate and return a fully configured plugin object. In this tutorial we'll look at:

• What factories are, and the role they serve in the Plugin API
• The factories available in core
• Using mappers to dynamically load a plugin when you don't know the ID of the specific plugin you need.

A plugin manager is responsible for both the definition of a new plugin type, and for listing and instantiating instances of plugins of the defined type.

In this tutorial we'll:

• Define what a plugin manager is.
• Create a list of all plugins of a specific type.
• Load and instantiate specific plugin instances, so we can use them in our code.

The term plugin type is used as a way to provide a generic name for all plugins managed by the same plugin manager. Example plugin types include block, field widget, and image effect. A plugin type doesn't consist of any code that provides specific functionality. Instead, it provides a way to refer to the system and it describes the central purpose of all plugins of that type.

In this tutorial, we'll cover what the term plugin type means and how it is used when talking about Drupal's plugin system. By the end of this tutorial, you'll understand what a plugin type is and be ready to learn how to define a plugin type in a module.