Drupal is integrated with CKEditor 5 as the default What You See Is What You Get (WYSIWYG) editor. The Editor module provides an API to integrate WYSIWYG editors, although CKEditor (the default editor) contributed modules can provide integrations with other WYSIWYG editors.

Text formats control the formatting of content and the WYSIWYG editor configuration for content authors. The standard Drupal installation profile provides a fully configured text format with the enabled CKEditor. We will walk through the steps of recreating this text format.

In this recipe, we will create a new text format with a custom CKEditor WYSIWYG configuration.

Getting ready

Before getting started, make sure the CKEditor module is installed. This module is automatically installed with Drupal’s standard installation.

How to do it…

Let’s create a new text format with a custom CKEditor WYSIWYG configuration:

1. Visit Configuration from the administrative toolbar and head to Text formats and editors under the Content Authoring heading.
2. Click on Add text format to begin creating the next text format.
3. Enter a name for the text format, such as the Editor format.
4. Select which roles have access to this format – this allows you to have granular control over what users can use when authoring content.
5. Select CKEditor from the Text editor select list. The configuration form for CKEditor will then be loaded.
6. You may now use an in-place editor to drag buttons onto the provided toolbar to configure your CKEditor toolbar:

Figure 2.1 – The text format edit form

7. Select any of the Enabled filters options, as shown in Figure 2.2, except for Display any HTML as plain text. That would be counterintuitive to using a WYSIWYG editor:

Figure 2.2 – The Enabled filters checkboxes

8. Once you’re satisfied, click on Save configuration to save your configuration and create the text filter. It will now be available to users when adding content to rich text fields.

How it works…

The Filter modules provide text formats that control how rich text fields are presented to the user. Drupal will render rich text saved in a text area based on the defined text format for the field. Text fields with “formatted” in their title will respect text format settings; others will render in plain text.

Important note

The text formats and editor’s screen warns of a security risk due to improper configuration. This is because you could grant an anonymous user access to a text format that allows full HTML or allows image sources to be from remote URLs. This may leave your site open to Cross-Site Scripting (XSS) attacks. A cross-site scripting attack is when attackers can inject malicious client-side scripts into your site.

The Editor module provides a bridge to WYSIWYG editors and text formats. It alters the text format form and rendering to allow the integration of WYSIWYG editor libraries. This allows each text format to have a configuration for its WYSIWYG editor.

Out of the box, the Editor module alone does not provide an editor. The CKEditor module works with the Editor API to enable the usage of the WYSIWYG editor.

Contributed modules can provide support for other WYSIWYG editors. For instance, the TinyMCE module (https://www.drupal.org/project/tinymce) integrates Drupal with the TinyMCE editor (https://www.tiny.cloud/tinymce).

There’s more…

Drupal provides granular control of how rich text is rendered and in extensible ways, which we will discuss further.

Filter module

When string data is added to a field that supports text formats, the data is saved and preserved as it was originally entered. Enabled filters for a text format will not be applied until the content is viewed. Drupal works in such a way that it saves the original content and only filters on display.

With the Filter module enabled, you can specify how text is rendered based on the roles of the user who created the text. It is important to understand the filters that are applied to a text format that uses a WYSIWYG editor. For example, if you selected the Display any HTML as plain text option, the formatting done by the WYSIWYG editor would be stripped out when viewed.

Improved links

A major component of WYSIWYG editing is the ability to insert links into other pieces of content or external sites. The default link button integrated with CKEditor allows for basic link embedding. This means that your content editors must know their internal content URLs ahead of time to link to them. A solution to this issue is the Linkit module at https://www.drupal.org/project/linkit.

The LinkIt module can be installed with the following Composer and Drush commands:

dd  /path/to/drupal
composer require drupal/linkit
php vendor/bin/drush en linkit –yes

The Linkit module provides a drop-in replacement for the default link functionality. It adds an auto-complete search for internal content and adds additional options for displaying the field. Linkit works by creating different profiles that allow you to control what content can be referenced, what attributes can be managed, and which users and roles can use a Linkit profile.

CKEditor plugins

The CKEditor module provides a plugin type called CKEditorPlugin. Plugins are small pieces of swappable functionality within Drupal. Plugins and plugin development will be covered in Chapter 8, Plug and Play With Plugins. This type provides integration between CKEditor and Drupal.

The image and link capabilities are plugins defined within the CKEditor module. Additional plugins can be provided through contributed projects or custom development.

Refer to the \Drupal\ckeditor5\Annotation\CKEditor5Plugin class (https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/modules/ckeditor5/src/Annotation/CKEditor5Plugin.php) for the plugin definition and the \Drupal\ckeditor5\Plugin\CKEditor5Plugin\ImageUpload class (https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/modules/ckeditor5/src/Plugin/CKEditor5Plugin/ImageUpload.php) as a working example.

See also

Refer to Chapter 8, Plug and Play With Plugins, for the CKEditor 5 documentation (https://www.drupal.org/docs/core-modules-and-themes/core-modules/ckeditor-5-module).

Many organizations have an editorial workflow that must be followed before content can be published on the website. The Content Moderation module allows content created in Drupal to go through an editorial process before it is published. In this recipe, we will create a content moderation workflow that puts content in a draft state and then reviews, approves, and publishes it. The content remains in a draft state and is hidden from site visitors until it is published.

Getting ready

In this recipe, we will be using the standard installation, which provides the Article content type. Any content type will suffice.

How to do it…

1. Begin by installing the Content Moderation module and its dependent module, Workflows:

   php vendor/bin/drush en content_moderation –yes

2. Visit Configuration and then Workflows. This page lists all configured content moderation workflows. Click Add workflow to create a new workflow.
3. In the Label field, give it a label of Approval workflow and select Content moderation for Workflow type.
4. The workflow has two default states of Draft and Published. We need to add Review and Approval states. For each of our new states, click the Add a new state link. Fill in the State label and press Save. Leave the Published and Default revision checkboxes unchecked. Those should only be used for a published state.
5. Rearrange the states’ ordering so that it is Draft, Review, Approval, Published. Press Save at the bottom of the form so that our ordering is saved.
6. Next, we need to create a transition to move a Draft to Review. Click Add a new transition. Set the Transition label to Ready for review. Select Draft as a From state. Then, select Review as the To state and press Save.
7. Now, we will create the Review to Approval transition. Click Add a new transition. Set the Transition label to Needs approval. Select Review as a From state. Then, select Approval as the To state and press Save.
8. We must edit the default Publish transition. Uncheck Draft from the From checkboxes and select Approval.
9. Finally, we must assign this workflow to content entities. Under This workflow applies to, look for Content types. Press Select and a dialog will open. Check Article, then press Save in the dialog.
10. Press Save at the bottom of the form. Our content moderation workflow is now complete!

How it works…

Without Content Moderation, publishable content entities only have two states: unpublished or published. There also are no permissions to control who can make an unpublished piece of content published or vice versa. Content Moderation solves this problem.

The Workflows module provides an API for defining states and transitions. It is up to modules such as Content Moderation to provide Workflow Type plugins to bring meaningful functionality. The Content Moderation module integrates with the revision capabilities of Drupal content entities.

When editing a content entity that uses Content Moderation, there will be a Moderation State field. This field contains the states that a piece of content can transition to, based on the current user’s permissions.

See also

• Content Moderation module documentation on Drupal.org: https://www.drupal.org/docs/8/core/modules/content-moderation/overview
• Workflows module documentation on Drupal.org: https://www.drupal.org/docs/8/core/modules/workflows/overview

Drupal excels in the realm of content management by allowing different types of content. In this recipe, we will walk you through creating a custom content type. We will create a Services type that has some basic fields and can be used in a scenario that brings attention to a company’s provided services.

You will also learn how to add fields to a content type in this recipe, which generally goes hand in hand with making a new content type on a Drupal site.

How to do it…

1. Go to Structure and then Content types. Click on Add content type to begin creating a new content type.
2. Enter Services as the name, and an optional description.
3. Select Display settings and uncheck the Display author and date information checkbox. This will hide the author and submitted time from services pages.
4. Click on the Save and manage fields button to save the new content type and manage its fields.
5. By default, new content types have a Body field automatically added to them. We will keep this field in place.
6. We will add a field that will provide a way to enter a marketing headline for the service. Click on Add field.
7. Select Text (plain) from the dropdown and enter Marketing headline as the label.

Important note

The Text (plain) option is a regular text field. The Text (formatted) option will allow you to use text formats on the displayed text in the field.

8. Click on Save field settings on the next form. On the following form, click on Save settings to finish adding the field.
9. The field has now been added, and content of this type can be created.

How it works…

In Drupal, content entities can have different bundles. A bundle refers to a different type of that entity type. The word bundle comes from it being a bundle of fields since each bundle of a content entity type can have different fields. When working with nodes, they are synonymous with content, and bundles for nodes are referred to as content types.

When a content type is created, a default body field is created for it. This is performed by calling the node_add_body_field() function in the node.module file. It is a great reference point for those who wish to see the steps for programmatically defining a bundle field outside of the user interface.

Fields can only be managed or added if the Field UI module is enabled. The Field UI module exposes the Manage Fields, Manage Form Display, and Manage Display options for entities, such as Nodes, Blocks, and Taxonomy Terms.

Form modes allow a site administrator to customize the edit form when modifying a content entity. In the case of nodes, you can rearrange the order of fields and change the form elements used for a fields node edit form. There is also the Field Group module. The Field Group module allows you to group fields into fieldsets.

In this recipe, we will install Field Group and modify the form display to create an Article content type.

How to do it…

1. First, we must add the Field Group module to the Drupal site using Composer and then install it with Drush:

   composer require drupal/field_group

   php vendor/bin/drush en field_group –yes

2. To customize the form’s display mode, go to Structure and then Content Types.
3. We will modify the Article content type’s form. Click on and expand the Operations button and select Manage form display.
4. Click Add field group to begin adding a new field group.
5. Select Details Sidebar from Add a new group, give this a Label of Metadata, and click Save and continue.
6. Press Create group on the next form and use the default values to finish creating the group.
7. Drag the newly created Metata group (as shown in Figure 2.3) up from the Disabled section so that is it enabled. Directly above the Disabled label is fine.
8. Take the Tags field and drag it so that it is nested under the Metadata group – below it, and slightly to the right:

Figure 2.3 – The Manage Display form with the Tags widget moved underneath the Metadata field group component

9. Click on the Save button at the bottom of the page to save your changes.
10. Go to Create a New Article; you will find the Metadata tab in the sidebar, which contains the Tags field:

Figure 2.4 – The Article edit form, with the Tags element in the sidebar

How it works…

When a content entity form is built, the form is aware of the display mode to be used. Then, it invokes the display mode to build the components for each field using the specified field widgets.

This allows you to customize specific parts of the form without having to replace the entire form. Developers can create new field widgets or leverage ones from contributed modules to enhance the functionality of forms.

Field Group does not create field widgets, but a new structure inside of the form display. It will then arrange field widgets into groupings. This provides a more organized content editing experience.

There’s more…

We will discuss more items for managing the form of a content entity in the following section.

Managing form display modes

Additional form display modes can be added by visiting Structure and then Display Modes under Form Modes. Each content entity type has a hidden default form mode that always exists. Additional form display modes can be added and configured using the display management form.

On their own, these forms and their configured field widgets are not directly integrated with Drupal. Using custom code, or even contributed projects, they can be used to embed for special uses.

For instance, there is the Register form mode for users. The user registration form is built using this display mode and the configured widgets instead of what is normally available when editing an existing user.