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.

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.

In this tutorial, you'll learn how to add a property to a configuration entity type in Drupal. Previously, we created a configuration entity type called video_preset and, using Drush, scaffolded the files and code to define a custom configuration entity type. Now, we'll add a new property called codec to this configuration entity type and update the code we created in the previous tutorial.

To add this new property to our custom configuration entity type, we need to update our schema file, configuration entity forms, the entity list builder class, and add getter and setter methods to our ConfigEntityType class.

In this tutorial, you'll learn about the two types of configuration data: simple configuration and configuration entities. By the end of this tutorial, you should have a better understanding of which type of configuration to use in your module.

In this tutorial, we’re going to walk through the process of creating a custom configuration entity type in Drupal in a custom module. We'll be using Drush's generate entity:configuration command to create and update the files in our example module. After Drush has generated and updated the files for our configuration entity, we'll walk through each file and see how they define data structure, metadata, an administrative interface, and menu links for a configuration entity in Drupal.

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

• Use Drush to generate a configuration entity type
• Identify files associated with a configuration entity and summarize the purpose and function of the code inside each file

When you are developing a module in Drupal, you can make certain functionality user-configurable. You can see this on Extend (admin/modules) in Drupal's administrative UI by looking for the Configure link near the module's description. To accomplish this, your module needs to define default settings in config/install/transcode_profile.settings.yml, create a settings form that will read those settings as the values for corresponding form fields, and update the settings when the form is submitted with updated values.

In this tutorial, we'll create a settings form that will be used as the module's Configure link in the Extend UI, as well as a menu link in an appropriate place in the administrative area. We'll use Drush, a command-line utility for Drupal, to speed up the process. We'll also create a default settings YAML file so that the settings form has something to read and update.

By the end of this tutorial, you should be able to get a configuration form up and running inside a custom module that will read and update a configuration object's values.

As we learned in Configuration Data Types, simple configuration is suitable for storing module settings as boolean values, integers, or text strings in one or more key/value pairs. In this tutorial, we'll walk through creating a schema and providing default configuration to store initial settings that a module needs to function.

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

When working on configuration in a module, whether as part of a migration that uses Migrate Plus configuration entities, or while developing custom configuration entities, you'll often need to re-import the configuration stored in the .yml files of the modules config/install/ or config/optional/ directories. This is tricky though, because Drupal only reads in those default configuration settings when the module is first enabled. So any changes you make to those files after the module has been installed will not be reflected without these workarounds.

Knowing how to do this can improve the developer experience of adding (or debugging) the default configuration that's provided with a module. Or for anyone using Migrate Plus configuration entities as part of a migration.

In this tutorial we'll:

• Learn about the Configuration Development module
• Look at how you can use Drush to perform a partial configuration import
• Write an implementation of hook_uninstall() to remove a module's configuration when it's uninstalled

By the end of this tutorial you should be able to re-import the configuration provided by a module without having to uninstall and then reinstall the module.

Now that we have some default simple configuration stored in a settings YAML file, let's utilize it in a form that our site administrators can use to update those values. We'll make use of some services and methods in Drupal's Configuration API in order to retrieve, update, and save simple configuration values with a form.