Media source plugins provide the link between media entities in Drupal and the actual media asset itself. They are the code that understand the difference between an image, a video, and a Tweet, and perform the translation that allows the media ecosystem to treat all media entities equally. For example, local image files, and remote YouTube videos, can both be catalogued in a similar way as media entities, but they need very different handling when it comes to displaying them.
Media sources are represented as plugins, there are a handful in Drupal core, and a developer can add new plugins to represent any type of media your application needs to catalogue.
In this tutorial we'll learn:
- How media source plugins relate to Media Types
- The responsibilities of a media source plugin
By the end of this tutorial you should be able to define the role of a media source plugin and understand what's required to define your own.
The Drupal core Media Library module provides an enhanced user interface for locating Media entities and attaching them to an article. It's a drop-in replacement for the default entity reference widget which uses a not very intuitive autocomplete field. Using the Drupal core Media Library module requires minimal configuration.
If you want to provide content creators with a gallery-like library of Media entities that they can browse through in order to find the ones they want to add to their content, the Media Library is the easiest way to do it. It can be configured to work with both Media fields and the CKEditor powered WYSIWYG editor commonly used for editing the body field of Drupal nodes. There's really no reason not to use it.
In addition to providing a better UI for locating existing Media entities, the Media Library provides a way to create new Media entities right from the content creation form. This prevents an otherwise confusing requirement where Media entities need to be created, via a different set of forms, before they can be used.
In this tutorial we'll:
- Install and configure the Media Library module to work with Media fields
- Use the user interface provided by the Media Library to improve the experience of finding and selecting Media entities to associate with a piece of content
By the end of this tutorial you'll know how to replace the default entity reference widget used for selecting Media entities with the much improved Media Library UI.
Media entities, like any content entity, work great with all the different features Drupal provides for changing the way things are displayed: view modes, Layout Builder, theme templates, and more. We're big fans of using view modes to create a component-like design system where entity types have view modes representing the different context in which they're displayed. Then we theme the view modes. This works great for displaying Media entities associated with a page and for changing the way that Media assets are displayed within the Media Library browser.
In this tutorial we'll:
- Create Hero and Sidebar view modes for Media entities
- Configure the Image Media type to use the new view modes and style each one differently
- Use the new view modes to render Image Media assets within a Layout
- Update the Media library view mode that's used by the Media Library browser to display additional information alongside the thumbnails used when selecting Media to attach to a page
By the end of this tutorial you should be able to change the way that Media assets are displayed by using view modes and display formatters in a Drupal site.
Drupal 8.8.0 introduced a bunch of new features intended to make it easier over the long-term to maintain a Drupal project using Composer. In doing so it establishes some new best practices, and moves into Drupal core solutions that were previously maintained by the community. This is all good news. But, it means if you're using Composer to update from Drupal 8.7.x or lower to 8.8.0 or higher you'll need to do a bit of additional work to untangle everything.
This tutorial is especially useful if you started your Drupal project using the drupal-composer/drupal-project
template and would like to convert to use the new templates (i.e. drupal/recommended-project
or drupal/legacy-project
) included with Drupal 8.8.x core.
In this tutorial we'll:
- Convert our project to use the new
drupal/core-recommended
, anddrupal/core-dev
Composer packages - Explain which commonly used Composer packages are deprecated, and which new ones replace them
- Learn how to use the
drupal/core-composer-scaffold
Composer plugin - Cover tips for troubleshooting updates
Furthermore, in order to Upgrade to Drupal 9 from Drupal 8, you will first need to update your Drupal 8 site to at least version 8.8, as the upgrade paths for Drupal 8 site from before Drupal 8.8.0 have been removed from Drupal 9.
By the end of this tutorial you should be able to update your Drupal projects using Drupal core 8.7.x or lower to Drupal core 8.8.0 or higher using Composer. And be ready for an upgrade to Drupal 9.
Drupal's development has a regular release cycle consisting of major, minor, and patch releases. Drupal releases use semantic versioning for its version numbers. Since we're committed to making sure our tutorials are kept up-to-date with the latest and greatest version of Drupal we figured it would be a good idea if you knew how to keep your Drupal site up-to-date with the latest "point" releases as well.
This tutorial will cover:
- How to determine the type of update
- The standard update procedure
- Update Drupal using Drush
- Update Drupal using Composer
This tutorial won't cover:
- How to perform a major version Drupal upgrade, for example, from Drupal 6 or 7 to the latest version of Drupal. For that, see our guide, Learn to Migrate to Drupal.
Upgrade to Drupal 10
FreeThere’s no one-size-fits-all path to upgrade from Drupal 9 to Drupal 10, but there is a set of common tasks that everyone will need to complete.
In this tutorial we’ll:
- Explain the differences between Drupal 9 and Drupal 10 that affect the upgrade path.
- Walk through the high-level steps required to upgrade from Drupal 9 to Drupal 10.
- Provide resources to help you create an upgrade checklist and start checking items off the list.
By the end of this tutorial you should be able to explain the major differences between Drupal 9 and 10, audit your existing Drupal 9 projects for Drupal 10 readiness, estimate the level of effort involved, and start the process of upgrading.
Upgrade to Drupal 9
FreeThere’s no one-size-fits-all path to upgrade from Drupal 8 to Drupal 9, but there is a set of common tasks that everyone will need to complete.
In this tutorial we’ll:
- Explain the differences between Drupal 8 and Drupal 9 that affect the upgrade path.
- Walk through the high-level steps required to upgrade from Drupal 8 to Drupal 9.
- Provide resources to help you create an upgrade checklist and start checking items off the list.
By the end of this tutorial you should be able to explain the major differences between Drupal 8 and 9, audit your existing Drupal 8 projects for Drupal 9 readiness, estimate the level of effort involved, and start the process of upgrading.
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.
Modules like Devel or Stage File Proxy offer key advantages when developing locally, but should never be enabled on a production site. This poses a problem for Drupal as which modules are enabled is a configuration. Compounding this problem is the configuration provided by these modules, as well as key configuration that must be set differently locally compared to production.
Fortunately, the Configuration Split module provides a means to accomplish all of these goals. Once set up, configuration can be exported in one or more "splits", enabling you to target different configurations for different environments or situations.
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.
Drupal's configuration system helps to solve the problem of moving changes in configuration from development to production. It does this in two ways: by providing a unified way to store configuration and by providing a process by which configuration changes can be imported and exported between instances of the same site. The configuration system is the result of work completed within the Configuration Management Initiative (CMI).
In this introduction, we'll provide:
- An overview of Drupal's configuration system
- Key concepts that you should know about
Using Drush to work with the Drupal Configuration System is straightforward when working locally. Navigate to the directory containing your site, then issue whatever Drush command you need.
Things become more complicated when multiple environments become involved. Often, a configuration change will need to be made on the production ("live") site and then need to be persisted to a Git repository later. When this occurs, Drush once more provides a solution in the form of the config-pull
subcommand.
Note: Drush 8 and the latest version use different methods and file types for configuration files. This tutorial will demonstrate methods that are compatible with the latest version of Drush with notes related to Drush 8.
There are some administrative UI tools for managing configuration, but some tasks can only be completed with Drush. As a site administrator, you will find Drush an indispensable tool for managing configuration between instances of the same site. Furthermore, Drush includes integration with Git in certain commands, enabling you to create a configuration workflow with Drush that also uses best practices in version control.
By the end of this lesson you should be able to:
- Get the status of a site's configuration
- List configuration on a site
- View configuration objects
- Set values for a specific key inside a configuration object
- Edit a configuration object in active configuration without needing a configuration form
- Integrate a Git workflow with Drush
The Configuration Manager module gives you as an administrator the ability to import and export configuration items on different instances of a Drupal site using a graphical user interface. In this tutorial, we'll take a tour of the Configuration Manager and the administrative interface it provides.
By the end of this lesson you will be able to:
- Access administrative pages for Import, Export, and Synchronize
- Find and configure permissions for Configuration Manager
- Identify the 3 primary actions of configuration management and how to perform them using the UI
While the administrative UI for Configuration synchronization certainly provides a simple and effective means to export and import configuration, it is by no means the preferred method. The Drush command line utility provides the same functionality without the need for a web interface or the need to log in.
The real power of the Workflows module is the fact that you can define your own custom workflows. Creating a new custom workflow requires adding a new workflow, and configuring the states and transitions that workflow will use.
In this tutorial we'll:
- Create and configure a new workflow
- Define and configure a set of states and transitions for the workflow
- Understand some best practices to keep in mind when defining workflows
By the end of this tutorial you'll be able to define your own custom workflows for any use-case.
The Content Moderation module exposes data about a content item's moderation state to Views. That allows us to use that information when building custom views. The data includes a moderation state field, filter, and a relationship to the moderation state entity.
In this tutorial we'll:
- Build a new view that uses the moderation state field and lists all revisions for a content item
- Display that view as a block which can be shown on any content page
By the end of this tutorial you'll know how to use the moderation state field in a view.