Drupal media entities are fieldable entities, which means that you can add any custom fields you want to your Media types. These fields can be used for collecting additional metadata about a resource, categorizing and organizing resources so they're easier to find in a large media library, or for displaying information like a photo credit or transcript for a video. The possibilities are endless once you know how to add, and optionally display, fields in Drupal.
Some example use cases for adding fields to Media types:
- Collect, and display, a credit to go along with a photo. This could also be a date, a location, or any other metadata.
- Store resource width and height dimensions as custom fields so they can be referenced by display logic in the theme layer.
- Use Taxonomy reference fields to add tags or categories to help keep a large library organized.
In this tutorial we'll:
- Learn how to add fields to a Media type
- Verify our new custom field is working
By the end of this tutorial you'll know how to add custom fields to any Media type.
The most common way to use Drupal's Media items is to add fields to content types, allowing the Media entities to be associated with one or more pieces of content. For example, adding a cover image to an article, or embedding a set of YouTube videos into a tutorial. This is accomplished by adding a Media field to the content type in question.
In this tutorial we'll:
- Explain what the different Media field-specific configuration options do
- Add a Media field to the existing Article content type
- Explain what the different field-specific configuration options do
- Confirm that it worked by verifying that the form for adding an article has the new field
By the end of this tutorial you'll know how to add a Media field to any content type, or any other fieldable entity, in order to allow Media items to be associated with the content.
Media entities in Drupal are content entities, and can be administered like most other Drupal content entities. In most cases you'll likely add new Media entities via the Media Library widget when creating a new content entity like an Article. However, it's possible to add them to the library without having to attach them to a piece of content. You may also want to update an existing Media entity, or just search the library to see whether something already exists.
In this tutorial we'll:
- Learn what a Media entity is in Drupal
- Get an overview of the main Media management page
- Learn how to add, edit, and delete, Media entities
- Learn how to bulk edit Media entities in Drupal
By the end of this tutorial you'll know how to perform basic find, add, edit, and delete operations to manage the Media entities in your library.
Drupal site administrators can create new media entity types, with their own unique configurations and sets of associated fields. Different media types can be configured with different field names, permissions, moderation workflows, and display settings, making it possible to create truly custom content administration experiences. The process is similar to creating a node content type like articles or events with one major distinction: every media type inherits from a specific media source plugin. The source plugin provides domain-specific knowledge about the kind of resource being represented. For example, the Remote video source plugin used with the default Remote video media type knows how to consume and display videos from YouTube and Vimeo given only their URL.
Drupal core comes with a couple of common media source plugins, and contributed modules and custom code can add to this list, increasing the different media providers with which Drupal can integrate.
In this tutorial we'll learn how to:
- Install a contributed module that provides a new media source plugin.
- Create a new media type.
By the end of this tutorial you should be able to explain how source plugins relate to media types, and create a new media type.
The Drupal Media Library and Media ecosystem can be integrated with any third-party media provider by defining new media source plugins. Media types (Media entity bundles) have an important distinction compared to other content entity types like nodes. Every media type inherits from a specific media source plugin. The source plugin provides domain-specific knowledge about the kind of resource being represented. For example, media types dealing with images know how to validate file extensions and render <img>
tags. Media types dealing with remotely hosted videos might know how to retrieve thumbnails from a remote API, and display an HTML video player and transcript.
In this tutorial we'll learn how to:
- Define a new source plugin
- Integrate a third-party API via its existing PHP library
By the end of this tutorial you should be able to create a new source plugin that exposes any third-party media resources you want to integrate with Drupal.
If the Media assets you want to use in your library support oEmbed, then you might be able to use them with a minimal custom code. Before you go down the path of creating a custom media source plugin try this approach first.
oEmbed is a standard way of allowing third party sites to embed an asset represented by a URL. The Remote Video source in core uses the oEmbed features of YouTube and Vimeo. When you paste a link into a Slack channel and it displays a pretty card preview, or an embedded video or Spotify playlist, that's oEmbed in action. Does the Media you want to embed have a canonical URL? If so, paste it into the tool here and see if it displays oEmbed info in the results.
In this tutorial we'll:
- Learn how to enable additional oEmbed providers as Media sources
- Use the contributed oEmbed Providers module for compatible providers
- Demonstrate how to create a custom oEmbed media source plugin to further customize the results
By the end of this tutorial you should be able to embed any oEmbed-compatible content as Media assets in Drupal.
When using the Drupal Media Library to browse for available Media entities to attach to your content, the interface that you see inside the modal window is created using Views. This means you can change it for your specific use-case. This is most useful when you want to expose filters for custom fields to allow users to more easily locate content in your library. As your library of media grows, you can create powerful application-specific ways for content authors to segment the list and find their assets.
In this tutorial we'll:
- Learn how to edit the Views used by the Drupal Media Library browser
- Add a new exposed filter for the custom tags field on some media entities
- Demonstrate how this change affects the user interface for locating and selecting media
By the end of this tutorial you should be able to customize the View used by the Media Library to add new filters and make other use-case specific changes.
Media Source plugins in Drupal have a powerful feature, called field mapping, that allows an administrator to configure a Media entity type to automatically populate the value of custom fields based on metadata retrieved from the source content. For example, you can add a creator field to the Remote Video Media type, which can use YouTube as a source. When a content author adds a new Remote Video entity they can provide a URL for the YouTube video. Then the source plugin can extract the creator's name from the YouTube API and use that data to populate a custom field. This saves the content author from having to do that work themselves.
In this tutorial we'll learn:
- How to discover what source metadata is available
- How to configure a Drupal Media type to automatically populate custom fields
By the end of this tutorial you should be able to add a custom field to a Media type on your Drupal site and automatically populate it with data retrieved from the source content.
One of the most powerful features of Drupal's Media Library is that it enables content authors to re-use media entities. Have a favorite image that you like to use with all blog posts about a specific topic? Or a default icon you want to use for a tutorial unless an alternative is provided? The Media Library can accommodate this without requiring you to keep a copy of the image locally and then attach it to every node where it's needed.
This can lead to a potential issue when an editor deletes an image, thinking they've also deleted all the content that used it. If they missed a post referencing the now deleted image, what happens when there is no image to show?
The contributed Entity Usage module provides a mechanism for tracking relationships between entities. This is essential functionality when working with a library of reusable media entities because it helps ensure that media entities attached to content are not deleted.
In this tutorial we'll:
- Discuss the use case for the Entity Usage module
- Learn how to configure Entity Usage to keep track of relationships between media entities and nodes that reference them
- Prevent media items from being deleted if they are in use somewhere on the site
By the end of this tutorial you should be able to explain what the Entity Usage module does, and how to use it to solve common problems related to deleting items from a large Media library.
A commonly asked question is, "How do you add images to the body of a content item in Drupal?" You can allow users to embed images, videos, or any other media into a field configured with a WYSIWYG editor, such as CKEditor. In this tutorial, we’ll show you how to enable Drupal’s Insert Media button for CKEditor, and configure the corresponding text format so that it can render embedded Media entities.
Content authors can then use the Media Library to select images (or other media) to embed into the page.
In this tutorial we'll:
- Learn how to enable the Insert Media button for CKEditor
- Demonstrate how to insert media into the body of a content item (or any other field configured to use CKEditor)
By the end of this tutorial you should know how to configure Drupal to allow content authors to embed images in content items.
Drupal's media management tools, the Media and Media Library modules, provide content authors with drag-and-drop media and asset handling, full WYSIWYG editor integration, and a library of reusable media assets. There's minimal configuration required to get started, but full control via Drupal's standard Entity and Field systems for those who need it.
In this tutorial we'll:
- Provide an introduction to the media system in Drupal and its use-cases
- Explain the Drupal core features that the Media system is built on
- Link to other tutorials that will go into much more depth on these topics
By the end of this tutorial you should know what role the Media and Media Library core modules fill and know whether or not you'll want to make use of them on your project.
Media entities are standard Drupal fieldable content entities. For the most part, they function, and are managed, in the same way as Nodes. So if you've previously created content in Drupal, much of working with Media entities should be familiar -- with some notable exceptions related to the connections between Media types and the media resources they represent.
In this tutorial we'll:
- Get an overview of Media entities, Media types, and Media fields in Drupal
- Point to other tutorials that go into more depth on individual topics
- Learn some basic terminology and concepts related to the Media system in Drupal
By the end of this tutorial you'll have an overview of the pieces that make up the Media system in Drupal core.
Note: This tutorial is specific to Drupal sites hosted on the Acquia platform and covers integrating its features to improve performance.
The Acquia platform includes Memcache, Varnish, and Content Delivery Network (CDN) integration. In order for these to be as effective as possible, they should be configured and tuned for your specific use case. This tutorial provides an introduction to these utilities and common configuration. For more detail, you should consult the Acquia documentation.
In this tutorial, we'll:
- Learn what caching utilities are included in the Acquia platform
- Set up and tune different parts of Acquia's application caching level including Memcache and Varnish
By the end of this tutorial, you'll know what application-level caching options exist on Acquia's platform. And how to configure it, and your Drupal application, for better performance.
WebPageTest (webpagetest.org) is a free open source resource that runs performance tests on a site, provides educational reports about what it finds, and suggests optimizations you can make. The tests performed via the WebPageTest interface include Lighthouse tests, performance-specific tests, Core Web Vitals, visual comparisons, and traceroute tests. The tool also allows saving a history of tests if you sign up for a free account. This tool won't make your site faster on its own, but it will give you some good ideas about where to focus your efforts.
In this tutorial we'll:
- Learn how to run performance tests via the WebPageTest web interface
- Learn how to read and interpret the results
By the end of this tutorial, you should know how to use the WebPageTest online interface to analyze a Drupal site's performance.
Lighthouse is an open source, automated tool for analyzing your site's performance. Lighthouse is built-in to the Google Chrome browser. When auditing a page, Lighthouse runs various tests against the page and then reports how well the page did across a broad spectrum of metrics. While Lighthouse doesn't improve the performance of a Drupal site itself, it helps to establish a performance profile and point towards areas that could be improved.
Lighthouse requires the use of Google Chrome. Other browsers include their own performance auditing tools. While the exact usage of each tool varies, the end result is the same: a report that can be interpreted to suggest where to focus your performance-tuning efforts.
In this tutorial, we'll:
- Learn how to run Lighthouse tests against a Drupal site
- Interpret the results of the report generated by Lighthouse
- Provide guidance on next steps to take to address the performance issues Lighthouse finds in our Drupal site
By the end of this tutorial you should be able to use Lighthouse to profile a Drupal site, interpret the results, and know where to start on making improvements.
Apache Bench (ab
) is a tool that comes with the commonly used Apache HTTP server. It is designed to give you an impression of how your current Apache installation performs. It will work for any HTTP server, not just Apache. Apache Bench shows you how many requests per second your server can serve. This metric is in part a measure of how long it takes Drupal (PHP) to process the request and create a response. While there are other things that the HTTP server does too, executing PHP is by far the most expensive when serving Drupal pages.
Therefore, Apache Bench helps profile your PHP code for new features, patches after their application, and PHP libraries used on the site. You can quickly compare before and after metrics as an indicator of the scale of the impact a change has.
In this tutorial, we'll:
- Learn how to run the Apache Bench tool on our local environment
- Learn to interpret the result of the tests
By the end of this tutorial, you should know how to benchmark and profile your local Drupal installation using Apache Bench (ab
).
Sites evolve over time. We're constantly adding and removing modules, modifying content, authoring custom plugins, and changing design elements. All of these changes impact our application's performance -- some more so than others. But if you're not measuring it, you can't know when your site inadvertently gets slower or by how much.
If you are responsible for a site's performance, it might be good to look into benchmarking it and establishing a performance budget early on, then monitor it on an ongoing basis. Many tools, paid and free, allow measuring key web performance indicators and backend code and server performance.
One-time measurements can be useful for immediate debugging, or when figuring out if that big new feature is going to have a negative impact on performance. But for long-term projects, it's helpful to have known baseline values and an established performance budget to see whether your performance improves or declines over time with every new feature.
Establishing the baseline (performance budget) and comparing future measurements is called site performance benchmarking.
In this tutorial, we'll:
- Learn the basics concepts of benchmarking
- Learn a benchmarking process and best practices
- List some commonly used tools for benchmarking Drupal
By the end of this tutorial, you should understand the concept of a performance budget, know when to benchmark your site, and list some tools available to help.
Pantheon uses its Object Cache and Global CDN services to help improve the performance of your Drupal sites. Using them requires a few steps to enable the services and configure your Drupal site to use them effectively.
Many performance optimizations are hosting-provider-specific. This tutorial covers some Pantheon-specific methods for increasing your Drupal site's performance. It's only relevant if your site is hosted on Pantheon. For other common providers, and generic performance tuning tips, refer to other tutorials in this course.
In this tutorial we'll:
- Learn how to configure and use Pantheon's Object Cache to speed up Drupal caching
- Learn about the use case for Pantheon's Advanced Page Cache module
- Install and configure the Advanced Page Cache module for better Drupal caching of sites hosted on Pantheon
By the end of this tutorial you should be able to explain when and why you would want to use Pantheon's Object Cache and Advanced Page Cache modules, and how they can help speed up Drupal sites hosted on Pantheon.
Over the history of the Internet, the single Page Speed metric evolved into various parameters that influence user experience. These metrics are commonly referred to as Core Web Vitals. Together, they paint a comprehensive picture of the performance of your site from an end user's perspective. These metrics are considered by Google and other search engines when assigning SEO scores.
Knowing what these metrics are, and what they are intended to measure, is an important part of creating a performance profile for your site. This knowledge can also help you find solutions for common performance issues.
In this tutorial, we'll:
- Define the metrics that make up the Core Web Vitals
- Point to additional resources where you can learn more about each metric
By the end of this tutorial, you should know which performance metrics are considered Core Web Vitals and what aspects of site performance they cover.
The performance optimization settings and modules provided by Drupal core are intended to work for the broadest possible set of use cases. From an administrator's perspective they provide minimal configuration options, and are designed to just work by being enabled. But behind that simplicity are some powerful features that will help speed up any Drupal-powered application.
The core Dynamic Page Cache and Internal Page Cache modules are designed to provide a base cache setup for any site. These modules are responsible for the static page cache, dynamic page cache, and lazy loading optimizations.
For developers, Drupal provides a complete and well-designed Cache API. You can, and should, integrate it into your custom code. This integration includes defining the cacheability of any content your module outputs so that Drupal can be smart about how that affects how and when a page that incorporates the output can be cached -- as well as storing and retrieving the results of complex or long-running operations. The API also helps with setting appropriate HTTP headers for the responses Drupal generates for each request so that the user's browser and other layers in the stack can appropriately cache the output.
The entire system is flexible, and there are many contributed modules that can aid in making the default caching system even faster for specific use cases.
In this tutorial, we'll:
- Learn about the caching-related modules in Drupal core
- Review the Drupal core performance settings and recommended values
By the end of this tutorial you should be familiar with the Drupal core modules responsible for caching, their settings, and recommended values.