When you create a module for Drupal, it can be useful to provide default configuration. This can be settings for a form, the placement of a block, or something more complex like the default image styles provided by the Image module in core. A module can provide default configuration for simple configuration or configuration entities.

In this tutorial, we will cover:

• Possible locations for default configuration
• What happens with configuration when a module is installed or uninstalled
• Managing dependencies in configuration
• Where to find examples of default configuration

When working on configuration in a module, whether as part of a migration that uses Migrate Plus configuration entities, or while developing custom configuration entities, you'll often need to re-import the configuration stored in the .yml files of the modules config/install/ or config/optional/ directories. This is tricky though, because Drupal only reads in those default configuration settings when the module is first enabled. So any changes you make to those files after the module has been installed will not be reflected without these workarounds.

Knowing how to do this can improve the developer experience of adding (or debugging) the default configuration that's provided with a module. Or for anyone using Migrate Plus configuration entities as part of a migration.

In this tutorial we'll:

• Learn about the Configuration Development module
• Look at how you can use Drush to perform a partial configuration import
• Write an implementation of hook_uninstall() to remove a module's configuration when it's uninstalled

By the end of this tutorial you should be able to re-import the configuration provided by a module without having to uninstall and then reinstall the module.

Now that we have some default simple configuration stored in a settings YAML file, let's utilize it in a form that our site administrators can use to update those values. We'll make use of some services and methods in Drupal's Configuration API in order to retrieve, update, and save simple configuration values with a form.

While we've already created configuration entity forms for creating, editing, and deleting configuration entities, in this tutorial, you'll learn how to use configuration entity data in the context of a module's settings (configuration) form. We'll refactor the module settings form we created previously and replace the textfield form element with a dropdown select list of our custom video preset configuration entities we created in another tutorial.

By the end of this tutorial, you should be able to:

• Load configuration entities using an injected entity_type.manager service
• Update the module settings form to use a select list of configuration entities
• Save the settings form with the refactored field

In addition to using one of the existing generators, developers can write their own Drush generator commands. This can help speed up repetitive tasks and reduce the use of boilerplate code that is prone to human error.

Generators are provided through Drush's integration with the Drupal Code Generator project. Writing new generators isn't specific to Drush, though if you're creating generators for Drupal it is definitely easiest with Drush as a wrapper.

Similar to Drush commands, generators can be supplied by a Drupal module or declared globally. If you have a feature-specific functionality, it's best to ship your custom generator within the custom module. Otherwise, a global generator can be declared and used.

In this tutorial we'll:

• Explain the anatomy of a Drush generator
• Write a custom Drush generator for handling a site's development.services.yml file, and use it in a project

By the end of this tutorial you should understand how to create, or customize, a Drush code generator and use it in your project.

Code generators are great productivity boosters that allow generating scaffolds for common development tasks in Drupal. One of the most common use cases for generators is scaffolding the code required for a custom entity type. Custom entities require many files and complicated annotations in order to function properly. There is a lot of boilerplate code that is more-or-less the same for every entity type. Creating all the files is repetitive, time-consuming, and prone to human error. Generators can help automate this task and make creating your own custom entity types quicker.

In this tutorial we'll:

• Learn how to generate the code for a custom entity with Drush
• Learn about the options that generators provide for custom entities

By the end of this tutorial you should know how to generate custom entities with Drush.

The Drupal Entity API makes it easy to define new custom content entity types. And in most cases, whenever you want to store custom content in Drupal, you should use the Entity API instead of making CRUD queries directly to the database. This ensures your code is more consistent and allows you to take advantage of all the features of the Entity API, like access control, Views module integration, and automatic JSON:API support. As well as making it easier for others to extend your custom content by ensuring all the proper hooks and lifecycle events get invoked when new content items get created, updated, and deleted.

In this tutorial, we'll:

• Walk through the process of creating a custom content entity

By the end of this tutorial, you'll be able to create your own custom content entity contained in a module.

One of Drupal's strengths is its fine-grained permission and access system. The Entity API enables this by providing interfaces that let us define access control rules.

In this tutorial we'll:

• Look at how access control is handled, using Drupal core as an example.
• Demonstrate how to implement access control in a custom module.
• Learn about the hooks that allow developers to modify access control for entities provided by another module.

By the end of this tutorial you should have a better understanding of the entity access control system and how to work with it.

Entities are the core data structures that provide the building blocks for nearly everything on a Drupal site. Whether an entity provides configuration or content, it plays a key role in how Drupal stores and manages data. Entities provide a consistent, developer-friendly, and Drupal-aware abstraction to data stored in the database.

In this tutorial, we will:

• Explore how different entity types relate.
• Compare configuration and content entities to understand the purpose and implementation of both.
• Review how (at a high level) an entity type is defined.

By the end of this tutorial, you'll understand the relationship between configuration and content entities and be able to identify the parts of code that define a custom entity type.

Often when building a site in Drupal you'll find yourself wanting to display a list of nodes, or find entities created by a particular author, or locate some content based on a particular set of criteria. Rather than querying the database directly, Drupal provides a helper class, EntityQuery, to make things a bit easier. The EntityQuery class will probably look very familiar to you if you're familiar with the Database API, or the EntityFieldQuery class in Drupal 7.

In this tutorial we'll:

• Go through several examples of using EntityQuery to find subsets of content.
• Demonstrate how to iterate over the results of an EntityQuery query.

By the end of this tutorial, you should understand how to use entity queries to create custom sets of data from entities.

When learning Drupal development, it won't be long before you encounter the word "entity" and the Entity API. But what are entities in Drupal? How can you use them to build your site? When should you use the Entity API?

This tutorial will explain Drupal's Entity system from a high level. We'll look at:

• The main problems the Entity system solves
• Key terms you should know
• Key concepts we'll explore as we dive into Drupal's Entity API

By the end of this tutorial, you should be able to explain the problems that the Entity API solves, and when you should use it in your own code.

Drupal includes the Symfony Validator component, and provides an Entity Validation API to assist in validating the values of fields on an entity. By using the Entity Validation API you can ensure that you're validation logic is applied to Entity CRUD operations regardless of how they are triggered. Whether editing an Entity via a Form API form, or creating a new Entity via the REST API, the same validation code will be used.

Using the Entity Validation API in order to validate the value of a field on an entity requires:

• Defining (or choosing) a constraint plugin
• Defining (or choosing) a validation plugin
• Adding the constraint to the field definition

In this tutorial, we'll look at how this Validation API works and how it can be used in custom code to ensure our entities have properly constructed values. We'll look at how this validation works in Drupal core and how we can add our own additional constraints. We'll also see how to work with the error messages returned from the validator when our entity doesn't pass validation.

Drupal's Entity system provides several hooks that allow custom code to interact with various parts of the entity life cycle.

In this tutorial we'll:

• Examine the available hooks
• Learn how to make use of them to act on several different types of operations on individual entities

By the end if this tutorial you should have a better understanding of the hooks available to developers who want to respond to entity lifecycle operations and how to use them to customize the way specific entity types work.

Containers are sandboxed applications that can be run anywhere, no matter the underlying host OS. Docker containers are quite different from VMs in a number of ways that need to be understood before we can use them to develop Drupal sites.

In this tutorial, we'll:

• Define a container
• Explain how a container is a more limited environment than a VM

Planning for a migration is essential. In our collective experience we've never once seen someone sit down and execute a migration flawlessly on their first attempt. Migrations involve preparing and analyzing your source data, building a new website that data can be migrated into, and lots of testing, rolling back, and testing again, in order to get everything right. By the end of this tutorial you should be ready to start planning for your own Drupal migration project, and have a better understanding of the challenges of migrating from one system to another.