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.

The Drupal plugin system allows a particular module or subsystem to provide functionality in an extensible, object-oriented way. The controlling module defines the basic framework (interface) for the functionality, and other modules can create plugins (implementing the interface) with particular behaviors. Plugins are grouped into plugin types. Each plugin type is managed by a plugin manager service, which uses a plugin discovery method to discover provided plugins of that type and instantiate them using a plugin factory.

The system aims to make it easy for developers to allow for management of these components via the user interface, giving more flexibility and control to site administrators.

In this tutorial we'll take a high-level look at the problem the Plugin API is solving and provide a starting point for diving deeper into the various components that make up the Plugin API.

The #access property can be used with any element in a render array, including form elements, to control the visibility of that element and its children. This is an effective way to limit access to specific parts of a page's content to only those users with the required permissions, and to show or hide material based on other conditional logic.

In this tutorial we'll:

• Review the #access Render API property
• Demonstrate using the #access property to show/hide a field on a node depending on the current user's permissions

By the end of this tutorial you should be able to limit access to any element on the page via logic that returns a Boolean value.

We often need to add code to an alter hook or preprocess function that adds additional HTML attributes to items in a render array. Maybe you're developing a module that adds conditional classes to elements on the page under certain circumstances. Or perhaps your theme needs to add some data attributes to certain links, or form elements, in order to enable some custom JavaScript functionality.

Adding HTML attributes like class, id, or data-* to render array elements involves:

• Adding the desired values to the element in a render array as an array of key/value pairs
• Converting the values in the render array to an Attribute object
• Outputting the Attribute object inside a template file

In this tutorial, we'll cover all of these steps. By the end of this tutorial, you should be able to add new HTML attributes to elements in a render array and discover which property those values should be added to, depending on the element in question.

Some Render API properties, like #pre_render, #element_validate, and #lazy_builder are considered callable. Rather than receiving a static value, they contain a pointer to code that should be called at a specific time during the process of rendering a render element. Callbacks are used in some cases to return a value that can be substituted into the render array, and in other cases given the opportunity to manipulate the current element in the array directly.

In this tutorial, we'll:

• Look at what callbacks are
• List some common callback properties
• Show various ways that callback code can be defined
• Discuss how to choose which method to use

By the end of this tutorial, you should be able to define an appropriate value for any Render API property that expects a callback, and define the logic that is executed when the callback is triggered.