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.

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.

Bartik is a core theme in Drupal. As a default theme for Drupal, it serves as an instructive example of a well-developed responsive theme. In this tutorial, we'll tour and explore Bartik, identify its primary features, and explain the use case for the Bartik theme and what you can learn from it.

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

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.

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.

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.

If you want to create a link to an internal page in a Twig template--and there's not already a variable in the template that contains the URL you want to link to--you'll need to determine the route of the thing you want to link to and then use the Twig url() or path() functions to generate appropriate URLs. In most cases when you want to create a link to an entity that is being output by the current template there's an existing helper variable to use. For example, in a node.html.twig template file there's a url variable that points to the current node. For other scenarios, like hard-coding a link to the /about page, you'll need to do a little more work.

In this tutorial, we'll:

• Get the absolute URL value
• Get the relative path value
• Generate HTML for a link
• Get the URI to a file, like an image in the Media library
• Get the active theme path

By the end of this tutorial you should be able to create links to any internal page via Twig.

Do you cringe at the sight of untidy whitespace or (gasp) no whitespace at all when you View Source? Learn how to tame whitespace in Twig template files in this tutorial. By the end of this lesson, you will be able to recognize how Twig controls whitespace and how you can do the same in your Drupal template files.

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.

Managing a Drupal application with Composer requires a few modifications to Composer's default behavior. For instance, Drupal expects that specialized packages called "modules" be downloaded to modules/contrib rather than Composer's default vendor directory.

Additionally, it is common practice in the Drupal community to modify contributed projects with patches from Drupal.org. How do we incorporate Drupal-specific practices like these into a Composer workflow?

In this tutorial we will:

• Address all of the Drupal-specific configuration necessary to manage a Drupal application using Composer

By the end of this tutorial you should know how to configure Composer to work with Drupal, and drupal.org.

When managing your Drupal project with Composer you'll use Composer commands to download (require) modules and themes that you want to install, as well as issuing commands to keep those modules and themes up-to-date when new versions are released.

In this tutorial we'll:

• Cover step-by-step instructions for performing common Composer tasks for a Drupal application
• Install and update Drupal projects (core, modules, themes, profiles, etc.) using Composer
• Convert an existing application to use Composer

By the end of this tutorial you should know how to use Composer to install, and update, Drupal modules and themes.

In this tutorial, you'll learn how to add a property to a configuration entity in Drupal. Previously, we created a configuration entity called Transcode Profile and learned about the files and code that compose a configuration entity. Now, we'll add a new property called codec to this configuration entity and learn some new concepts in the process.

In order to add this new property to our custom configuration entity, we'll need to update our schema file, configuration entity forms, the entity list builder class, and add getter and setter methods to our main TranscodeProfile class.

When automating the deployment of a Drupal site, it's critical to have a good understanding of the configuration management workflow in order for deployments to be consistent and successful.

Before you can get started synchronizing configuration between instances of your site, you'll need to create a new instance or "clone" of your Drupal site.

By the end of this tutorial, you should know:

• Why it's necessary to clone your site if you want to manage configuration between environments
• How to find your site's universally unique identifier (UUID)
• What to consider when setting up a directory structure for your project
• How to clone a Drupal site

Drupal creates a line of separation between what is content and what is configuration. The line is such that content is stored only in the database, whereas configuration is maintained by the configuration management system. While cached to the database for performance reasons, configuration can be thought of primarily living in the sync directory as a series of flat files.

This sounds like a perfectly clear distinction in theory, but there are several times where interdependencies appear between content and configuration. Understanding the key places where these interface can help prevent confusion and "disappearing" settings due to a lack of understanding.