The Root of the Challenge
Before going over all of the different solutions to this challenge, I think it is important to take a bit of time to look at the standard approach to layout that comes with Drupal and was common in older Drupal 7 sites. Basically most sites operate on a Block and Region layout. This means a site's theme will come with a Header, content, sidebar, footer, etc region that you will then place content, or blocks into in order to create the layout of the page. This method can work very well for sites who only have a couple of types of ways they want to layout the page. However, for sites that are looking for more flexibility, this can lead to a team trying to work around and circumvent the baked-in regions a theme provides. This is bad because oftentimes the methods used can have a negative impact on the page load time, SEO rankings, and accessibility of the site.
Drupal like many other CMS solutions provides structured content modeling tools. Drupal has some of the most advanced and customizable among them. A blog post and a staff bio can use two different templates to get a unique layout when displaying the page while providing an advanced authoring experience to meet business objectives. When it comes time to build special pages though this can get a bit tricky if things are not properly planned out in advance. Not taking the time to select a strategy for creating content can lead to your team struggling to meet marketing expectations and requiring additional development time, that is why we have put together this article to help you and our future clients out when trying to decide what method or combination of methods will work best for them. As you can see from Rackspace's blog below the traditional layout can provide consistent results, but is restrictive:
The most important thing to remember is the way a "standard" page works, the page is always made up of regions, which will contain one or more blocks as well as the Main page content. Usually, the main page content block will contain a node or other entity that is made up of fields. The combinations of those fields will vary based on the content type, for example a blog post will probably have a field for the article as well as a tag field for tagging topics in that blog. For many sites, this simplistic approach will work just fine, however things can become complicated quickly when the structural and presentation needs of a piece of content don't fit into a regular pattern of fields in a node. Most times In real-world sites we see this happen in a couple of ways:
One-time content
One-time or one-off content is usually some piece of unique content that's different enough that it does not really fit into the other categories of content on the site. This could be a landing page, the home page, or maybe a month-long marketing campaign. The typical common theme is their uncommon-ness with other items and the fact that it is unlikely to be recreated or duplicated. If there are only a couple of these, then it may be worth the time to plan, design, and build a special content type you can use.
Flexible Portal pages
Entertainment and news sites often need to have sections or categories that all function like mini homepages for topics. These types of pages typically will each have a list of items, called a river. Larger enterprise and corporate sites tend to have many sections representing different product lines, business departments, or regional stores. Typically each will have key points in the navigation that serve as home pages.
This flexible customizable portal pattern can happen in other situations too, but it this pattern is what sets it apart from the One-time content pattern. Even if you have a lot of customizable landing pages, each editor and manager will probably want their portal to look a bit different from the others. This can mean a different type of grid system, different combinations of blocks, or differences in the rules used for dynamic lists. This almost always means the editors will want to have more control over the look and layout for a page leaving designers and developers out of the picture for the creation of the page.
Unforeseen Requirements
Projects that leverage ad-hoc web pages can oftentimes run into the unknown design and content constraints this is due to the different approaches that may be applied after the designer and developer have completed the initial site. When this happens oftentimes patterns that are present in content can become a liability instead of an asset. The pool of content in these sorts of situations. Trying to predict the future needs is a risky and oftentimes losing battle, this is where the more advanced strategies below can come into play.
Advanced Layout Strategies for Drupal 8
The limitations of the basic layout options most Drupal 7 sites came with lead to some new more advanced approaches in Drupal 8, below I will be going over each of them and the Pros/Cons of each. So that you can make an educated choice on which of the strategies work best for your new site.
Smart Templates
If the structure of your special content is mostly consistent, but you need to adjust just a few elements of the styling and layout of individual pages, then Smart templates will work for you. This strategy will leverage Drupal's standard theming system and a small amount of custom code in your theme. This will allow your site to examine a piece of content before it is displayed and select a template for specific conditions. Similar techniques can also allow you to add css or javascript for specific situations to further expand on the experience.
If you have editors who will need more direct control over these style and template decisions, adding one or two custom fields that allow you to switch can sometimes be enough. You could also add in some list fields with various layout or style variations using the values to decide which of your smart templates to use.
Pros of using Smart Templates
- Easy to theme trick that is available with stock Drupal installations
- Easy to explain, preview, and demo
- Content API / Rest API friendly
Cons of using Smart Templates
- Handles presentation variation, but does not always cover all structural changes
- Adding too many options can complicate editor view and can confuse content creators
- Variations or changes would require developers and designers to be involved.
Stacked Elements
When looking at the structure of those unique content items, and seeing how it varies reveals that just leveraging smart templates is not enough, then the next step in complexity is Stacked Elements or components. Basically, this is a combination of component content types that allow handling of the variation and a container content type to wrap the different types of content components together, this is basically the premise behind the very popular paragraphs module. The component content items can be defined with a common structural pattern used across the site, like slideshows, calls to action, event announcements, and more. Then the container or parent content type uses a multiple value reference field or our preferred use a paragraph field to tie the multiple components together to create a single piece of content. A container page could stack a testimonial component on top of a slideshow or call to action component, or more combinations. Then adding new element types or components to the site allows for an ever-expanding library of layout options while keeping things pretty structured based on templates.
When using the stacked component approach you need to use a consistent set of reusable items, as well as well defined design patterns that can map well to horizontal sections of self-contained content. If you need to create more complex grid structures you can easily add in the structure of your content elements to the details of your site during the design process. If it changes, then you will have to rework your element items theming too. Also, all of the pages that use them would need to be recreated or evaluated.
Pros of using Stacked Elements
- Can be built with core or third-party modules
- Focuses more on relationships than the "Page"
- Decisions for layout are captured in the content
- The order of content is linear and not ambiguous
Cons of using Stacked Elements
- Difficult for creating natural flowing narratives
- Can create deeply nested trees of content
- Makes changing the design and content model later more problematic
- Translation and localization can be a challenge
Embedded Entities
Sometimes unique pages are pretty straightforward save for a small bit of complicated structured content that needs to live inside a block of text. Some long-form feature articles that have sidebars are one of the most common use cases. In Drupal, one of the best solutions for this is something similar to the stacked element approach defined above, providing support for individual elements like sidebars, infographics, and so on can be defined as structured content types. Instead of stacking these items on top of each other, you can instead embed them inside of a node's body field using the Entity Embed module.
This approach has been talked about as far back as Drupal 7, but since then Drupal's entity support and embedding tools have matured and advanced considerably. The Media module, for example, is now included in Drupal core and leverages this technique to embed images and video into the content. There are other supporting modules like Entity Browser that make it easier to select existing items or create new ones without the need to leave the original document's edit form. When implemented in a thought out way, the flexibility of it is on par with HTML pages while still providing the consistency that you get with stronger structured content.
Pros of Embedded Entities
- Allows preserving the natural narrative flow
- Help keep complex HTML out of the body field
- Allows embedding entities inside of CKEditor or other rich editors
- Allows text wrapping and other display controls
- Works well with existing pattern libraries
Cons of Embedded Entities
- Multiple Contrib modules and complex configuration to setup
- Embedded Entities do not inherit workflow states
- Requires theming and content modeling of embeddable entities prior to use
- Easy for editors to leverage for all cases creating messes of pages.
Layout Builder
If you have pages that need a more flexible grid-like layout with the ability to leverage multiple columns or need more dynamic elements like views or custom blocks along with your more traditional fielded content, then the Drupal 8 Layout builder is probably the answer. It allows the combining of a modular approach that stacked elements and entity embedding with a large library of grid layouts. Individual nodes can have unique layouts when they are set to leverage the Layout module. It is a really powerful tool and now is available as a part of Drupal core, you can extend it further with custom plugins that add additional layout grids, map existing content from structured fields into its library, and much more.
One of the challenges however with Layout builder is that there is not a direct relationship between the content and the container page. This means that something like building a view that lists all of the components that live on a page is not possible. Also, some output formats like RSS feeds will ignore those components placed on the page with layout unless they also are a part of the content somewhere in a field.
There are ways to work around that limitation though by leveraging the fields and relationships that come with Drupal fields API to ensure that you capture all of the content that should appear on a custom page, then restricting the Layout builder library to just the fields that are already there on the node being edited. Given all of the flexibility that comes with the Layout builder, those restrictions can be a hard sell. If you are looking to get the most out of Layout builder, and the reliability of explicit relationships between a container page and its elements, then a custom module can provide a hook into the Layout Builder's API in order to make it possible.
Pros of using Layout builder
- Allows mixing Field content, blocks, and views
- Provides a high level of control over page layouts
- Editors gain the freedom to build and populate new layouts
- Ability to extend and control layouts in code
Cons of using Layout Builder
- Content from blocks is not directly connected to nodes
- Can be difficult to mix templated elements with custom layouts
- Hard to enforce sitewide consistency
- Interface for layout builder is still in development and not as smooth as it could be