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.

Twig is the theme template engine in Drupal as of version 8. Like any code, there are guidelines and standards that dictate both the style and the structure of the code. In this tutorial we will explain how to adhere to the Drupal code standards while implementing Twig templating.

By the end of this tutorial you will be able to adhere to Drupal's coding standards when writing Twig, and know where to find more information about the guidelines when necessary.

Managing a Drupal application with Composer requires a few modifications to Composer's default behavior. For instance, Drupal expects that specialized packages called "modules" be downloaded to modules/contrib rather than Composer's default vendor directory.

Additionally, it is common practice in the Drupal community to modify contributed projects with patches from Drupal.org. How do we incorporate Drupal-specific practices like these into a Composer workflow?

In this tutorial we will:

• Address all of the Drupal-specific configuration necessary to manage a Drupal application using Composer

By the end of this tutorial you should know how to configure Composer to work with Drupal, and drupal.org.

When managing your Drupal project with Composer you'll use Composer commands to download (require) modules and themes that you want to install, as well as issuing commands to keep those modules and themes up-to-date when new versions are released.

In this tutorial we'll:

• Cover step-by-step instructions for performing common Composer tasks for a Drupal application
• Install and update Drupal projects (core, modules, themes, profiles, etc.) using Composer
• Convert an existing application to use Composer

By the end of this tutorial you should know how to use Composer to install, and update, Drupal modules and themes.

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.

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.

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

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.

Drupal stores many of your site's settings, such as content types, views, roles, and image styles, as configuration. When you're working with multiple environments or collaborating with a team, you need a reliable way to move those configuration changes from place to place. Drupal's configuration management system provides tools to export, track, and import configuration, keeping your site consistent from local development to the live site and enabling you to test configuration changes safely in a development environment and deploy them in code to the live site.

In this tutorial, we'll introduce the configuration management workflow in Drupal and explain how to synchronize your configuration across environments.

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

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.