The Drush executable can be configured through the use of YAML configuration files and environment variables. This configuration can help cut down on typing lengthy frequently-used commands. You can tell Drush to look for command files in project-specific locations. Configuration can also set the value(s) of a specific command's options, instead of having to type them at the command line every time.

In this tutorial we'll:

• Explore different Drush configuration options
• Learn how to configure Drush for your project

By the end of this tutorial, you'll know how to provide project specific, and global, configuration that helps customize Drush and improve your own efficiency.

Creating a custom Drush command requires creating a PHP class that Drush can find with methods that have PHP attributes that provide metadata about each custom command. You'll use an autowire trait to inject any services into it. You'll also optionally modify the project's composer.json to tell Drush what versions of Drush the command is compatible with.

Custom Drush commands are a great way to expose your custom module's features to help automate these tasks and allow users to perform them as background processes. They can also provide a more efficient way to execute PHP code that takes a long time and is prone to timing out when run via the web server.

Depending on your use-case it can also be more efficient to create a custom Drush command to execute your logic instead of coding a complete UI. For example, if all the command needs to do is generate a CSV list it might take less effort to write a Drush command and pipe the output to a file than to create a UI that generates a file and prompts the user to download it.

In this tutorial we'll:

• Declare a new custom Drush command inside a custom module
• Make our custom Drush command output a list of all the blocked users on the site
• Verify our new command is working

By the end of this tutorial you should understand how to create a custom Drush command that returns a list of blocked users.

Developers can implement the Drush Command API to write their own custom Drush commands. This allows you to include Drush commands with your modules to allow the module's features to be used via the CLI. You can also create project-specific Drush commands that help with the development, deployment, and maintenance of your particular application.

We've written Drush commands to help generate reports, make it easier for new team members to get up and running, compile custom theme assets, and more. Any time we need to write PHP code that interacts with our Drupal site where we're worried the code might time out because it takes too long to execute we'll reach for Drush. Custom Drush commands are also useful to combine background processes that can be executed on cron, such as nightly imports, data synchronization, bulk database manipulation, custom queues processing, and so much more.

In this tutorial we'll:

• Learn about different types of custom Drush commands
• Review the anatomy of a Drush command
• See how the Drush bootstrap process relates to commands

By the end of this tutorial, you'll be able to identify the parts of a custom Drush command and start writing your own.

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.

One of the problems that Drush solves for developers is the automation and optimization of routine tasks. Drush commands attempt to speed up workflows and tasks that developers and site maintainers would otherwise have to do manually through the UI, or run one-by-one via the command line. One of those tasks is the process of deploying changes to a Drupal application from one environment to another.

The typical Drupal deployment process consists of repeatable steps such as importing configuration changes, applying database updates, and clearing the cache. Drush comes with the handy drush deploy command that allows you to automate the execution of all of these tasks post code deployment.

In this tutorial we'll:

• Learn about the drush deploy command
• Discuss when you would use the deploy command

By the end of this tutorial you'll know how to use the drush deploy command in conjunction with other useful deployment-related commands to help automate the task of deploying changes to a Drupal site's configuration and code.

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.

Some Drush commands return a lot of information -- lists of modules, generators, and status reports, for example. It might be hard to find a property you need in the small command window output. Luckily, the output of Drush commands can be piped to other commands, used as a source for imports, settings for CI, and other DevOps tasks.

In order to accommodate all these different use cases, Drush comes with a formatting system that allows you to format and filter output to meet your needs. This system allows to you specify what fields you want returned when the output contains more than one field. It also allows Drush command output to be formatted as JSON, XML, raw PHP, a table, and more.

In this tutorial we'll:

• Learn how to specify the output format -- and what formats are available
• Limit the fields that are returned in a report
• Learn to filter the output to only the data we're interested in

By the end of this tutorial you'll know how to format a Drush command's output to fit your needs.

If you want to change the way an existing Drush command works, you use hooks. Hooks are useful for altering command parameters, options, attributes data, and adding custom logic during particular stages of the command execution process. Drush hooks are conceptually similar to Drupal hooks.

Hooks are methods on a Drush command class with an attribute indicating what hook is being implemented, and thus when the code should be invoked. The code in the methods is executed during specific stages of the command cycle. Developers can use core hooks -- predefined methods that come with Drush core -- or declare a custom hook that other commands can use.

In this tutorial we'll:

• Explore the different core Drush hooks
• Learn which hooks are called at what stage of the command cycle
• View example hook attributes and method implementations

By the end of this tutorial you'll know what types of core hooks are available to you and when they are called.

Adding logging and error handling are an important part of authoring Drush commands. Logs allow developers to get timely feedback from a command and inform users about potential alterations and flags, events to monitor, and the progress of long-running commands. Correct error handling allows for clean exits, meaningful error descriptions, and provides a path forward for developers to fix the errors and accomplish their goals.

In this tutorial we'll:

• Explore the different types of logging messages Drush commands can output
• Learn how to handle errors from within a Drush command

By the end of this tutorial you'll know what types of log messages you can use; how to log success messages, errors, or debug statements from a custom Drush command; and how to handle errors and exceptions.

When the logic of a command depends on user input, it's useful to set up an interactive questionnaire inside the command code. This allows you to provide the user with more context about the input they're providing, and ensure that you collect all the necessary values. This is especially useful when the command uses a pre-defined list of options and the values require memorization. An example of this is the drush cache-clear command that comes with Drush core. It requires an argument indicating which cache to clear, which you can specify at the command line; however, if you invoke the command with no arguments it will present you with a list of cache bins to choose from and a UI for selecting one.

Drush 9+ can access the Input/Output (I/O) object via the $this->io() method. This object -- an instance of \Drush\Style\DrushStyle -- holds information about user-provided input, and utilities for manipulating that input. To ask a user a question, use an io() object in the command callback method. It can take over the execution flow of the command as needed to stop and gather additional input. The I/O system has various methods for asking confirmation or choice questions such as confirm() and select().

In addition to prompting for input, the I/O object can be used to provide other styling to the command, like progress bars.

In this tutorial we'll:

• Learn how to prompt the user for additional input
• Process the user's answer as part of the command execution flow

By the end of this tutorial you should understand how to prompt a user for additional input for a custom Drush command.

While Drush empowers all Drupal users with its commands, it's even more powerful when used in combination with scripting solutions such as Composer and Bash. Scripts can be used to power post-deployment tasks like importing new configuration or clearing the cache, as part of CI processes to sync a database from one environment to another, to run background processes on the server such as imports and migrations, search indexing, running cron, and much more. If you want to write Bash (or any other scripts) that interact with a Drupal site, then Drush is the tool for you.

In this tutorial we'll:

• Learn how to use Drush commands within Composer and Bash scripts
• Learn how to chain multiple Drush commands together in a script

By the end of this tutorial you'll know how to use Drush as part of a script that automates common or tedious tasks.

When you manage many Drupal websites, you may perform repetitive tasks that are common across all of your sites. In our experience, this usually relates to having a personal preference for how certain tasks are accomplished. For example, maybe you like to make backups of the database and files in a specific way before testing upgrades, or you have a set of scripts for running scans of core web vitals. Although these tasks can be bundled into a custom module, it could be useful to create a site-wide Drush command instead. Site-wide commands can be installed with Composer, managed in a separate Git repository, and act as a project dependency. This way they are easy to maintain through a separate upstream. Changes to this code will be reflected on all the sites where it's used.

In this tutorial we'll:

• Declare a custom site-wide Drush command
• Demonstrate how to use Composer to manage a package that contains a Drush command

By the end of this tutorial you'll be able to create a site-wide Drush command and manage the code with Git and Composer.

Docker often seems like an impenetrable product. Is it a VM system? A suite of development tools? A clustering product? A software distribution facility? When the answer is "yes" to each of these, it only becomes more confusing. For the Drupal developer, Docker is a way to provide a local development environment to run web server software.

In this tutorial, we'll:

• Define the terms hypervisor, virtual machine (VM), and containers
• List the advantages of containers over VMs
• List the advantages of Docker for Drupal developers

Installing Docker is easy, but there are some details you may want to consider before you download and run the installer.

In this tutorial, we'll focus on:

• Why Linux is Docker’s native environment
• The difference between Docker edge vs. Docker stable
• Why Docker for non-Linux requires a VM

Now that we know what Docker is, what containers are, and how to install Docker, just how do we use containers? While graphical user interfaces (GUI) exist for Docker, the primary way to interact with it is via the command line.

In this tutorial, we'll:

• Start Docker for Mac or Docker for Windows
• Use the docker run command to run a container interactively
• Break down the arguments of the docker run command

When we use docker run to start a container, we download a compressed, ready-to-use container called an image. Images make containers easy to share via a registry like Docker Hub, but also affect how file storage works when using containers.

In this tutorial, we'll:

• Discuss how file storage works in Docker containers
• Describe images, base images, and the scratch image
• Identify layers and show how layers make up Docker's filesystem

Running a container interactively can be useful, but often it's not what we really need. A web server stack is made up of several components such as the Linux OS, the Apache web server, a PHP runtime, and a database such as MySQL. Collectively, we call this a LAMP stack. If we were to run these in Docker with what we now know, we'd have to keep open several terminal windows!

Obviously that's not what we want to do. Instead, we want to run the containers in the background. That way, we can use them like we would any web server. Fortunately, Docker makes running and managing a container in the a background easy with just a few commands.

In this tutorial, we'll:

• Start a container in the background
• Use docker ps to list running Docker containers
• Use docker run to enter a container running in the background
• Use docker kill to stop a container running in the background

Often we don't want to run just one container at a time, but a set of containers that act together to provide a unit of functionality. Yet, docker run only starts one container at a time, with one command in each container at a time.

Docker Compose lets us overcome this limitation by allowing us to define a single file that describes multiple containers, their relationship to each other, and utilities to manage that set of containers as a single unit.

In this tutorial, we'll:

• Introduce Docker Compose
• Run multiple containers at once using Docker Compose
• Identify the purpose of docker-compose.yml
• Learn what resources a set of containers share

Docker Compose allows us to manage several related containers as a single group. We define container sets by creating a creating the Compose file, docker-compose.yml.

In this tutorial, we'll:

• Create the basic structure of the Compose file
• Define a container set using off-the-shelf containers
• Describe where to place it in your project
• See how directory names are significant in Compose

Once we have the docker-compose.yml file created, we can use it to work with a set of containers. Instead of the docker command, Docker Compose has its own command to work with multiple containers at once: docker-compose.

In this tutorial, we'll:

• Cover the basic usage of the Compose command
• Describe how to start, stop, and list running container sets