One of the primary ways that modules extend Drupal is by adding dynamic pages with content generated by application-specific logic. This tutorial looks at Drupal's process of handling a user's request and transforming it into a complete web page. We'll answer questions like:
- How does Drupal use Symfony's HttpKernel to process requests?
- How do user-configured blocks and the theme layer contribute to the page's content and appearance?
- What is the role of routes, controllers, and responses in this process?
In this tutorial, we'll:
- Follow the journey of a user request from URL to an HTML response in Drupal.
- Define the role of routes, controllers, and responses in Drupal's request handling.
- See how blocks and the theme layer contribute to the final output of a Drupal page.
By the end of this tutorial, you should be able to describe Drupal's request flow, understand the interaction of its key components in building a page, and appreciate the modular architecture that drives Drupal's flexibility.
Theme developers often need to add or remove classes and other attributes from an HTML tag. Template files handle this with a special Attributes object that contains the attributes and their values, as well as a handful of powerful methods to help manage these attributes.
In this tutorial we’ll cover:
- Adding/removing classes from elements in a Twig template
- The attributes object
- Examples of common tasks using various helper methods on the attributes object
One important aspect of theme administration is the configuration of global and theme-specific settings. In this tutorial, you will learn where theme settings are configured in Drupal's administrative interface, the difference between global and theme-specific settings, and what each global setting refers to on a base installation of Drupal with a custom theme installed.
Drupal User Guide
GuideCustom themes in Drupal must be configured to inherit settings, templates, and other assets from a parent theme. Which base theme you use is configurable. This allows theme developers to use a different set of markup as the starting point for their theme, organize various theme assets into a more maintainable structure, and more. All of this is made possible because of how Drupal's theme layer uses a chain of inheritance when assembling all the parts of a theme.
Base themes are also a powerful way to encapsulate standards and best practices into a reusable code base. You'll find dozens of contributed base themes on Drupal.org that can serve as a great starting point, especially if you're planning to work with an existing design framework like Bootstrap or Susy Grids. Or if you want to leverage modern JavaScript bundling without setting up Webpack on your own.
In this tutorial we'll:
- Learn what base themes and subthemes are
- Look at a few examples of template inheritance and how that works
- Discuss some use cases for theme inheritance
By the end of this tutorial you'll know how to declare the base theme that your theme builds upon.
In Twig, you can modify variables using functions or filters. Twig has a bunch of built-in functions and filters. Drupal extends Twig to provide a few handy Drupal-specific functions and filters as well.
In this tutorial, we'll look at:
- What are functions and filters?
- How to use functions and filters in Twig
- Detailed information about the Drupal-specific functions and filters and their use case
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.
Making Drupal fast by default implies having caching layers and CSS and JavaScript aggregation utilities enabled out-of-the-box. As a theme developer this can be annoying, because you must clear these various caches in order to preview any changes. In addition, inspecting variables with debugging tools often produces PHP errors. We'll make some recommendations for PHP settings on your local environment that can prevent these errors from happening so often.
By the end of this tutorial, you should be able to:
- Set up your local Drupal site for theme development
- Prepare your local development environment for working on and debugging themes
Template files are used by modules when they need to add custom HTML to the content they output. The most common example is wrapping your output in one or more <div>
tags to give it additional structure and context. Using custom template files in a Drupal module requires defining a new theme hook, creating the template file, an associating the appropriate data with the template file via a render array.
In this tutorial, we'll:
- Learn how to add a custom Twig template file to a module.
- Update the
WeatherPage
controller to use the new template file.
By the end of this tutorial you should be able to create and use custom template files in a module.
The Views module is a query generator and render engine in Drupal core. It's typically used to create and output collections of items such as Drupal content entities. But it can also aggregate users, blocks, log records, and more. The output can be rendered many ways, including as a list, a grid, or an RSS feed. Views is commonly used in Drupal to create pages, blocks and other types of displays.
Through the Views API developers can expose new data to Views, add new configuration options, create new output plugins, field formatters, sort handlers, filter handlers, and more. By creating these customizations as extensions of Views instead of as stand alone queries, or hard-coded lists, you can empower site administrators to mix and match your customizations with the existing feature set in any way they might need.
In this tutorial we'll:
- Get a high level overview of the Views API.
- Discuss the functional parts of the Views API such as hooks, plugins, and data types.
- Learn how to use the Views API in your project.
By the end of this tutorial you'll have a solid understanding of the parts of the Views API and some guidance on which to use for your goals.
Layout Builder is one of many different approaches to handling editorial layouts in Drupal. Now that it's stable, and part of Drupal core, we expect to see it become the dominant approach over time. However, as with most things in Drupal, there are multiple ways to solve the problem of creating component based flexible layouts that can be administered via the user interface.
It's a good idea to understand the different approaches and know what's available.
When it comes to component based design and ability to construct flexible layouts, it is important to understand the benefits and risks of the most popular techniques: Paragraphs, Bricks, entities and view modes, and Layout Builder. Understanding which approach fits the needs of your project best can be critical for its success in the future.
In this tutorial we'll look at some common approaches to administering layouts in a way that gives content editors controls including:
- Drupal core's Layout Builder
- Using core's entity reference fields and view modes
- The contributed Paragraphs module
- The contributed Bricks module
By the end of this tutorial you should have a broad overview of the different popular approaches to creating editor-controlled layouts.
Before you begin a Drupal 6 or 7 (source) to Drupal 9 or 10 (destination) migration there are a number of things you should consider. Taking the time to plan your migration will help to ensure that you're successful. In this tutorial we'll take a high-level look at:
- Evaluating your existing Drupal 6/7 site for migration feasibility
- Preparing your source Drupal 6/7 site for a migration
- Preparing the destination Drupal site you're migrating to
By the end of this tutorial you should be ready to start assessing the feasibility of performing a successful migration, and begin making a migration plan.
This tutorial will help you understand the complete life cycle of a Drupal form: receiving the request from a browser, displaying a page with a form, rendering the form as HTML, handling the submitted form, validating input, handling errors, and processing data. We'll point out the common places that module developers might want to inject additional functionality into the process. And we'll link to tutorials with more details about each integration point in a form's life cycle.
In this tutorial, we'll:
- List the steps of the life cycle of a Drupal form.
- Describe how Drupal determines which form to display, and which form handles an HTTP POST request.
- Understand the role of
FormStateInterface
in the life cycle of a form.
By the end of this tutorial, you should have a solid understanding of the life cycle of a form within Drupal.
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.
Previously, in Implement a Functional Test, we learned how to tell BrowserTestBase
to use the Standard installation profile in order to get our test passing, letting the Standard profile implicitly provide our dependencies. We mentioned that doing so probably wasn't the best decision and that we should explicitly declare those dependencies instead.
In this tutorial, we'll walk through how to explicitly declare our test's dependencies. When in doubt, it's generally considered a best practice to be as explicit about the dependencies of our tests as possible. By the end of this tutorial, you should be able to:
- Understand why we want to explicitly declare our dependencies.
- Determine what the dependencies really are and make a list of them.
- Implement each dependency in our list.
- Emerge with a thorough passing test.
Twig is the theme template engine in Drupal as of version 8. Like any code, there are guidelines and standards that dictate both the style and the structure of the code. In this tutorial we will explain how to adhere to the Drupal code standards while implementing Twig templating.
By the end of this tutorial you will be able to adhere to Drupal's coding standards when writing Twig, and know where to find more information about the guidelines when necessary.
The core structure of Drupal's Render API is the render array, which is a hierarchical associative array containing data to be rendered and properties describing how the data should be rendered. As a module developer you'll use render arrays to describe the content your module controls in order to output it on a page as HTML, or as part of a response in another format like JSON. As a theme developer, you'll manipulate render arrays in order to affect the way content is output on the page.
In this tutorial we'll learn:
- What render arrays are and why they exist
- The basic format of a render array
- What "properties" and "elements" signify in the context of a render array
- Where to find more information about how to create a render array to describe your own content
By the end of this tutorial you should be able to understand when you need to use a render array, recognize one when you see it, and know where to get more detailed information about render array formatting specifics.