
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.
To follow along with the rest of the migration tutorials you'll want to make sure you understand the following concepts and terms as they relate to Drupal migrations.
In this tutorial, we'll take look at the basic components of a migration and familiarize ourselves with some of the concepts and terminology needed to understand how the system works. We'll cover:
- What is a migration?
- Migration templates
- The extract, transform, load process
- Destinations and sources
- Additional Drupalisms
By the end of this tutorial you should be able to identify the various components that a migration is composed of, and explain at a basic level what each is responsible for.
Views API in Drupal
CourseAt its core, Views is a query generator. It provides a way for site builders and developers to construct queries for Drupal content using an intuitive user interface. The UI allows you to configure the fields, filters, sorting, and relationships in the generated query using common conditions. In most cases, this is sufficient. However, there are situations where you need to dynamically alter the constructed query using hook_views_query_alter()
prior to its execution.
One example use case is adding sort parameters to a search view if no search terms have been entered. You can use hook_views_query_alter()
to check if a search term was entered. If so, sort the result by relevance; and if there are no search terms, sort the results by date. Or maybe you need to dynamically set the value of a filter condition based on a calculation performed by your custom code.
Using hook_views_query_alter()
in a custom module, you can alter the query that is generated by a view before the query is performed. In most cases this alters the SQL query used. This same technique will work regardless of the storage system Views is querying.
In this tutorial we'll:
- Learn how to alter a view's query using the
hook_views_query_alter()
hook in Drupal - Use
hook_views_query_alter()
to dynamically add a new sort condition that could not be achieved using the UI
By the end of this tutorial you should know how to alter the database query used to retrieve the results for a view.
In this tutorial, we'll walk through the process of adding and configuring filters and adding a filter group.
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.
When you create a custom form for Drupal and your module defines the form controller, the best way to handle processing of submitted data is via the submitForm()
method of your controller. This method is called automatically by the Form API during the process of handling a user-submitted form. It can be used to save incoming data to the database, trigger a workflow based on user input, and instruct the Form API where to send the user after form processing has completed.
In this tutorial we'll:
- Demonstrate how to add a
submitForm()
method to a form controller class - Access the value(s) of form input elements via the
$form_state
object - Set a redirect after performing processing in a form submission handler
By the end of this tutorial you should know how to access the values of a submitted form, and how to write custom processing code inside of the submitForm()
method of a form controller.
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 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
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.
Happy New Year! The Module Development series is wrapping up by working our way through another major API in Drupal, the database layer. We have five videos to walk you through it.
- An overview of the database layer in Drupal 7 is an excerpt from our Overview of Drupal 7 roundtable discussion, led by Angie Byron, the Drupal 7 co-maintainer.
This week we're continuing PHP for Beginners Part 3 , which is working with databases in PHP. Last week, we started off my covering the fundamentals of SQL and working with a MySQL database. Today we hook this up with the PHP site we're building. Additionally, we have a bonnus lesson YAML.
Getting Drupal to run in Docker requires a lot of moving parts. After installing Docker and Docker Compose, we need to select a collection of containers from Docker Hub and create a new docker-compose.yml file. Once we have environment variables and volumes configured, this only gives us the capability of running a Drupal site in Docker.
What if we already have a Drupal site we want to develop using Docker? In this tutorial, we'll show how to modify an existing project to minimize the setup time necessary for switching to a Docker-based environment.
In this tutorial, we'll:
- Describe the best practices for project organization.
- Use an environment file to configure containers.
- Add a Docker-specific settings.php file.
January Content Update
Blog postHappy 2015, members! We’re welcoming this new year with new Drupal tutorials. Here’s what you can expect over the next few weeks.
If you want to modify the Drupal-to-Drupal migrations created by Migrate Upgrade you'll need to export the Migrate Plus configuration entities, convert the ones you want to customize to standard migration .yml files, and put them into a custom module. Then, you can make edits the YAML definition of the migration, and keep your customizations in Git.
We recommend creating a new module to house the code that makes up your custom Drupal-to-Drupal migration.
In this tutorial we'll:
- Create a new module
- Export the migration configuration entities generated by
drush migrate-upgrade
as YAML files - Copy the files that represent the migrations we're interested in into our new module
- Customize the copied files
By the end of this tutorial you should have a new module that contains the starting migration YAML files for your custom migration.
Dependency injection is an object-oriented programming design pattern widely used in Drupal. Instead of a class creating an object directly, dependency injection provides services or objects to a class externally, and is an example of the Inversion of Control principle.
In this tutorial, we'll:
- Explain dependency injection in the context of Drupal.
- Take a look at examples of constructor and setter injection in Drupal code.
By the end of this tutorial, you'll recognize dependency injection patterns and understand how it's used in Drupal module development.
The individual items that make up the content of a page impact the cacheability of that page. In order for Drupal's cache and external caches to better understand how the content varies on a page, module developers use the #cache
render element property. The #cache
property defines cacheability metadata for individual elements in a render array.
Additionally, these Render API elements can become fairly complex. The calculation of what the final HTML output should look like often involves looking up content in the database, checking multiple conditions, maybe querying an external API, and various other tasks. This can cause turning a render array into HTML to become quite expensive. In order to speed up this process, the Render API will cache the generated HTML for each element and reuse it on future requests whenever possible -- but only if you tell it to do so.
In this tutorial, we'll look at:
- How render caching impacts the performance of a page
- Defining the cacheability of an item with cache tags, cache contexts, and cache max-age
- Examples of using the
#cache
property in a render array
By the end of this tutorial you should know how, and when, to use the #cache
property when defining render arrays.
Creating a container set to support Drupal development requires some specialized knowledge. Now that we understand containers, images, how to use Docker Compose (docker-compose
), and how to select images on Docker Hub, we're ready to build a container set to support Drupal development.
In this tutorial, we'll:
- Select images of software that we'll need to run Drupal
- Create a new Compose file
- Configure bind volumes and environment variables to support the site
- Test the configuration
See Dockerize an Existing Project if you already have Drupal installed.
Why Solr?
FreeDrupal has long provided a built-in search mechanism, so why do we need anything more? In this tutorial, we introduce Apache Solr, a free and open source search service that has several advantages and features beyond Drupal’s built-in search.
In this tutorial, we'll:
- Define Apache Solr
- Identify Apache Lucene, the legacy name for Solr
- List key features of Solr
- Identify the advantages of Solr compared to Drupal search