Template files are responsible for the HTML markup of every page generated by Drupal. Any file ending with the .html.twig extension is a template file. These files are composed of standard HTML markup as well as tokens used by the Twig template engine to represent dynamic content that will be substituted into the HTML markup when the template is used. As a theme developer, you'll work with this a lot.
In this tutorial we’re going to learn about:
- What template files are, and how they fit into the big picture of creating a theme
- How template files are used in order to allow theme developers to modify the HTML markup output by Drupal
- Naming conventions for, and specificity of, template files
Preprocess functions allow you to change existing variables, or add new variables, for a template file using PHP code. In this exercise, you'll:
- Define a PHP function that implements a preprocess hook
- Create a new variable named
{{ today }}
that contains the current date and gets passed to the page.html.twig template file.
We recommend that you try the exercise's steps first, and refer to the video if you need help.
Like many things in Drupal, there are multiple ways to solve the same problem when using Layout Builder. The Layout Builder system is very flexible. In order to be successful when using it, it helps to plan ahead and think through your specific use-case. Picking a pattern, and sticking to it, will help ensure your configuration is more maintainable, and easier for others to understand. While there's nothing to prevent you from mixing and matching, in our experience we've found it's helpful to at least set some ground rules.
In this tutorial we'll outline 3 different patterns to use with Layout Builder, and the pros and cons of each. We'll include:
- Using content fields in scenarios where a few pages use Layout Builder, but the majority of the site's layout is done via the theme and is generally not configurable by editors.
- Using a blocks-based approach to layouts for scenarios where you want to use Layout Builder instead of the traditional blocks and regions approach and allow editors to make changes via the UI.
- And finally, using an Entity view modes approach for sites that rely heavily on Layout Builder and contain lots of interrelated content types with complex layout requirements.
By the end of this tutorial you should have a better understanding of how to approach using Layout Builder for your specific use-case, and the advantages and disadvantages of different common patterns.
Template files in Drupal modules provide the default HTML markup for the visual presentation of a module's data. Be aware that themes are likely to override the template with site-specific customizations. This template should contain only minimal markup to ensure functionality, and document the variables fed into the template.
In this tutorial, we'll:
- Explain the role of Twig template files in modules.
- Show how modules declare and use template files.
- Recognize how a render array can specify a template.
By the end of this tutorial, you should be able to articulate how and when a module should define a new template file.
14.3. Learning More
FreeHow to find additional material to gain advanced site-building skills.
In this exercise, we'll continue our template overriding practice by overriding the image field template. We'll consult the Bootstrap documentation and add a responsive image class that will apply to any images uploaded by a user to the field_image
field. Once again, we'll add this class to the classes
array in the set
Twig tag. You should work on the exercise steps below first, and you can refer to the video if you need some help.
Now that we understand what templates are and how we can use them, let's override some templates! In this tutorial we'll copy the views wrapper template to our theme and override it so that we can customize the markup for the Baseball Players view. Then we'll modify the template so that our view's pager appears both above and below our table of players.
Drupal media entities are fieldable entities, which means that you can add any custom fields you want to your Media types. These fields can be used for collecting additional metadata about a resource, categorizing and organizing resources so they're easier to find in a large media library, or for displaying information like a photo credit or transcript for a video. The possibilities are endless once you know how to add, and optionally display, fields in Drupal.
Some example use cases for adding fields to Media types:
- Collect, and display, a credit to go along with a photo. This could also be a date, a location, or any other metadata.
- Store resource width and height dimensions as custom fields so they can be referenced by display logic in the theme layer.
- Use Taxonomy reference fields to add tags or categories to help keep a large library organized.
In this tutorial we'll:
- Learn how to add fields to a Media type
- Verify our new custom field is working
By the end of this tutorial you'll know how to add custom fields to any Media type.
In this exercise, we'll practice using the t
filter in a Twig template. As a best practice, all hard-coded text in a template should be translatable. Simple text (containing no dynamic tokens) can be passed through the t
filter to achieve this objective. Along the way, we'll also use a basic conditional if
statement with Twig. We recommend that you try following the exercise's steps first, and refer to the video if you need help.
This guide was written, and is maintained, by Drupalize.Me. For more high quality written and video Drupal tutorials created by our team of experts, check out the collection of Drupalize.Me Guides.
Overview of development sites with an example deployment workflow for site building.
Every web framework, including Drupal, has basically the same job: provide a way for developers to map URLs to the code that builds the corresponding pages. Drupal uses Symfony's HTTPKernel component. Kernel events are dispatched to coordinate the following tasks:
- Process the incoming request
- Figure out what to put on the page
- Create a response
- Deliver that response to the user's browser
Knowing a bit more about how Drupal handles the request-to-response workflow will help you better understand how to use routes and controllers to create your own custom pages or deal with authentication, access checking, and error handling in a Drupal module.
In this tutorial we'll:
- Walk through the process that Drupal uses to convert an incoming request into HTML that a browser can read
- See how the Symfony
HTTPKernel
helps orchestrate this process - Learn about how the output from a custom controller gets incorporated into the final page
By the end of this tutorial, you should be able to describe the process that Drupal goes through to convert an incoming request for a URL into an HTML response displayed by the browser.
Drupal core comes with a few base themes: Stable, Stable 9, Classy, and Stark. Each one has a different intended use case. And all of them are useful as a reference for building your own themes.
In this tutorial we'll:
- Learn what each of the base themes included in Drupal core is intended to be used for
- Compare the output from the base themes with a focus on Stable and Classy
By the end of this tutorial you'll be able to explain the use case for each of the base themes included with Drupal core and make an informed decision about which, if any, to use when creating your own custom themes.
The available dynamic tokens or variables vary from template to template. Each page is built from a set of templates.
In this exercise, we'll:
- Override and name the node template file so that it will only affect Article nodes on our Drupal site.
- Inspect the available variables.
- Customize the markup.
- Use the Twig filter
without
.
We recommend that you try to work through the exercise yourself, and refer to the video if you need help.
It's time to create the bare-bones structure for a new theme on your site. You should try to complete this exercise based what you've learned from the tutorial prerequisites listed below. The video at the end of this tutorial will walk you through the implementation of this exercise if you need some help. In this exercise, we'll:
- Create an info file that describes a custom theme to Drupal with the regions listed below (we're going to name ours "reboot").
- Enable, and view, a bare-bones custom theme.
By the end of this exercise, you should feel comfortable starting a theme using several methods.
Core Themes: Stark
FreeStark is one of the themes bundled with Drupal. It is intentionally bare bones and its purpose is to help Drupal theme and module developers get to the heart of Drupal's system templates. In this tutorial, we'll explore Stark and its primary features and discuss the various reasons for utilizing the Stark theme.
One of the features of any content management system's architecture is the separation of presentation and data. In Drupal, modules are responsible for figuring out what should be on the page, and themes are responsible for the final look and feel of anything shown in the browser. It's vital for a module to return themeable output, so that the active theme can determine how it's presented.
In this tutorial, we'll:
- Define themeable output.
- Show how modules can avoid embedding presentation data in their output.
- Explain why Drupal favors structured arrays over HTML strings for data presentation.
By the end of this tutorial, you will be able to articulate the role modules play in enabling themes to customize a Drupal site's appearance.
Themes define the regions that are available for site administrators to place blocks in, creating a layout framework within which the components that compose a page can be placed. As a theme developer you'll need to determine what regions are necessary to accommodate your design's layout, while also ensuring it'll work with the way Drupal uses blocks to place content onto the page. Deciding what regions to create requires knowledge of how Drupal works and a clear vision of the design you're trying to achieve.
In this tutorial we'll:
- Explain what regions are and how they relate to themes
- Describe how regions are handled internally within Drupal
- Demonstrate things to keep in mind when planning the regions for your custom theme
By the end of this tutorial you should be able to describe what a region is, explain how Drupal themes use regions to place content, and get started dissecting your own designs into regions.
As we learned in the What Is a Breakpoints YAML file? tutorial, modules and themes can expose their site's CSS breakpoints and media queries to other Drupal modules and themes by implementing a breakpoints YAML file. In that tutorial, you also learned about the structure of a breakpoints configuration file and why you'd want to create one. In this tutorial, we’ll walk through the process of creating an example breakpoints file step-by-step.
By the end of this lesson, you should be able to create a working breakpoints YAML file in a theme or module. We'll test it out by enabling Drupal's Responsive Image module, where we'll be able to see it listed in the configuration form for creating a new responsive image style.