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.

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.

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.

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.

In Twig, you can modify variables using functions or filters. Twig has a bunch of built-in functions and filters. Drupal extends Twig to provide a few handy Drupal-specific functions and filters as well.

In this tutorial, we'll look at:

• What are functions and filters?
• How to use functions and filters in Twig
• Detailed information about the Drupal-specific functions and filters and their use case

To read a Twig template file, you'll need to recognize Twig's syntax delimiters. Twig has three syntax delimiters: one for printing out variables, another for performing actions or logic, and lastly, one for comments, also used for docblocks.

In this tutorial we'll:

• Explore each of Twig's 3 syntax delimiters.
• Show examples of each from Drupal's core template files.

By the end of this tutorial you should be able to recognize each of Twig's syntax delimiters and understand what the engine will do when it encounters them.

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.

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.

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.

As a developer, within a module, you can define settings for the module and provide a configuration form for administrators to update the values of those settings. In this tutorial, we'll create a configuration settings form for a module and define default values for each setting. We'll use Drupal Console, a command-line utility for Drupal to do some code scaffolding and speed up the process.

By the end of this lesson, you should be able to get a basic settings form up and running inside a custom module complete with default settings and a menu link.

Before we start synchronizing configuration, let's take a look at the default, out-of-the-box file location for staging and synchronizing configuration. Then we'll walk through how to change that directory to a location outside our project's docroot and update settings.php appropriately.

In this tutorial, we'll cover:

• The default location of the configuration sync directory
• How the configuration sync directory is secured
• How to change the location of the sync directory

The configuration system in Drupal was designed to manage and sync configuration between instances of a Drupal site. So before configuration management can be useful, we must have another instance—or clone—of our Drupal site. In this lesson, you will learn:

• Why cloning a Drupal site is necessary in order to manage configuration
• How to clone a Drupal site using tools that have a graphical user interface (GUI)

If you prefer using web-based or GUI tools rather than command line tools such as Drush and Git, then this lesson is for you.

Not every environment or copy of a site you may be working on will be created equally. You may want to enable logging on a development site or need to use different API keys depending on the environment. But you also need to make sure that your instance-specific configuration overrides don't make it into the database, mistakenly get exported, or compromise security.

In this tutorial, you will learn how to:

• Override the global $config array in settings.php (or settings.local.php)
• Retrieve overridden (immutable) configuration (read-only mode)
• Retrieve original (mutable) configuration for updating (read/write mode)
• Set dynamic values for configuration instead of overriding values

When you create a module for Drupal, it can be useful to provide default configuration. This can be settings for a form, the placement of a block, or something more complex like the default image styles provided by the Image module in core. A module can provide default configuration for simple configuration or configuration entities.

In this tutorial, we will cover:

• Possible locations for default configuration
• What happens with configuration when a module is installed or uninstalled
• Managing dependencies in configuration
• Where to find examples of default configuration

Configuration entities are suitable for creating user-defined configuration, such as image styles, views, content types, etc. A configuration entity type is defined by a module, default configuration is provided by that module as well as any other module, and then users can create zero or more configuration entities through Drupal's administrative UI.

In this tutorial, you will learn about:

• What configuration entities are
• Configuration entity types versus configuration entities
• An example in core: image style
• Overview of the process of creating your own configuration entity types in a module

In this tutorial, we'll cover how to load configuration entity data in a module. We'll change the AdminSettingsForm.php we created and replace the simple textfield we were using with a dropdown select list. Then we'll use data from our Transcode Profile module's configuration entity, loaded by the EntityTypeManager via the services container, to choose our preferred Transcode Profile.

By the end of this tutorial, you should be able to:

• Know how to load configuration entities using EntityTypeManager via the services container
• Update the AdminSettingsForm.php to use a dropdown select list
• Save your preferred transcode profile from a list of transcode profile entities
• Update the default configuration provided with the demo module to include transcode profiles