To follow along with the rest of the migration tutorials you'll want to make sure you understand the following concepts and terms as they relate to Drupal migrations.
In this tutorial, we'll take look at the basic components of a migration and familiarize ourselves with some of the concepts and terminology needed to understand how the system works. We'll cover:
- What is a migration?
- Migration templates
- The extract, transform, load process
- Destinations and sources
- Additional Drupalisms
By the end of this tutorial you should be able to identify the various components that a migration is composed of, and explain at a basic level what each is responsible for.
There's a whole ecosystem of contributed modules that build on the Migrate API in Drupal core. They do things like provide Drush commands for working with migrations, add new sources (CSV, JSON, etc.), add new destinations, provide code examples, and fill in other gaps. Think of these as the tools of the trade you’ll use to do your work. In most cases you’ll use these to do the migration, but then once the migration is complete you can remove them from your project.
Then there are the contributed modules that add features to your site. Like Flag, Paragraphs, or Webform. These modules often contain migration-related code that is intended to help make it easier to handle data specific to these modules. There is code in the Flag module, for example, that can help with knowing how to extract flagging records from Drupal 7, and for transforming that data into the format the module expects it to be in for Drupal 10. You might end up having to tweak it a bit, but at least you’re not starting from scratch.
In this tutorial we'll:
- Look at some of the most commonly used toolset modules.
- Explain what you can expect to find in standard contributed modules related to migrations.
By the end of this tutorial you should have a better sense of the various tools available to you for authoring a migration.
Before you begin a Drupal 6 or 7 (source) to Drupal 9 or 10 (destination) migration there are a number of things you should consider. Taking the time to plan your migration will help to ensure that you're successful. In this tutorial we'll take a high-level look at:
- Evaluating your existing Drupal 6/7 site for migration feasibility
- Preparing your source Drupal 6/7 site for a migration
- Preparing the destination Drupal site you're migrating to
By the end of this tutorial you should be ready to start assessing the feasibility of performing a successful migration, and begin making a migration plan.
Planning for a migration is essential. In our collective experience we've never once seen someone sit down and execute a migration flawlessly on their first attempt. Migrations involve preparing and analyzing your source data, building a new website that data can be migrated into, and lots of testing, rolling back, and testing again, in order to get everything right. By the end of this tutorial you should be ready to start planning for your own Drupal migration project, and have a better understanding of the challenges of migrating from one system to another.
When preparing to migrate from an older version of Drupal (Drupal 7 or previous) to the latest version of Drupal (Drupal 8 or later) you'll need to determine if the contributed modules you use are ready to go. The Upgrade Status module can give you a list of all the modules installed on your site, and information about the availability of a latest Drupal version. It's not perfect, and will still require some manual research for some modules, but it is a great start towards helping you plan for your migration.
In this tutorial we'll:
- Install the Upgrade Status module and use it to generate a status report
- Review the generated report
- Talk about using the Contrib Tracker project, and other methods for getting more details about the status of upgrades for any module
By the end of this tutorial you should be able to evaluate all the installed modules on your existing Drupal site and determine the status of a module release that is compatible with the latest version of Drupal.
As new major versions of Drupal are released, contributed modules need to be updated for compatibility. As of right now (October 2021) there are a lot of contributed modules with a Drupal 8 release and a patch in the queue to make them work with Drupal 9. However, there's no official Drupal 9 compatible release for the module, so the module can't be installed with Composer. This creates a circular problem where you can't composer require
the module if you don't patch it, but you can't patch it until after it's been downloaded by Composer.
To help solve this common issue, Drupal.org provides a lenient Composer endpoint that publishes all modules as compatible with Drupal 9 regardless of whether that's true or not. By using it, you can composer require
the module and then use cweagans/composer-patches
to apply any necessary patches.
In this tutorial we'll:
- Add the lenient Composer endpoint to our project's composer.json file
-
composer require
a non-Drupal 9 compatible module - Use Composer to download and apply a patch that makes the module Drupal 9 compatible
By the end of this tutorial you should be able to use contributed modules that require a patch to be compatible with Drupal 9.
Layout Builder is one of many different approaches to handling editorial layouts in Drupal. Now that it's stable, and part of Drupal core, we expect to see it become the dominant approach over time. However, as with most things in Drupal, there are multiple ways to solve the problem of creating component based flexible layouts that can be administered via the user interface.
It's a good idea to understand the different approaches and know what's available.
When it comes to component based design and ability to construct flexible layouts, it is important to understand the benefits and risks of the most popular techniques: Paragraphs, Bricks, entities and view modes, and Layout Builder. Understanding which approach fits the needs of your project best can be critical for its success in the future.
In this tutorial we'll look at some common approaches to administering layouts in a way that gives content editors controls including:
- Drupal core's Layout Builder
- Using core's entity reference fields and view modes
- The contributed Paragraphs module
- The contributed Bricks module
By the end of this tutorial you should have a broad overview of the different popular approaches to creating editor-controlled layouts.
In their simplest form layout plugins in Drupal Layout Builder define the part of the content output that can't be changed. For example a three column layout will consist of three equal columns every time an editor decides to use it as the layout section. The editor can place whatever they want into the three columns. But they can not change the overall layout. This restricts editorial capabilities of using layout plugins since in real life a three column layout may need to consist of a wider middle column and narrower side columns, allow for column headings, or other customizations.
This flexibility is accomplished by creating, and exposing, configuration options for layout plugins in Drupal's Layout Builder. In more advanced cases, the we can take this flexibility further by exposing an interface editors to dynamically define layout plugins.
In this tutorial we'll:
- Learn how to use custom PHP classes in the layout plugin annotation
- Learn what annotations properties can be used for custom layout declaration
- Define the concept of derivatives and outline scenarios for using them
- How to declare static single layouts using YAML format
By the end of this tutorial you'll learn advanced ways of declaring configurable custom layout plugins.
A new favorite page-building and design module in Drupal's core software, Layout Builder makes it possible to create content-type-specific layouts. All nodes of the associated content type will display their content using the defined layout. This allows site builders to display a page's content in two columns, or three, or two columns with a full-width banner image, etc. Then you can place the content type's fields and Drupal blocks into the sections of the defined layout, all via the Drupal UI.
In this tutorial we'll:
- Enable the Drupal Layout Builder and Layout Discover modules
- Create a new two-column flexible layout via the user interface
- Update the Basic page content type so that all nodes use the new two-column layout
By the end of this tutorial you should know how to create a new flexible layout, and apply it to one or more content types.
When building with Layout Builder, the list of blocks available for a site administrator to place in a layout can grow and become overwhelming to navigate. This is especially true when you've got a lot of different modules enabled, as each can add new blocks. As well, complex configurations may require site admins to create more and more custom blocks. Some blocks, like certain Views, or default core blocks like "Who's online", are not meant to be used within the Layout Builder. These blocks can clutter the UI and also impact the performance of Layout Builder UI. The contributed module Block List Override is designed to help solve this problem.
In this tutorial we'll:
- Learn what the Block List Override module does
- Install and configure the module to improve the user experience when creating layouts
By the end of this tutorial you should know how to use the Block List Override module to improve the UX of the Layout Builder interface.
Layout Builder module comes with some common layouts that can be used out of the box. The Drupal community has created modules that provide more layout options. However, perhaps your project requires special layouts that cannot be constructed with already existing options. Or you require more precise control over the CSS classes and HTML markup, especially if your website is based on a third-party front-end framework. In these cases you can define custom layouts in a module or theme and make them discoverable by the Layout Builder.
In this tutorial we'll:
- Define a new layout plugin
- Create a corresponding Twig template file for HTML markup
- Use our new layout in the Layout Builder UI
By the end of this tutorial you should know how to define a new layout in code, within a module or a theme.
Layout plugins can be dynamically generated based on configuration using plugin derivatives. This allows developers to provide Drupal site administrators with a UI for creating new layout plugins, or to automatically register layout plugins based on the environment.
This is useful in situations where it's not enough to define a set of pre-configured layouts to use in the Layout Builder. Instead, you need to empower editors to declare their own new layout plugins without writing any code. Derivatives could also be used in scenarios where the layouts that should be made available depend on configuration set elsewhere in the module. Or, you might have a scenario where you want to have multiple different 2-column layouts, and for those layouts to have different names, so that they can be themed differently depending on which one is used.
In this tutorial we'll:
- Create a user interface that allows editors to dynamically define layouts via configuration.
- Learn how to set up a plugin deriver that creates layout plugins based on configuration.
- Create custom dynamic layout plugins with variable numbers of columns.
By the end of this tutorial you'll know how to declare dynamic custom layout plugins using derivatives.
When defining new layout plugins for Drupal you can add custom CSS and JavaScript via asset libraries. This allows for the creation of layouts with complex structures and interactive elements. Those elements might include grids, tabs, and accordions. Drupal allows you to attach custom CSS and JavaScript directly to a layout plugin, or via the layout's Twig template file.
In this tutorial we'll:
- Define a custom asset library with JavaScript and CSS functionality
- Attach the asset library to the custom layout plugin
- Transform a multicolumn layout into tabs
By the end of this tutorial you should know how to attach custom CSS and JavaScript to a layout plugin to add interactivity and styling.
One of the biggest UX problems with the current Layout Builder UI in core is that the control panel is often too narrow. This is especially noticeable when creating inline blocks, and working with WYSIWYG fields. The contributed Layout Builder Modal module is one solution to address this problem. It moves the UI for creating, and editing, custom blocks in a Layout into a wider modal window.
In this tutorial we'll:
- Install the Layout Builder Modal module
- Demonstrate how it can be used to improve the UX of managing custom blocks in Layout Builder
By the end of this tutorial you should know what the Layout Builder Modal module does, and determine if it's useful for your project.
The Layout Builder module for Drupal provides a layout user interface (UI), a set of flexible visual design tools that allows content creators and site administrators to customize the layout of a page via a powerful drag-and-drop UI. You can use Layout Builder to customize the layout of a single page, create a custom layout for all content of a certain type, or build landing pages.
At a high level it allows users to generate a layout -- two columns with a header, for example -- and then place a content type's fields and any blocks into that layout.
Layout Builder provides an API, and layout discovery feature, that themes and other modules can use to provide new templates. It allows more consistent tooling across the entire page-building ecosystem.
In this tutorial we'll:
- Give an overview of what Drupal Layout Builder is, and its common uses
- Introduce terminology and concepts related to Layout Builder
By the end of this tutorial you'll have a better understanding of what the Drupal core Layout Builder module does and how it might help with your specific use-case.
The Layout Builder Restrictions module allows you to configure which layouts, and which blocks, should be available in the Layout Builder UI. This helps improve the user experience by removing blocks that you don't want someone to place into a layout. It also restricts which layouts are available for a content type. For example, you may allow an editor to change the layout for a blog page but restrict them to choosing between 1- or 2-column layouts. Yet, you can still provide a 3-column layout option for use in other scenarios.
In this tutorial we'll:
- Install the Layout Builder Restrictions module
- Learn how to curate the list of layouts for use on a per-content type basis
- Restrict the list of blocks available for placement via Layout Builder's UI
By the end of this tutorial you'll know how to use the Layout Builder Restrictions module to curate the list of layout and block options available to editors in the Layout Builder UI.
When building a site using Drupal's Layout Builder, it's a good idea to keep the number of layout plugins manageable. In many cases it's better to create a single layout plugin that can be re-used rather than duplicate a layout multiple times to accommodate minor variations. One way to do this is provide editors with configuration options that will change the output when a layout is used.
For example, imagine you need to provide variations of a 3-column layout where the columns are different widths. You could define a new layout for each variation. Or you could define a single layout with a configuration option that allows a user to choose the column widths. The latter approach reduces code duplication, and makes the codebase easier to maintain.
In this tutorial we'll:
- Learn how to declare advance layout plugins with configurable settings in the Drupal Layout Builder
- Extend the
LayoutDefault
class and create a custom settings form that editors will see when using a layout - Use the provided configuration values in the layout's Twig template file to modify the layout when it is rendered
By the end of this tutorial you should be able to expose layout-related settings to editors, allowing for more flexibility in custom layout plugins.
The Layout Builder module allows editors to create flexible layouts per content type, and per node. When configured to allow per-node layout customization, each node inherits the base layout for the content type. But editors can choose to further customize the layout on a node by node basis. This allows them to tailor the layout to better suit the specific node, and to have presentation flexibility that can be managed through Drupal's UI instead of in code. This also makes it harder to enforce design consistency, and future updates to the content type specific layout won't be applied to pages using a node specific layout.
In this tutorial we'll:
- Learn how to enable node-specific layouts
- Create a custom layout that is used on only one page
By the end of this tutorial you'll understand how to configure per-node-specific layouts.
The Layout Builder Styles module extends the Drupal core Layout Builder UI to add the ability for editors to apply custom CSS classes to the blocks and sections that make up a layout. This gives layout editors more control over the look and feel of elements within a layout. It's especially useful when using Drupal's Layout Builder in conjunction with a design system like Bootstrap, Material UI, or your own predefined utility classes.
The module allows site builders to define new styles. Then, when placing a block into a layout, if there are any styles available for the block type, the user is presented with a select list where they can choose one or more to apply. When a style is applied, any CSS classes associated with the style are added to the markup. Also, a new style-specific theme hook suggestion is added to the block to allow for further customization.
In this tutorial we'll:
- Install and configure the Drupal Layout Builder Styles module
- Learn how to define new styles
- Learn how anyone editing a layout can apply the styles we defined to a block or section in the layout to change the UX
By the end of this tutorial, you should be able to use the Layout Builder Styles module to allow editors to add predefined styles to existing layouts and blocks without writing any code.
Like many things in Drupal, there are multiple ways to solve the same problem when using Layout Builder. The Layout Builder system is very flexible. In order to be successful when using it, it helps to plan ahead and think through your specific use-case. Picking a pattern, and sticking to it, will help ensure your configuration is more maintainable, and easier for others to understand. While there's nothing to prevent you from mixing and matching, in our experience we've found it's helpful to at least set some ground rules.
In this tutorial we'll outline 3 different patterns to use with Layout Builder, and the pros and cons of each. We'll include:
- Using content fields in scenarios where a few pages use Layout Builder, but the majority of the site's layout is done via the theme and is generally not configurable by editors.
- Using a blocks-based approach to layouts for scenarios where you want to use Layout Builder instead of the traditional blocks and regions approach and allow editors to make changes via the UI.
- And finally, using an Entity view modes approach for sites that rely heavily on Layout Builder and contain lots of interrelated content types with complex layout requirements.
By the end of this tutorial you should have a better understanding of how to approach using Layout Builder for your specific use-case, and the advantages and disadvantages of different common patterns.