Styling the Content

In this chapter, we’ll explore some ways to style the main content of a page.

First, we’ll discover how content is structured by learning everything about entities, bundles, and fields. Then, we’ll talk about the other entity types usually related to the main content, such as media elements and taxonomy terms.

You’ll learn several methods to structure Drupal’s contents and how to style them to match the design system properly. You’ll also learn how to provide a custom field formatter to provide a different markup for a field, and how to add styles to the What You See is What You Get (WYSIWYG) editor.

Finally, we’ll list some alternatives that you can use to manage content in a more advanced way.

The topics we will cover in this chapter are as follows:

• Entity, fields, bundles, and display modes
• Media and image styles
• Taxonomy terms
• How to structure contents
• Defining a new field formatter...

Entity, fields, bundles, and display modes

All contents managed by Drupal are stored in some entity type.

In Drupal, an entity is a data structure representing a specific content or information type. Entities define the structure and behavior of different kinds of content on a Drupal site, such as nodes, users, taxonomy terms, comments, media.

Note

Drupal uses the term content on the web UI and documentation to refer to a specific entity type, which in code is called a node. Even if you look at the canonical URL for a content page (one of the pages that you can reach from the Content menu on the toolbar), you see that it’s in the form node/1, where 1 is the ID of the node that Drupal will render in the main content area of the page.

Each entity type has its properties that define the information it manages. For example, a node entity type might have properties such as a title, body text, and author, while a user entity type might have properties such as a username...

Media and image styles

A media entity represents any kind of asset that can be exposed as a field and used to build content. It can be an image, a local or remote video, audio, or a simple file.

Note

The media module of Drupal is extensible with contributed modules and can manage oEmbed (https://oembed.com) remote URLs, iframes, and so on.

A media entity is a wrapper of a file or a remote asset used to provide additional fields; the field of a media entity that stores the asset (local or remote) is referred to as the source.

Media entities can be managed by a media library, an optional core module of Drupal that enhances the media module itself with some additional features. For example, it provides an interface to easily find and (re)use existing media items:

Figure 6.3 – The media library

The previous figure shows an example of the widget used to upload or select existing media.

Image styles

Images can be rendered with different...

Taxonomy terms

One of the key features of Drupal is the ability to define new taxonomy terms and use them to categorize content.

Taxonomy terms have the following features:

• Grouped in vocabularies
• Hierarchical
• Can be enriched by custom fields

Vocabularies represent the bundle for the term entity type.

The demo website defines two new vocabularies, one for the trip duration and one for the trip difficulty level.

Like the media entity, a taxonomy term is attached to other entities using an entity reference field.

How to structure content

The main source of content in Drupal is nodes. As we saw, the output of a node is used to fill the main content block of a page.

Nodes are associated with a specific content type that defines the fields and display settings for that type of content.

On our demo website, we’ve defined some content types to represent a trip, a landing page, and a base page; the full list is here: /admin/structure/types.

The demo website uses two approaches to structure content:

• By directly using fields
• By splitting a page into sub-components that can be used to build more complex layouts

We can use the first approach to build pages constrained to a specific layout, such as the page that describes a trip:

Figure 6.9 – A content type built with fields

For this kind of content, an editor can only choose the values to insert for each field. They cannot choose, for example, that the text must be rendered before...

Defining a new field formatter

Looking at the full version of a trip node, you’ll see that field_lat_lng is a little bit ugly. It prints the raw values for the latitude and longitude. It should be way better to have a geographical map with a marker on it. We can implement this directly in a Twig template, but this solution has a couple of drawbacks:

• Twig is quite limited when it comes to data manipulation
• If we need a similar field but with a different name, we have to duplicate the code

Providing a different way to render a field on the frontend is a task for a field formatter.

First of all, we need to define a new theme hook in a custom module:

function alps_base_theme(): array {
  return [
    'alps_base_lat_lng' => [
      'variables' => [
        'lat' => '',
       ...

Customizing the WYSIWYG editor

Drupal core comes with the CKEditor 5 text editor by default. You can switch to something else if you want, but CKEditor is the editor most supported by the core and contrib modules.

Text formats

Which CKEditor widgets are available in the WYSIWYG editor and how they’re configured is managed by a Text format.

A Text format is used to choose the following:

• Which WYSIWYG editor to use when entering a formatted text, and its configuration
• How the text entered in the WYSIWYG editor is translated before it is printed on a page

For security reasons, you must never trust input from users, even if they come from your organization. A properly configured Text format makes sure that this doesn’t happen.

Text formats are available to users based on their roles on the website, and you should give more power to trusted people only.

Note

If a user has permission to edit nodes created from a content type, but doesn&...

Alternative ways to manage content

Both core and contrib solutions exist to structure and manage content on a Drupal 10 website:

• Layout Builder and Layout discovery: Core modules that provide a drag and drop interface to visually place content fields in a custom layout
• Display suite: A contrib module to place the fields of content in subregions (https://www.drupal.org/project/ds)
• Gutenberg: A contrib module to integrate the Gutenberg editor in Drupal (https://www.drupal.org/project/gutenberg)

All those solutions provide a different way to insert information into a Drupal node (or any other entity type), but the rendering part is exactly the same.

Ultimately, you’ll always have a theme hook that mixes some PHP variables with a Twig template to generate HTML markup.

Summary

In this chapter, we saw that content in Drupal is composed of fields, grouped in entity bundles, and shown on a page using a display mode.

We’ve understood how to manage media entities and provide a set of image styles to adapt an uploaded image to the one rendered on the frontend. We talked about taxonomy terms, what they are, and how to use them.

You now know that you can do the same thing in different ways in Drupal, with different modules and configurations, but ultimately, Drupal will render it in the same way.

Finally, we saw an advanced topic on how to create a custom field formatter and add custom styles to CKEditor.

Even a simple website allows some interactions with the end user, and this is usually done with forms. In Chapter 7, Styling Forms, we’ll discover how to style them.