The performance optimization settings and modules provided by Drupal core are intended to work for the broadest possible set of use cases. From an administrator's perspective they provide minimal configuration options, and are designed to just work by being enabled. But behind that simplicity are some powerful features that will help speed up any Drupal-powered application.
The core Dynamic Page Cache and Internal Page Cache modules are designed to provide a base cache setup for any site. These modules are responsible for the static page cache, dynamic page cache, and lazy loading optimizations.
For developers, Drupal provides a complete and well-designed Cache API. You can, and should, integrate it into your custom code. This integration includes defining the cacheability of any content your module outputs so that Drupal can be smart about how that affects how and when a page that incorporates the output can be cached -- as well as storing and retrieving the results of complex or long-running operations. The API also helps with setting appropriate HTTP headers for the responses Drupal generates for each request so that the user's browser and other layers in the stack can appropriately cache the output.
The entire system is flexible, and there are many contributed modules that can aid in making the default caching system even faster for specific use cases.
In this tutorial, we'll:
- Learn about the caching-related modules in Drupal core
- Review the Drupal core performance settings and recommended values
By the end of this tutorial you should be familiar with the Drupal core modules responsible for caching, their settings, and recommended values.
There's no magical set of right tools to use to monitor a Drupal site's performance and health. While thinking about performance monitoring, you need to optimize your approach depending on the number of applications you manage, their complexity, business needs, and the skill-set of your team. Based on these factors, you may choose to use one of the core or contributed modules, go with third-party solutions and services, or some combination of both.
Drupal core comes with a couple of modules that allow you to monitor the health and performance of the site including Syslog, Database Logging, and the status reports provided by the System module. There are also numerous community-contributed modules, a sampling of which we'll cover here.
In this tutorial, we'll:
- List some contributed modules that are commonly used for monitoring a Drupal site
- Provide an overview of what each module does
By the end of this tutorial you should be able to list a few contributed modules that might be useful for monitoring your Drupal application and define what each one does.
New Relic is a monitoring service that provides insights into your application stack from front-end performance to the server and infrastructure metrics. New Relic uses a combination of aggregating server logs, and pre-built (or custom) monitors to track the metrics that are most important to your application. The collected data can be organized into custom dashboards, and alerts can be set up and issued per customizable conditions.
In this tutorial, we'll:
- Learn about different New Relic modules and their purpose
- Review some default dashboard components and reports
- Discuss how to use the information in New Relic to understand the health of your Drupal application
By the end of this tutorial, you should understand the basics of using New Relic and the insights it offers to monitor and improve the performance of your Drupal site.
Performance profiling allows you to see an overview of how your Drupal application stacks up against your users' needs and business requirements. A good profile will help you understand where the performance bottlenecks are and where you should focus your efforts in order to achieve the best results when optimizing your application.
There are many profiling tools available to help you analyze your Drupal site's performance. Some are free -- like the browser’s built-in development tools, the Lighthouse Chrome extension, and XHProf. Some are paid -- like New Relic, Blackfire, and other profiling SaaS solutions.
In this tutorial we'll:
- Outline the general concepts and goals of performance profiling
- List some available profiling tools and their features
By the end of this tutorial you should be able to describe what performance profiling is, and list the tools commonly used to establish a performance profile for a Drupal site.
When your site is experiencing performance issues, one way to pinpoint the cause is to use profiling tools. Before you can fix the issue you have to be able to identify what's causing it. All profiling tools do roughly the same thing: they tell you what code is called during the request and how much time is spent executing it. This helps to identify the slowest code and dig deeper into the cause. Once the cause is determined you can start figuring out how to optimize the code.
For this tutorial, we’ll use New Relic as a profiling tool, but you can apply a similar methodology using the profiling tool of your choice.
In this tutorial, we'll:
- Learn how to identify and analyze slow transactions
- Look at common things to check for while profiling
- Cover some questions you should ask when looking at profiling data to help track down the slow code
By the end of this tutorial, you should know how to profile a Drupal site (specifically with New Relic) to find performance bottlenecks.
No one likes to wait for a slow site to load. Not me, not you, and definitely not search engines. And the effect of site load times on things like SEO, user bounce rates, purchase intent, and overall satisfaction are only going to become more pronounced over time.
Drupal is a modern web framework that is capable of serving millions of users. But every site is unique, and while Drupal tries hard to be fast out of the box, you'll need to develop a performance profile, caching strategy, and scaling plan that are specific to your use case in order to be truly blazing fast.
Drupal site performance depends on multiple components, from hardware setup and caching system configuration to contributed modules, front-end page weight, and CDNs. Experienced Drupal developers looking to optimize their applications know where to start looking for potential savings. They can manipulate settings and combinations of these components to achieve the desired results. Our goal with this set of tutorials is to help explain the process and provide you with the insight that comes with experience.
In this tutorial we'll:
- Introduce high-level performance concepts for Drupal that we'll then cover in more detail elsewhere
- Provide an overview of the main Drupal performance components.
By the end of this tutorial, you should understand what components around your Drupal application are responsible for site performance.
Often, there's an existing Drush command that does most of what you want, but needs just a few tweaks or enhancements to make it meet your project requirements. Maybe the existing core Drush command has the functionality but lacks some additional validation. Or maybe you need to add an additional option to perform some application-specific debugging logic for all commands in a group.
Drush hooks can be used to alter, extend, and enhance existing Drush commands.
In this tutorial we'll:
- Learn how to alter a Drush command with code in a custom module
- Declare a validation hook that alters the
user:password
command with additional password validation logic
By the end of this tutorial you should be able to alter a Drush command provided by Drush core or a contributed module with your own custom code.
Back-end developers, and Drupal site builders, often find themselves having to perform the same UI steps over and over again, like exporting configuration, importing configuration changes, running cron, processing a large queue of jobs, indexing items for Search API, and more. Performing these tasks with Drush saves time and reduces the number of clicks required.
Drush core contains commands to execute all the most common tasks. Many contributed modules provide their own Drush commands to make interaction with the module's features, easier, faster, and scriptable.
In this tutorial we'll:
- Learn about the Drush core commands for common tasks like interacting with queues, performing database backups, and importing/exporting configuration
- Demonstrate how to find the Drush commands provided by contributed modules in your project
By the end of this tutorial you'll learn some popular commands for common tasks that'll speed up your daily work.
Every Drupal site consists of many Drupal projects like modules and themes. Drush comes with a group of commands that aid in managing projects from the command line. These commands can check which modules are present in a site's codebase, report their security status, enable modules, and display metadata for modules and themes. All of these commands start with the pm
prefix, and are part of the project manager group.
Common use cases for the project manager commands include: quickly enabling/disabling modules via the CLI rather than performing numerous clicks in the UI, and as part of CI/CD process that lists (or maybe even automates) security updates.
In this tutorial we'll:
- List the available
pm
commands - Enable a module with Drush
- Uninstall a module with Drush
- Use Drush to check for security updates for modules, themes and PHP packages
By the end of this tutorial you'll have an understanding of the project manager commands that come with Drush, how to use them, and how to speed up common workflows and maintenance tasks.
Administration and maintenance of Drupal websites consists of many tasks that can both be performed via the command line, and automated, with Drush. Using Drush's site and environment administration commands you can run database updates, check an environment's status, clear (rebuild) the cache, perform Cron-related operations, and manage users. These tasks are repetitive, often require many steps in the UI, and may be tedious in the long run. Learning to execute them with Drush can save you time and allows for more automation of common tasks.
In this tutorial we'll:
- Use Drush to check a site's status
- Learn how to perform database updates with Drush
- Clear the Drupal cache with Drush
- Use Drush to execute Cron tasks for a Drupal site
- Learn how to use Drush to login to a site as any user, and manage existing users
By the end of this tutorial you'll be able to perform many common Drupal environment and administration tasks from the command line with Drush. We're not going to cover all of the environment management commands in this tutorial, just some of the more popular ones. We encourage you to explore further on your own.
What Is Drush?
FreeDrush, aka The Drupal Shell, is a command line utility and UNIX scripting interface for Drupal. It allows access to common Drupal features and tasks via the command line. It can help speed up common tasks for Drupal site builders, developers, and DevOps teams. Among other things, it makes it easier to integrate Drupal into CI/CD workflows.
In this tutorial we'll:
- Learn what Drush is and what can be done with Drush
- Install Drush
- Find a list of Drush commands
- Learn how to execute commands
By the end of this tutorial, you'll understand how to install and use Drush with your Drupal projects, navigate the list of its commands and run them. This is intended as an overview. Other tutorials will provide more detail about common commands and use-cases.
Make your custom Drush command more flexible by allowing users to pass command line arguments into it. For example, rather than hard-coding that the command lists users with a specific status, allow the desired status to be specified at run-time. This allows the command's logic to be more generic, and to return different results, or operate on different data, based on the provided parameters.
Parameters are variables that are passed from user input at the command line into the Drush command method. Typically, they are either single string values, or comma-delimited strings of values. Parameters are typically used to provide input for the command related to what the command should work on, in contrast to options, which are typically used to configure how the command works.
In this tutorial we'll:
- Declare parameters for a custom Drush command in its annotation
- Use the parameter input inside the custom Drush command method
By the end of this tutorial you should understand how to work with parameters inside custom Drush commands.
When you create a custom Drush command it might be useful to allow users to pass options (predefined values) that change the way a command works. You can think of options as being flags, or variables, that affect the command's internal logic. As an example, consider the Drush core user:login
command which by default returns a one-time login link for the root account. The command also accepts an optional --name
option which allows the internal logic to create a link for a specified user instead of only being able to create links for the root user. This makes the command useful in a wider variety of situations. Another common option is the --format
option which allows a user to specify that they want the command to return its output in a format (CSV, JSON, Table, etc.) other than the default.
Options are defined in the Drush command's annotation. Their values are passed as part of an associative array to the command method. Unlike parameters, options are not ordered, so you can specify them in any order, and they are called with two dashes like --my-option
. Options are always optional, not required, and can be set up to accept a value --name=John
or as a boolean flag without a value --translate
.
In this tutorial we'll:
- Declare options for a custom Drush command in its annotation
- Learn how to use these options inside the custom Drush command method
By the end of this tutorial you should be able to add options to your own custom Drush commands.
Drush commands are commonly run in the Drupal docroot, the directory where Drupal's files live. This is a relatively simple task on your local development environment. But if you're working on multiple sites and each of those sites has one or more remote environments that you connect to via SSH, workflows quickly become complicated. Creating and using Drush site aliases allows you to run Drush commands on any site, local or remote, that you have credentials to access, from any location on your computer that has access to a Drush executable.
Imagine you've got a Drupal project with dev, test, and live environments in the cloud somewhere. And you need to clear the cache on the dev environment. You could SSH to that environment, and execute drush cr
there. Or, after configuring a site alias you could do something like:
drush @provider.dev cr -y
And Drush will connect to the remote environment and clear the cache.
Site aliases allow bundling the configuration options (--uri
, --root
, etc.) for a specific remote server under an alias. This reduces the amount of typing required. Even more importantly, it helps teams agree on a common definition for environments like @dev
, @test
, and @live
by committing their configurations to version control.
In this tutorial we'll:
- Define what a Drush site alias is
- Understand the use case for aliases
- Learn how to configure and use Drush site aliases
By the end of this tutorial, you should understand how Drush site aliases work, how to create Drush site aliases, and how to use them in a Drush command.
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 annotated methods and metadata about each custom command. You'll create a drush.services.yml file that tells Drush where to find the command class and any services to inject into it. You'll also 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.
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.
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, annotation 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 annotation 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 annotations 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.