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.

Often, there's an existing Drush command that does most of what you want, but needs just a few tweaks or enhancements to make it meet your project requirements. Maybe the existing core Drush command has the functionality but lacks some additional validation. Or maybe you need to add an option to perform some application-specific debugging logic for all commands in a group.

Drush hooks can be used to alter, extend, and enhance existing Drush commands.

In this tutorial we'll:

• Learn how to alter a Drush command with code in a custom module
• Declare a validation hook that alters the user:password command with additional password validation logic

By the end of this tutorial you should be able to alter a Drush command provided by Drush core or a contributed module with your own custom code.

Back-end developers, and Drupal site builders, often find themselves having to perform the same UI steps over and over again, like exporting configuration, importing configuration changes, running cron, processing a large queue of jobs, indexing items for Search API, and more. Performing these tasks with Drush saves time and reduces the number of clicks required.

Drush core contains commands to execute all the most common tasks. Many contributed modules provide their own Drush commands to make interaction with the module's features, easier, faster, and scriptable.

In this tutorial we'll:

• Learn about the Drush core commands for common tasks like interacting with queues, performing database backups, and importing/exporting configuration
• Demonstrate how to find the Drush commands provided by contributed modules in your project

By the end of this tutorial you'll learn some popular commands for common tasks that'll speed up your daily work.

Every Drupal site consists of many Drupal projects like modules and themes. Drush comes with a group of commands that aid in managing projects from the command line. These commands can check which modules are present in a site's codebase, report their security status, enable modules, and display metadata for modules and themes. All of these commands start with the pm prefix, and are part of the project manager group.

Common use cases for the project manager commands include: quickly enabling/disabling modules via the CLI rather than performing numerous clicks in the UI, and as part of CI/CD process that lists (or maybe even automates) security updates.

In this tutorial we'll:

• List the available pm commands
• Enable a module with Drush
• Uninstall a module with Drush
• Use Drush to check for security updates for modules, themes and PHP packages

By the end of this tutorial you'll have an understanding of the project manager commands that come with Drush, how to use them, and how to speed up common workflows and maintenance tasks.

Administration and maintenance of Drupal websites consists of many tasks that can both be performed via the command line, and automated, with Drush. Using Drush's site and environment administration commands you can run database updates, check an environment's status, clear (rebuild) the cache, perform Cron-related operations, and manage users. These tasks are repetitive, often require many steps in the UI, and may be tedious in the long run. Learning to execute them with Drush can save you time and allows for more automation of common tasks.

In this tutorial we'll:

• Use Drush to check a site's status
• Learn how to perform database updates with Drush
• Clear the Drupal cache with Drush
• Use Drush to execute Cron tasks for a Drupal site
• Learn how to use Drush to login to a site as any user, and manage existing users

By the end of this tutorial you'll be able to perform many common Drupal environment and administration tasks from the command line with Drush. We're not going to cover all of the environment management commands in this tutorial, just some of the more popular ones. We encourage you to explore further on your own.

Drush, aka The Drupal Shell, is a command line utility and UNIX scripting interface for Drupal. It allows access to common Drupal features and tasks via the command line. It can help speed up common tasks for Drupal site builders, developers, and DevOps teams. Among other things, it makes it easier to integrate Drupal into CI/CD workflows.

In this tutorial we'll:

• Learn what Drush is and what can be done with Drush
• Install Drush
• Find a list of Drush commands
• Learn how to execute commands

By the end of this tutorial, you'll understand how to install and use Drush with your Drupal projects, navigate the list of its commands and run them. This is intended as an overview. Other tutorials will provide more detail about common commands and use-cases.

Make your custom Drush command more flexible by allowing users to pass command line arguments into it. For example, rather than hard-coding that the command lists users with a specific status, allow the desired status to be specified at run-time. This allows the command's logic to be more generic, and to return different results, or operate on different data, based on the provided parameters.

Parameters are variables that are passed from user input at the command line into the Drush command method. Typically, they are either single string values, or comma-delimited strings of values. Parameters are typically used to provide input for the command related to what the command should work on, in contrast to options, which are typically used to configure how the command works.

In this tutorial we'll:

• Declare parameters for a custom Drush command in its attributes
• Use the parameter input inside the custom Drush command method

By the end of this tutorial you should understand how to work with parameters inside custom Drush commands.

When you create a custom Drush command it might be useful to allow users to pass options (predefined values) that change the way a command works. You can think of options as being flags, or variables, that affect the command's internal logic. As an example, consider the Drush core user:login command which by default returns a one-time login link for the root account. The command also accepts an optional --name option which allows the internal logic to create a link for a specified user instead of only being able to create links for the root user. This makes the command useful in a wider variety of situations. Another common option is the --format option which allows a user to specify that they want the command to return its output in a format (CSV, JSON, Table, etc.) other than the default.

Options are defined in the Drush command's attributes. Their values are passed as part of an associative array to the command method. Unlike parameters, options are not ordered, so you can specify them in any order, and they are called with two dashes like --my-option. Options are always optional, not required, and can be set up to accept a value --name=John or as a boolean flag without a value --translate.

In this tutorial we'll:

• Declare options for a custom Drush command in its attributes
• Learn how to use these options inside the custom Drush command method

By the end of this tutorial, you should be able to add options to your own custom Drush commands.

Drush commands are commonly run in the Drupal docroot, the directory where Drupal's files live. This is a relatively simple task on your local development environment. But if you're working on multiple sites and each of those sites has one or more remote environments that you connect to via SSH, workflows quickly become complicated. Creating and using Drush site aliases allows you to run Drush commands on any site, local or remote, that you have credentials to access, from any location on your computer that has access to a Drush executable.

Imagine you've got a Drupal project with dev, test, and live environments in the cloud somewhere. And you need to clear the cache on the dev environment. You could SSH to that environment, and execute drush cr there. Or, after configuring a site alias you could do something like:

drush @provider.dev cr -y

And Drush will connect to the remote environment and clear the cache.

Site aliases allow bundling the configuration options (--uri, --root, etc.) for a specific remote server under an alias. This reduces the amount of typing required. Even more importantly, it helps teams agree on a common definition for environments like @dev, @test, and @live by committing their configurations to version control.

In this tutorial we'll:

• Define what a Drush site alias is
• Understand the use case for aliases
• Learn how to configure and use Drush site aliases

By the end of this tutorial, you should understand how Drush site aliases work, how to create Drush site aliases, and how to use them in a Drush command.

The Drush executable can be configured through the use of YAML configuration files and environment variables. This configuration can help cut down on typing lengthy frequently-used commands. You can tell Drush to look for command files in project-specific locations. Configuration can also set the value(s) of a specific command's options, instead of having to type them at the command line every time.

In this tutorial we'll:

• Explore different Drush configuration options
• Learn how to configure Drush for your project

By the end of this tutorial, you'll know how to provide project specific, and global, configuration that helps customize Drush and improve your own efficiency.

Creating a custom Drush command requires creating a PHP class that Drush can find with methods that have PHP attributes that provide metadata about each custom command. You'll use an autowire trait to inject any services into it. You'll also optionally modify the project's composer.json to tell Drush what versions of Drush the command is compatible with.

Custom Drush commands are a great way to expose your custom module's features to help automate these tasks and allow users to perform them as background processes. They can also provide a more efficient way to execute PHP code that takes a long time and is prone to timing out when run via the web server.

Depending on your use-case it can also be more efficient to create a custom Drush command to execute your logic instead of coding a complete UI. For example, if all the command needs to do is generate a CSV list it might take less effort to write a Drush command and pipe the output to a file than to create a UI that generates a file and prompts the user to download it.

In this tutorial we'll:

• Declare a new custom Drush command inside a custom module
• Make our custom Drush command output a list of all the blocked users on the site
• Verify our new command is working

By the end of this tutorial you should understand how to create a custom Drush command that returns a list of blocked users.