Drupal has a few handy settings you can tweak to make developing themes a little more intuitive and a lot more awesome. In this tutorial, we'll practice manually setting up our environment for theme development by:
- Disabling some caches
- Turning off CSS and JS aggregation
- Turning on the Twig debug service
By the end of this tutorial, you'll have practiced setting up your environment for theme development.
In this tutorial we'll look at how you can use the #theme
property of a render array to define custom HTML. With this information, module developers can use render arrays to define content, and theme developers can understand how elements in a render array are converted to HTML and which templates they can override to change the output for a specific element.
Learn how to:
- Use
hook_theme()
to define a new theme hook and define default values for variables - Create a corresponding Twig template file that outputs the variables and any custom HTML markup
- Use a preprocess function to add additional variables for the Twig template file you created
- Use the new theme hook in conjunction with a
#theme
property in a render array to link your Twig template file to actual content
By the end of this tutorial you should know how to define new templates to output content as HTML. You should also have a better understanding of how Twig template files are linked to elements in a render array.
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.
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.
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.
In order to change Drupal's default markup you need to override template files. The page template controls the overall layout of your theme, including the placement of regions. You should practice the exercise following the written instructions below. Use the video walk-through to help if you get stuck.
In this exercise, we'll:
- Override the currently used page.html.twig template file.
- Modify the content of the file to include the regions defined in the theme's .info.yml file.
- Wrap the regions in the page template file with HTML markup using CSS classes from Bootstrap to achieve the example layout.
By the end of this tutorial, you'll gain practice creating a custom layout in a page template file.
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.
Once you've defined an asset library you'll need to tell Drupal when you want to add the CSS and JavaScript that it includes to the page. Ideally you'll do so in a way that allows Drupal to only add the corresponding assets on pages where they are needed.
You can attach a library to all pages, a subset of pages, or to elements in a render array. This allows you to have some assets that are global, and others that get loaded on an as-needed basis. To attach a library you'll need to know both its name and prefix, and then use one of the techniques outlined below to let Drupal know when to include it.
In this tutorial, we'll look at attaching asset libraries:
- Globally, via your THEMENAME.info.yml file
- Conditionally, via a preprocess function using the
#attached
render array property - Inside of a Twig template file
By the end of this tutorial you should be able to attach asset libraries in various different ways depending on your use case.
Customizing the available regions in your theme is one of the first things you'll do when creating your own themes. Doing so gives you complete control over where content is displayed on the page, and the markup involved. Adding regions to a theme is a two-step process that involves editing your theme's THEMENAME.info.yml file and updating your page.html.twig file.
In this tutorial we'll:
- Declare one or more new regions in our themes THEMENAME.info.yml file.
- Output the content of those regions in our theme via the page.html.twig file.
By the end of this tutorial you should be able to add or edit the regions a theme provides. Also, you'll ensure that blocks placed into regions are displayed by outputting the regions in the page template.
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
It's a Drupal best practice to always use Drupal's internationalization utilities for any user interface strings in your code. This includes the PHP t()
function and StringTranslationTrait
trait, the Twig t
filter, and the JavaScript Drupal.t()
function. This makes it possible for our module's interface to be localized.
In this tutorial, we'll:
- Edit the
WeatherPage
controller and use thet()
method from theStringTranslationTrait
trait for all UI strings. - Update the weather-page.html.twig template file to use the Twig
t
filter. - Modify the JavaScript in our forecast.js code to use the
Drupal.t()
function for UI strings.
By the end of this tutorial you should be able to update the PHP, Twig, and JavaScript code in your module to ensure that any user interface strings they output are translatable.
In this exercise, we'll practice theming by overriding the main menu template. We'll:
- Override and rename the main menu template so that it will only affect the main menu component of our Drupal site.
- Add Bootstrap classes from the base nav component into our overridden main menu template file.
- Add CSS classes to HTML selectors using
attributes.addClass()
andset
methods.
We recommend that you work on the exercise steps below first. You can refer to the video if you need some help.
CSS in Drupal
TopicCascading Style Sheets (CSS) files are added as an asset library through a theme’s libraries configuration file. HTML attributes, including classes and IDs, are commonly added in template files with Twig.
Each theme is a collection of files that define a presentation layer for Drupal. While only a THEMENAME.info.yml file is required, most themes will contain other files as well. Some are Drupal-specific, and need to follow a strict naming convention and be placed in the appropriate place for Drupal to find them. Others are standard front-end web assets like CSS, JavaScript, and image files that can be placed anywhere within the theme's code.
In this tutorial we'll learn about:
- The various types of files you can expect to find in a theme directory
- Where in the Drupal code base your theme directory should live
- Keeping the directory and all the files within organized
By the end of this tutorial you should be able to explain where a Drupal theme should be placed in a project's code base, and the types of files one can expect to find in a theme.
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.
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.
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.
Like most output in Drupal, Views relies on Twig templates for a significant amount of its rendering. In this tutorial we'll identify where you can find the default Views templates within your file system, what the common templates are for, and how to name your templates so that they are applied to specific views.
By the end of this tutorial, you should be able to:
- Identify where to find default views templates
- Understand which templates apply to what part of a view
- Get a sense of the template suggestions and how to use them to limit where your custom templates are applied
- Identify a view's machine name
- Identify a display's machine name
- Identify a field's machine name
If you want to make changes to the HTML markup of any element on the page you need to first figure out the theme hook or base name of the template file used to generate it. This information is required to override the template in your custom theme.
There are other situations in which knowing the theme hook name of a template file is useful. Including determining which preprocess function affects a template, and which template theme hook suggestions can be used.
In this tutorial we'll learn:
- How to figure out the theme hook name for any template
By the end of this tutorial you should be able to use the output from Twig's debugging mode to determine the theme hook name of any template file.
In order to ensure that all user interface strings in your application can be translated using Drupal's localization system, any text you add to templates needs to use either the t
filter or the {% trans %}
tag. Anyone creating themes or editing template files associated with a theme or a module should know how to use these two utilities.
In this tutorial we'll look at:
- How to use the
t
filter and{% trans %}
tag in a Twig template - The differences between the two, and how to determine which one to use
- How to translate strings assigned to variables in preprocess functions using the PHP
t()
function