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 requirea 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.
In this tutorial, we'll walk through the process of adding and configuring filters and adding a filter group.
In this tutorial, we'll walk through the process of adding and configuring sort criteria to a view.
In this tutorial, we'll add and configure a contextual filter for a view. Our Baseball Awards content type has a field Year. We'll make it possible for a page to be dynamically created on our site that contains the year and lists the awards for that specific year. To do this, we'll add a contextual filter to the Baseball Awards view that will allow visitors to filter the list of awards by the award year. We'll also add a block using the summary view contextual filter configuration, which visitors can use to view results for specific years.
One of the ways you can create a REST endpoint in Drupal is by using Views. In this tutorial, we'll add a REST endpoint display to a view of baseball players. We'll examine and configure settings that are unique to the REST endpoint display.
By the end of this tutorial you should be able to:
- Add a REST endpoint display to a view
- Understand how to configure settings for an endpoint
Instead of providing multiple views with different filter criteria, consider empowering your users by exposing filter criteria as an interactive form. You can even configure the forms to use AJAX to refresh results. In this tutorial, we'll walk through the process of adding and configuring exposed filter or sort criteria in a view.
Like exposed filters, we can expose sort criteria to the site visitor. Exposing sort criteria gives the visitor more control over the list of content they are viewing. In this tutorial, we'll configure our view of baseball players to allow visitors to sort the list in different ways by adding several exposed sort criteria.
Contextual filters are a Views mechanism for dynamically refining the contents of a view. It might be helpful to think of them as "dynamic filters". In this tutorial, we'll discuss the concept of context, look at how to add contextual filters in the Views UI, and review the Taxonomy term view that comes with Drupal and how it uses a contextual filter.
Exposing filter criteria allows the users of your site to choose how to filter a content list created in Views. When rendered on the page, the exposed filters will be displayed to the user as interactive form components.
By the end of this tutorial you will:
- Understand what it means to expose filter criteria and when it might be useful.
- Be able to identify when a view has exposed filters and which filters are exposed.
Exposing sort criteria allows the users of your site to sort a view using an interactive form.
By the end of this tutorial you will:
- Understand what it means to expose sort criteria and when it might be useful.
- Be able to identify a view's exposed sort criteria.
With filters, we can define query conditions and refine the results of a view. But what is a filter and how do filters work in Views? In this tutorial, you'll learn:
- How to add and configure filter criteria to a view to refine results
- What configuration options are available for filter criteria operators
- How filter groups allow you to group and order filter criteria to achieve desired results
By the end of this lesson, you should understand how to use and configure filter criteria in Views to refine the results of your view. (Note: We'll cover exposed filters in Overview: Exposed Filter Criteria in Views)
In order to display values for referenced entities in views, you need to add a relationship. What is a relationship, how do they work, and what does it mean to require this relationship? What are some common use cases for adding a relationship to a view? By the end of this tutorial you should be able to:
- Explain some common use cases for adding a relationship to a view.
- Understand the concept of entity references and how those field values can be displayed in a view.
With sort criteria, we can specify how to order our list. We can specify sort criteria using any field on or related to our view's base entity, and then specify in which order to sort, e.g. ascending or descending. If you are familiar with MySQL, it may be helpful to know that sort criteria are the ORDER BY clause of the query that Views builds. In this tutorial, you'll learn:
- How to add and configure sort criteria to a view to sort the list in various ways
- What configuration options are available
By the end of this lesson, you should understand how to use and configure sort criteria in Views. (Note: We'll cover exposed sort criteria in Overview: Exposed Sort Criteria in Views)
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 you understand the purpose of relationships in Views, let's add a relationship to a view so that we can access and display a field value from a related entity.
In this tutorial, we'll modify the Player Awards view to add a relationship to the player that received the award. Then we will add a field that belongs to the player content that would normally not be available to the view without our new relationship.
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.