Layout in Drupal 8, Part 2October 6, 2017
Layout in Drupal 8 is a broad topic. For these articles, “layout” means anything that affects an overall web page’s appearance – elements such as page structure, columns and rows, regions, etc.
In Layout Part 1, I looked at how page layout can be done using Drupal’s core features – the default theme of Bartik, the core module of Blocks, the Twig template system.
For part 2, I'll cover what contributed (contrib) modules we can use for layout, as well as other themes and grid systems.
Why Contributed Modules?
Drupal has long allowed site owners to define content types and fields in a UI. And using Manage Display, editors can rearrange the order of how fields are rendered. What hasn’t been allowed, outside of manually editing page template files, is the ability to add or alter page regions, and move fields into different regions on a page (e.g. header, footer, main, aside). What the following modules do is allow users to customize their page layouts in powerful ways, all without getting into code.
Debuting in Drupal 7, Paragraphs opened a new world of options for page layout, in a powerful and (somewhat) easy-to-grasp concept that held great power to non-technical site editors. Similar to using Panels and Fieldable Panel Panes, Paragraphs allows editor to:
- Create custom content types (paragraph types) with their own set of data fields (like custom block types in Drupal 8), that can then be used to
- Create unlimited blocks of content right on the node edit screen, and
- Rearrange their sort order with a simple, drag-and-drop interface.
Unlike Panels, Paragraphs doesn’t have extensive context and layout options. Instead, you can create Paragraph types, and offer them as an option for site editors to create on a page after the Body field. We like to call these Paragraph types “widgets.” Think of these widgets as similar to custom Block types. For each widget, you can define fields, define the layout, and define the style.
An easy example is an Image widget. While a site editor could add an image to a page via the WYSIWYG controls, using a Paragraph widget offers many more options. We can define the way the image renders, offer a select list of sizes for the editor choose from, and attach additional fields such as caption, source, date taken, etc. With a map widget, a site editor can simply type in an address, and a fully-embedded Google map gets rendered.
But wait, there’s more
Thanks for the ability to embed Paragraph widgets inside other widgets, we can create layout-style widgets, such as 3-column group, and then embed additional paragraph content inside of them. While this sounds complex and perhaps a bit strange, what it means is you have a container for your layout rules, and then inside the container, your custom content. For example, an editor could add a 3-column list of callouts to a page without code. Each callout could be a paragraph widget with fields for title, image, summary and link.
All Paragraph content is typically placed following the Body field. This allows editors to break up their page content with images, videos, maps, etc., without having to manage these elements inside their Body field. The ability to both “chunk out” and rearrange content on a page lends itself perfectly to the storytelling style of modern web design. Some have gone so far as to eliminate the Body field entirely from their content types, but I think it still has some use as the summary or introductory area of your page.
Sample Use Case
We first used Paragraphs extensively on the Century College website. Site editors construct and maintain rich content through a set of Paragraph widgets, all without touching code.
In the example shown here, the page is comprised of a series of widgets – text blocks, featured images, image slideshows, embedded map, horizontal rules between content.
Trying to lay out this page content within a single Body field would get really messy. Editors would have to embed a map generated elsewhere, embed a slideshow generated somewhere else, resize and place images in the place they wanted – all within a tiny WYSIWYG editor. CSS styles and classes would likely be part of the layout, requiring editors to go into code. And should changes be required at a later date, it could get even messier.
Using a series of preconfigured Paragraph widgets we've provided, editors can:
- Select a widget (e.g. Map)
- Fill out the field for that widget (e.g. street address)
- Save and refresh
In this example, a map would be appear on the page, already styled and formatted for you. Should an editor wish to move the map to a different place, they simply edit the page, find the widget they created, and drag it to a new position.
Do you need this module?
Since we have ability to create custom Block types, with their own set of fields in Drupal 8, what is the advantage to using Paragraphs? It’s debatable, but I find of the main advantages is the ability to associate these widgets of content directly with the node. Unlike Blocks, each Paragraph you create won’t appear in a giant list of content in the Blocks UI. They are only visible when editing a specific node. The disadvantage is that you can’t reuse Paragraph content on multiple pages, like you can with Blocks.
Paragraphs is very similar from Drupal 7 to Drupal 8, but some improvements to UI are coming soon (available now in experimental form). It’s already one of the more popular modules in Drupal 8, and hopefully will continue to evolve over time.
Themes and Grids
In addition to contrib modules, you can also check out contributed themes and grid frameworks for additional layout control through a grid-system.
What are grid-systems?
Grid systems are used to define a consistent structure and placement of regions for your content, following a consistent pattern (grid) of widths and heights. Grid systems have been a part of web design for several years, and much longer a part of print design.
Grid systems can come in endless variations of grids. They aren’t specific to any version of Drupal or any other CMS. But I don’t want to focus on the grid itself. Instead, I want to talk about grid frameworks (aka “grid engines”).
Grid frameworks are libraries of code, created to generate a series of grids of your choosing. These libraries do all the math in the background, calculating the width of each grid column across a range of screen sizes. Rather than build a grid system from scratch, these frameworks provide you with all the tools you need. You simply install a grid framework, and then start defining the type of grid you would like. For example, give me a 1-column grid for mobile, an 8-column grid for tablets, and a 16-column grid for desktops.
Some of the more popular frameworks I have used are SingularityGS, Susy, and Neat. One of the advantages in using a grid framework is the ability to apply grid layouts to your site, regardless of what Drupal theme you are using. The grid gets defined in your CSS, and applied to your Drupal layout.
It does require some learning, a tiny bit of math and knowledge of CSS, but it isn’t terribly hard. If you hate learning another system, and just need something simple and predefined, consider a Drupal theme with a grid-framework built in.
Themes with Grid Frameworks
The most popular option here has to be the Bootstrap theme. Installing Bootstrap gives your content access to a well-defined and responsive grid framework, plus additional theme settings for your controlling your breadcrumbs, navigation, tooltips, and more — all preset layout options.
With Bootstrap, you can apply a predefined CSS class to a block, region, or other container, and it will follow a grid such as 12-column or 16-column. Drupal templates have to be altered to include Bootstrap-specific classes, but the Bootstrap theme has done all that work for you. This theme is available for both Drupal 7 and Drupal 8. A similar but lesser-known theme, Foundation, is another option that does similar things.