Providing Enhanced Drupal Authoring Experiences in Layout Builder

First introduced in Drupal 8, the Layout Builder module provides content editors with a way to drag and drop components into preset layouts in Drupal, re-order them and change their contents at their discretion without requiring code. This is similar to proprietary solutions like Acquia Site Studio, Mercury or DXPR Builder.

One of Layout Builders primary strengths is that it is built entirely with Drupal core APIs and conventions. That means that every facet of Layout Builder can be modified or enhanced from its interface to the rendering to the end user which other solutions do not really offer. On top of that, there are dozens of modules that provide new features and extensions on Layout Builder, making it a very attractive solution that allows nearly full ownership of the solution top to bottom.

Like other areas of Drupal, this provides a lot of power and flexibility in molding the experience to something enjoyable for authors. In this article we will demonstrate examples of this in action and explain how by making a few modifications you can greatly enhance the authoring experience in Layout Builder.

In this article I will demonstrate some of the ways we have altered the user interface for enhanced authoring experiences in Layout Builder.

Use Context to show or hide sections and components in Layout Builder

Sometimes we have a need to make a section of the page dynamic or only show specific things to specific users in certain circumstances. Out of the box, Layout Builder doesn’t necessarily have a way to do this. We created the Layout Builder Context integration module for Drupal that bridges the gap between the Context module and Layout Builder. We wrote about it in depth on the Velir blog last year.

Using this module is a fantastic way to add deeper display control from Context into Layout Builder, usable on either full layout sections or individual components within a layout section.

A few editorial examples for a page could be:

• Show a specific area of the page to privileged users
• Display a section with author details if the page was authored by certain roles
• Show different components under certain conditions
• Display a different call to action for visitors who have not been to the site in several weeks
• Hide certain page details beyond a specific date
• Personalize content for specific audiences
• Present different Webforms based on geolocated IPs or other aspects of their session

Combining Layout Builder and Context is a homerun for site builders and authoring flexibility. These are just a sample of the things you could do!

Use Contextual Links to provide quick actions in Layout Builder

At the heart of everything in Layout Builder are blocks. Block types make up the component structures you can place into layouts. Every component you place has a contextual menu, which you may recognize:

These are known as contextual links in Drupal. You can also add to this menu using either YAML configuration or hooks in custom modules.

Consider a scenario where you have a block type that might pull in information from a third-party service and display it in a visualization. Editors can select what dataset they want to pull, and then select how long to cache that information. When rendering the component, Drupal will respect these values.

But what if you wanted to “view” the API response for debugging purposes? What if you wanted to quickly clear the components cache data without waiting for the next cache expiration?

You can add contextual links to block types in Drupal to solve this. After we have declared our links, they appear in the contextual menu for this block type providing quick assistance to the content editor:

If there was a question about what the API may be sending back in this case, simply clicking on “View API Response” would tell us without having to use Chrome debugger or PHP debugger to inspect the HTTP response:

These additions are easy to do as contextual links and provide convenience and speed for different tasks. Authors are people too and don’t have access to many of the deeper developer tools that we use day to day and these additions help them stay on the same page with custom integrations and how things work.

Use Storage Entities to create reusable complex components

We often encounter requirements where editors need to display complex content components, like visualization, maps, or other interactives that may be used around the site more than once. It would be tempting to create them as block types, but that would mean they would not be easily reused around the site.

One way to make this easy is to use the Storage Entities module to contain this information. That will enable editors to ‘create new’ or ‘reuse’ existing items. For example, we recently integrated a third-party API that brings in data to visualize in Highcharts. Users set the endpoint they want to hit and the data they want to query, then the length of time to hold the response in cache.

As just a regular block type, creating an instance of this for Layout Builder would make it not easily reusable. Since we created a “Chart” storage entity, editors can store the information in a separate area and reference it in a dedicated block in Layout Builder. This makes charts reusable across the site and makes it easy to change from one stored chart to another and back again.

Create Custom Layouts to Provide Flexibility

Consider this – a layout doesn’t literally have to be a space for displaying content. Sometimes there are requirements to adding items to a page that are hidden or add embedded tracking scripts. We can facilitate this by adding a custom layout that has no visible appearance, style or dimensions. For instance, we can create a ‘Hidden’ layout plugin:

/** 
* Hidden layout region for modals. 
*/ 
class Hidden extends LayoutDefault implements PluginFormInterface { 
 
  /** 
   * {@inheritdoc} 
   */ 
  public function buildConfigurationForm(array $form, FormStateInterface $form_state) { 
    $form = parent::buildConfigurationForm($form, $form_state); 
 
    $form['help'] = [ 
      '#markup' => '<p>The hidden layout is meant to contain hidden items that conditionally appear, like modals.</p>',
    ]; 
 
    return $form; 
  } 
 
} 

With this new layout type, you can add interactives to a page like a modal without it appearing incorrectly on the page (thanks to custom CSS and JS, of course):

After saving, we can see that the modal works. With this example, solutions that usually guide users to the block management page or other bespoke methods of managing modals outside of content editing screen are now done from the same interface, making it easier for authors.

Upon saving and viewing this page, the modal appears:

Here it is in action. Note that the layout is not visible and has no margin or padding. To the content editor, placeholder text appears in Layout Builder indicating there is a modal component and what it contains. The actual firing of a modal is reserved only for anonymous users. When an anonymous user visits the page, the modal appears.

These are just a few of the ways we have enhanced the Layout Builder interface for content editors. Keep an eye out for future posts demonstrating other ways we can enhance the authoring experience in Drupal.

Get the Drupal 10 Development Cookbook 

Drupal 9 is now the end of its life. Have you upgraded to Drupal 10 yet? Are you facing some difficulties? We have a great resource that can help you!

The "Drupal 10 Development Cookbook" is co-authored by Matt Glaman and me, Kevin Quillen. We cover a wide variety of topics with hands-on examples so you can get up and running with Drupal 10 in no time. These topics include running Drupal locally with Docker-based tools, content modeling, creating custom modules, how to do automated testing, and migrating data into Drupal from various data sources. The book will help you understand how to develop and build modules just like the ones we talk about often at Velir.  

What others are saying:

You can pick up the book on Amazon as a physical copy or for Kindle.