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.
When determining which template file to use to theme an element, Drupal uses the list of theme hook suggestions to look for the best match. This allows for fine-grained control over how things appear based on dynamic state and contextual information in your application. The list of theme hook suggestions varies for each base template, so we need a way to figure out our options.
In this tutorial we'll look at:
- How to determine the list of valid theme hook suggestions for any template file
- How theme hook suggestions are added by modules and themes
By the end of this tutorial you should be able to explain how theme hook suggestions are added, and determine the valid suggestions for any template file.
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.
Anyone writing JavaScript for Drupal should use the Drupal.behaviors
API when writing their custom JavaScript functionality. Doing so ensures that your JavaScript is executed at the appropriate times during the life cycle of a page, such as when the page loads, or after new DOM elements have been added via an AJAX request.
In this tutorial we'll look at:
- The problem that
Drupal.behaviors
solves - How to use
Drupal.behaviors
when writing your JavaScript code
By the end of this tutorial you should be able to explain what the Drupal.behaviors
API is, and be able to use it in your own JavaScript.
Drupal comes with all of its caching features enabled by default. This improves response time, but can be frustrating for themers as it makes it harder to preview the changes you make to template files.
In this tutorial we'll look at:
- Why these features are enabled by default
- How the theme layer leverages Drupal's caches
- Why you should learn to disable them when doing development
Knowing how to inspect the variables available within a template file enables you to discover all of the dynamic content in a Twig file, not just that which is already being used.
In this tutorial, we'll learn how to use {{ dump() }}
, kint()
, vardumper()
, and XDebug to inspect variables in a template file.
Before visitors to your site will see the pages displayed using a theme the theme needs to be installed and set as the default. This is true whether it's a custom theme you wrote yourself, or a contributed theme you downloaded from Drupal.org. Installing themes can be done either via the user interface, or using Drush. Once a theme is installed, users of your site will see all public facing page rendered using that theme. Themes that are no longer being used can safely be uninstalled.
In this tutorial we'll:
- Demonstrate how to install a theme and make it the default using both the UI and Drush.
- Learn to differentiate between installed themes, default themes, and uninstalled themes.
- Configure our site to use an administration theme for the administrative pages.
By the end of this tutorial you should be able to install a theme and make it the one visitors to your site see by default.
JavaScript is used and loaded in special ways within a Drupal site. JavaScript is loaded via asset libraries and Drupal core provides a bunch of different JavaScript libraries that you can load and use in your module or theme. This tutorial provides a brief orientation to some of the JavaScript included in core.
In this tutorial we'll:
- Preview the JavaScript ecosystem in Drupal
- Find pointers to tutorials where you can learn more about adding JavaScript to a theme or module
- Learn about examples of JavaScript in Drupal core that are useful to review for learning purposes
By the end of this tutorial you should have a good overview of how JavaScript is used throughout Drupal core.
Many of the variables that you have access to inside of a Twig template file are arrays. For example a list of values for a multi-value field, or a set of error messages generated when validating a form submission. In order to work with arrays in Twig you'll need to understand how for
loops work. This is essential information for anyone creating Drupal themes.
In this tutorial we'll cover:
- Using the
for
tag to iterate over an array - Using the
loop
variable inside of afor
loop for additional context
Any text that will be displayed to user as part of your application's user interface should be passed through the t()
function, or an equivalent, so that it can be translated into other languages as needed. This tutorial will look at how to use the t()
function.
This tutorial contains information that applies to anyone writing modules or themes. And many of the tutorials you read on this site and on the web in general will expect that you understand how basic string translation works.
In this tutorial we'll look at:
- Passing strings through the
t()
function or equivalent so they are available for translation - Using placeholders for dynamic content in translatable strings
- Tips for making your code's interface strings easier to translate
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
In developing the theme for your website it's important to take accessibility into account. Making your site available and functional for as many users as possible is always a good idea. Progressive enhancement and graceful degradation are key, but how do you go about accounting for the minute differences between browser capabilities? This is where the Modernizr.js library can help you out.
Modernizr is a collection of browser detection tests which allow you, in either CSS or JavaScript, to determine if a particular browser supports a large list of features. From there it can automatically add classes to your page depending on the results of a particular feature test. It can also be used to create additional custom tests. In this tutorial we'll take a look at a few of the feature detection tests that Modernizr natively supports as well as how a custom test can be added to a Drupal theme.
This tutorial demonstrates how to locate the template file that is currently being used to render an element and override it in your own theme. This is an important skill for anyone who wants to make changes to Drupal's default HTML markup.
In this tutorial we'll:
- Override the node.html.twig template in our theme
- Make changes to the markup
- Create a content-type-specific template override like node--CONTENT_TYPE.html.twig
By the end of this tutorial you should be able to modify the HTML markup used to display a node, or any other element of the page generated using a template file.
The ability to loop over an array of values in a Twig template and print out each value individually is an important skill for anyone developing themes for Drupal. Common scenarios include: loop over the values of a multiple value field; iterate through a list of links; and display error messages at the top of forms. This tutorial will provide an example of using the Twig for
function to iterate over a list, or a subset of a list.
In this tutorial we'll cover how to:
- Output values from a multi-value field in an unordered list.
- Add first and last classes to the first and last items in a list by using the Twig
loop
variable.
By the end of this tutorial you should be able to print out the values of an array as individual list items using a loop in Twig.
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.
The Responsive Image module provides a process for transforming images uploaded through image fields into responsive images. This is accomplished through the configuration of responsive image styles. The configuration form for adding and editing responsive image styles is quite extensive. In this tutorial, we'll go through this form and learn what each option entails. By the end of this lesson, you should have a good understanding of the various options in the responsive image style configuration form.
You might already be familiar with image styles in Drupal. Image styles are a popular and commonly used feature of Drupal because they enable your site's content creators to upload an image once, but have it displayed at various sizes and resolutions depending on its context. Image styles are configured and then applied to an image field's display settings, whether using view modes, Views field settings, or other contexts. Responsive image style field formatters are applied in the same exact way, but the process of creating responsive image styles is a bit different.
Using responsive image styles as image field formatters enables your Drupal site to produce specific HTML markup for images so that either:
- The browser can choose an appropriately sized image source, given the size of the user device's viewport size
- You can dictate to the browser which image sources to use at different breakpoints.
In the first case, the resulting markup uses the srcset
and sizes
attribute in an <img>
element. In the second case, <picture>
and <source>
elements are generated in conjunction with the <img>
tag.
It is also possible to create a responsive image style that just provides alternate images depending on the display-density (i.e. 1.5x or 2x) of the user device.
In this tutorial, we'll look at three use cases for responsive images, how those use cases are handled in HTML, and how they can be handled using Drupal's Responsive Image module. By the end of this tutorial, you should be ready to create a responsive image style appropriate for your Drupal site.
In this tutorial, we're going to add a responsive image style to an image field on the Article content type. This will add the srcset
and sizes
attributes to the output <img>
element, providing media conditions, width descriptors, and a set of image sources for the browser to choose from, depending on the user device's viewport size.
This solution, especially when used in conjunction with CSS, will provide flexible, fluid, and faster-loading images for your site, and will work for probably 80% of use cases. It does not provide "art direction", that is, making cropping, aspect ratio, or orientation changes to an image. This solution also provides for different display-densities, like 1.5x and 2x image sources without the need for display-density descriptors.
Another benefit of this solution is that it uses the Responsive Image module's breakpoint configuration file, so there is no need for you to create a breakpoint file in your theme to implement this flavor of responsive image style.
Before you can create a path or link to another page on your site, you'll need to know the route (unless there is already a variable available for the URL you need). Finding a route can be a tricky task unless you have the right tools. In this tutorial, we'll show how tools like Webprofiler, Drush, and Grep can be used to get route information for a page, so that you can use functions that need a route as a function parameter.
In this tutorial we'll:
- Learn how to determine the route or path of an internal page.
It's often useful to pass dynamically calculated values from the server to the client in order to make them available to your front-end JavaScript. Your JavaScript might need to know something particular about the user currently visiting the site or the value of a particular configuration variable. In this tutorial, we'll look at how Drupal can pass these values from the PHP code that executes during a page load to the front-end JavaScript in your theme.
In order to do this, we'll need to:
- Explain how drupalSettings bridges the gap between PHP and JavaScript
- Generate values for settings in PHP and make them available to JavaScript
- Make use of PHP generated settings within your JavaScript code