Theme Drupal Sites for Drupal 7, 8, 9, and 10

YAML, which stands for YAML Ain't Markup Language, is a human-readable data serialization format that's been widely adopted in a variety of use cases in Drupal. Anyone wanting to write modules, or themes, for Drupal will need to understand YAML syntax. Even site builders are likely to encounter YAML at least in passing as YAML is the data-serialization format of choice for Drupal's configuration management system. Good thing it's pretty easy to learn even with the most basic of programming backgrounds.

This tutorial will look at the YAML data format and provide examples of how to write and read YAML. Starting with an introduction to the language's syntax and some of the strengths of YAML. Then looking at the difference between scalar data types like strings and integers, and collection data types like lists and associative arrays.

Since YAML in the Drupal world is read into PHP and ultimately becomes a PHP data structure that we can use in our own code we'll also look at how the YAML we write in a .yml file is represented in PHP data types. To do this we'll use the YAML Sandbox module that provides a handy textarea into which we can type YAML and have it parsed into PHP data structures.

Learning objectives

• Explain what YAML is and its strengths as a data serialization format
• Create scalar key/value pairs in YAML
• Create lists, and associative arrays using YAML collections
• Understand how the YAML you write is represented in PHP

Tips

• In Drupal, use the .yml extension and not .yaml
• Ensure your code editing application is configured to use spaces (preferably 2 spaces, as per Drupal coding standards), not the tab character when the TAB key is pressed. If you have tab characters in a YAML file within a Drupal environment, a fatal PHP error will be thrown and you'll see a White Screen of Death (WSOD).
• Copy and paste from an existing YAML file to ensure the formatting is correct, and edit from there.

• http://www.yaml.org
• YAML Sandbox module
• Find other tutorials and external resources related to YAML on our YAML topic page (Drupalize.Me)

Themes are the part of Drupal that you, and anyone else visiting your Drupal powered application, see when they view any page in their browser. You can think of a theme as a layer, kind of like a screen, that exists between your Drupal content and the users of your site. Whenever a page is requested Drupal does the work of assembling the content to display into structured data which is then handed off to the presentation layer to determine how to visually represent the data provided.

Drupal themes are created by front-end developer. Frequently referred to as themers, or theme developers. Themes consist of standard web assets like CSS, JavaScript, and images, combined with Drupal-specific templates for generating HTML markup, and YAML files for telling Drupal about the file and features that make up each individual theme.

In this tutorial we'll:

• Explain what a Drupal theme is.
• Explain the role of a Drupal themer in the process of building a Drupal site.
• Get a high level overview of the types of files/code that themes are made of.

By the end of this tutorial you should be able to explain what a Drupal theme is, and the kind of work a Drupal theme developer will be expected to do.

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.

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.

Info files, aka THEMENAME.info.yml files, provide Drupal with metadata about your theme, the features it supports, and the regions that it defines. All themes are required to have a THEMENAME.info.yml file, and creating one is generally the first step you'll take when creating a new theme.

In this tutorial we'll:

• Create a new .info.yml file and define a new theme
• Review the required key/value pairs of an .info.yml file
• Enable our new theme in the Drupal UI

By the end of this tutorial you'll be able start a new theme by creating the required *.info.yml file and better understand its contents.

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

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.

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.

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.

Some, but not all, themes come with administrator-configurable settings that you can change through the UI. These might allow you to upload your own logo, choose between a couple of different pre-defined layouts, or turn features of a theme on or off. In this tutorial we’ll look at where you can find these theme settings if they exist, and how to go about changing them.

Contributed and custom themes can ship with a thumbnail screenshot that will be used to represent the theme when listing themes in the administration UI.

In this tutorial you'll learn how to:

• Prepare your site for the screenshot
• Create a screenshot of your theme
• Define a screenshot file for your theme in the THEMENAME.info.yml file

In Drupal's Appearance UI, all themes get a theme settings form. As a theme developer, you can customize the theme settings form, enabling site administrators to have more control over the appearance of the theme.

In this tutorial, we'll show you how to add admin-configurable settings to your theme. In the process of doing this, we'll use a variety of theme and module development skills and assume you have some familiarity with using Drupal's Form API, Configuration API, and theme system (see Prerequisites).

By the end of this tutorial, you will be able to provide custom theme settings that an administrator can use to modify the appearance of the theme.

Custom 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.

Make your theme a subtheme of a base theme, allowing it to inherit all the base theme's templates and other properties. When creating Drupal themes it is common to use the Classy theme provided with Drupal core as a base theme to jumpstart your development.

In this tutorial we'll learn how to:

• Use the base theme key in our theme's THEMENAME.info.yml file
• Make our Ice Cream theme inherit from the Classy theme, or any other theme

By the end of this tutorial you should be able to tell Drupal that your theme is a child of another theme and should inherit all of the parent theme's features.

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

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.

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.

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

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.

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

Knowing how to clear Drupal's cache is an important skill for any developer. You'll likely find yourself doing it frequently in order to get Drupal to register the changes you make to your code, or other updates you make via the UI. It is also a good first step to trouble shooting problems with your Drupal site: Clear the cache before you do any other debugging to ensure it's not just a bad cache entry.

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.

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.

Themes and modules can alter the list of theme hook suggestions in order to add new ones, remove existing ones, or reorder the list. This powerful feature allows for the definition of custom logic in your application that can tell Drupal to use different templates based on your own unique needs. You might for example; use a different page template for authenticated users, or a custom block template for someone's birthday.

In this tutorial we'll cover:

• Adding new theme hook suggestions from a theme using hook_theme_suggestions_HOOK_alter()
• Altering the list of theme hook suggestions
• Removing theme hook suggestions
• Reordering the list of theme hook suggestions

An asset library is a bundle of CSS and/or JavaScript files that work together to provide a style and functionality for a specific component. They are frequently used to isolate the functionality and styling of a specific component, like the tabs displayed at the top of each node, into a reusable library. If you want to include CSS and/or JavaScript in your Drupal theme or module you'll need to declare an asset library that tells Drupal about the existence, and location, of those files. And then attach that library to a page, or specific element, so that it gets loaded when needed.

In this tutorial we’ll:

• Define what an asset library is.
• Explain why asset libraries are used to include JavaScript and CSS files.
• Look at some example asset library definitions.

By the end of this tutorial you should be able to define what asset libraries are, and when you'll need to create one.

New asset libraries can be defined by either modules or themes. In order to define a new asset library you need to create the requisite CSS and JavaScript files, and a new THEMENAME.libraries.yml, or MODULENAME.libraries.yml file that aggregates them together and provides metadata about the library itself and any dependencies.

In this tutorial we’ll:

• Look at the structure of a *.libraries.yml file and demonstrate how to combine a couple of CSS and JS files together into an asset library that can be used in a theme or a module
• Look at how one asset library can declare that it is dependent on another in order to ensure the assets from the dependency are loaded as well

By the end of this tutorial you should know how to define a new asset library in either a module or a theme.

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.

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.

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.

Maybe you've heard of anonymous closures but you're not quite sure how they apply in Drupal, or why using them is considered a best-practice. Anonymous closures allow you to avoid accidentally clashing with anything in the global scope, as well as to alias the jQuery object to the more commonly used $. This is necessary because Drupal runs jQuery in no-conflict mode. This tutorial will look at the syntax used for placing your custom JavaScript code inside an anonymous closure, and why it's a good idea to do so.

In this tutorial we'll:

• Explain what a closure is (briefly), and what immediately invoked function expressions are
• Show how typically Drupal JavaScript gets wrapped in a closure
• Provide a copy/paste example you can use in your own code

By the end of this tutorial you should be able to explain what an anonymous closure is, and how to use one in your custom JavaScript for Drupal.

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

Every theme can contain an optional THEMENAME.theme file. This file contains additional business logic written in PHP and is primarily used for manipulation of the variables available for a template file, and suggesting alternative candidate template file names. Themes can also use this file to implement some, but not all, of the hooks invoked by Drupal modules.

In this tutorial we'll learn:

• The use case for THEMENAME.theme files, and where to find them
• The different types of functions and hooks you can implement in a THEMENAME.theme file

By the end of this tutorial you should be able to know how to start adding PHP logic to your custom theme.

Preprocess functions allow Drupal themes to manipulate the variables that are used in Twig template files by using PHP functions to preprocess data before it is exposed to each template. All of the dynamic content available to theme developers within a Twig template file is exposed through a preprocess function. Understanding how preprocess functions work, and the role they play, is important for both module developers and theme developers.

In this tutorial we'll learn:

• What preprocess functions are and how they work
• The use case for preprocess functions
• The order of execution for preprocess functions

By the end of this tutorial you should be able to explain what preprocess functions are and the role they play in a Drupal theme.

Preprocess functions are specially-named PHP functions that allow themes and modules to modify the variables passed to a Twig template file. They are commonly used by themes to alter existing variables before they are passed to the relevant template files. For example; Changing the makeup of render array so that it renders an <ol> list instead of a <ul> list. Or appending data to the label of a node depending on custom logic.

In this tutorial we'll:

• Define a new preprocess function in our theme's .theme file
• Use the preprocess functions to modify the content of an existing variable before it's used in Twig

By the end of this tutorial you should be able to define new preprocess functions in a theme (or module) that manipulate the variables for a specific Twig template file.

Preprocess functions are specially-named functions that can be used to add new variables to a Twig template file. They are commonly used by themes to add new variables based on custom PHP logic and simplify accessing the data contained in complex entity structures. For example: adding a variable to all node.html.twig template files that contains the combined content a couple of specific fields under a meaningful name like {{ call_to_action }}. Modules use preprocess functions to expose the dynamic data they manage to Twig template files, or to alter data provided by another module based on custom logic.

In this tutorial we'll learn how to:

• Use PHP to perform some complex logic in our theme.
• Store the resulting calculation in a variable.
• Make that variable available to a Twig template file.

Example use cases for adding variables with preprocess functions include:

• Anytime calculating the value to output in a template requires logic more complex than an if/else statement.
• Anytime the desired value requires additional string manipulation beyond what can be easily accomplished using an existing Twig filter or function.

By the end of this tutorial you should be able to expose new variables to a Twig template file by defining a preprocess function in either a module or a theme.

You may know that Drupal provides utility PHP functions for manipulating and sanitizing strings. Drupal also provides JavaScript functions for the same purpose. The two most useful are Drupal.checkPlain and Drupal.formatPlural. Drupal.checkPlain lets you ensure a string is safe for output into the DOM; it is useful when working with user-provided input. Drupal.formatPlural ensures that a string containing a count of items is pluralized correctly. This tutorial will show you where you can find documentation for and example use-cases of both.

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.

It's probably not too surprising that a library called Backbone aims to provide structure to your front-end JavaScript code and applications. In this tutorial we'll take a look at how Backbone.js goes about achieving that goal, and how you can make use of it on your Drupal site. We'll first take a high-level look at the main components that make up the Backbone.js library. With that basic understanding in place we'll look at an example of how you might integrate Backbone.js into a Drupal site.

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

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

Sometimes your JavaScript needs to insert new strings into the user interface. In order to ensure that those user-facing strings can be translated into other languages, just like the rest of Drupal's user interface, you should make sure and use the Drupal.t function anytime you output a string of text.

In Drupal, whenever we output markup it's best practice to use a Twig template or a theme function. But whenever you need to output DOM elements within JavaScript the best practice is to use the Drupal.theme function. This function ensures that the output can be overridden just like the HTML output by Twig. This tutorial covers how to use the Drupal.theme function in your JavaScript when inserting DOM elements, as well as how to replace the markup output by other JavaScript code that is using the Drupal.theme function.

ESLint is the linting tool of choice for JavaScript in Drupal. In this tutorial we’ll show how to install the ESLint application and then use it to verify that your JavaScript files are meeting the Drupal coding standards.

Drupal (as of version 8.4) has adopted the Airbnb JavaScript coding standards. In this tutorial, we'll walk through how to install the necessary package dependencies to run eslint on JavaScript files within your Drupal site.

You've got a slick responsive theme for your Drupal site that's been implemented in CSS using media queries. But the content and images on your site will regularly be updated and you want to use the Responsive Images module to create responsive image style field formatters that you can apply to image field display settings.

In this lesson, we'll review the concepts of breakpoints and media queries so that you can better understand what's going on when you encounter them in non-CSS file contexts like configuration forms for responsive image styles or breakpoint YAML files.

By the end of this tutorial, you should have an understanding of what breakpoints are, how they are expressed in media queries, and how they are relevant in the context of Drupal.

Drupal's Breakpoint module defines a "breakpoint" plugin type that modules or themes can implement via a breakpoints configuration file. So, in order to make their breakpoints discoverable, themes and modules define their breakpoints in a THEME-OR-MODULE.breakpoints.yml file located in the root of their directory.

In this tutorial, you'll learn about the structure of a breakpoints configuration file and why you would want to use one. We’ll cover the kinds of metadata you can include in a breakpoint file, including key, label, mediaQuery, weight, multipliers, and breakpoint group. Throughout, we'll look at some examples of breakpoint configuration files available in Drupal themes and modules.

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.

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:

1. The browser can choose an appropriately sized image source, given the size of the user device's viewport size
2. 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 we dive into advanced theming we are going to review the basic PHP you will need to use. This is a short review of PHP, including topics like data structures (arrays and objects), conditionals and operators, loops, and functions.

960 Robots