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.
Panels has long been one of the more popular contrib modules for layout in Drupal. At Electric Citizen, we’ve been using Panels and its large suite of associated modules (Page Manager, Panelizer, MiniPanels, Panels IPE, Fieldable Panel Panes) for years. Virtually every Drupal project we’ve worked on involved these modules in some capacity.
So what does Panels do? The full answer would take more than we’ll cover here. But at the base level, Panels offers a visual UI, where site builders can make custom page layouts through:
- Custom page layouts (e.g. three columns, two columns with header and footer, 2x2 grid, etc.)
- Moving and rearranging content fields into different regions of a layout
- Inserting custom blocks and views into custom page regions (e.g. - add a sidebar menu to every basic page)
Note that Panels traditionally has been used for the “middle” content of a page – the part where the Body content goes. Headers and Footer (e.g. site name, logo, main menu) are global content areas unaffected by Panels. The exception is if you used Panels Everywhere, which takes the Panels concept to every content regions of your site (like the Blocks UI).
Panels in Action
Our client at the University of Minnesota Law School is a great example of Panels in action. Every page on the site is constructed of panels layouts.
The most common layout has a sidebar left and wider column for main content. The 2-column "sandwich" layout has site menus and various calls to action in the sidebar, while the main column contains the body copy. The header region contains a featured image (if available) and page title.
Panels IPE lets site editors change the layout of an individual page, if desired, without code. They simply choose a different page layout–three-column, for example– and then rearrange the various components using a drag-and-drop interface. They can also insert new or existing content to various page regions, such as a button to "Apply Now."
Changes from Drupal 7 to Drupal 8
Panels did so many things in the past that I think it scared people away, starting with a complex looking user interface. Panelizer also had a complex looking UI. These have been tamed somewhat in Drupal 8, and hopefully easier to understand for new users, by reducing the number of visual options, and simplifying the path to follow when applying your settings. The basic concepts of page layout and field layout, however, have carried over between versions.
In Drupal 7, Panels had a UI, while Page Manager ran behind the scenes. In Drupal 8, there isn’t a stand-alone “Panels” interface anymore, and Page Manager is optional. You’ll need to rely on a Panels-related module like Panelizer, however, for the user interface and making edits. Panelizer was created for extending Panel-like changes on a page-by-page basis (vs global changes), but can be used in managing global settings as well.
Other changes include integration with the new Layout plugin, which lets users share layout templates between different modules, and not require developers to create separate 2-column or 3-column layouts (for example) for every module that might need it.
The in-place editor (IPE), which allows editors to add or rearrange Panels content on the page you are editing–as opposed to a backend configuration screen–has been ported to Drupal 8 but with a new, cleaner looking UI.
Fieldable Panel Panes, a useful Drupal 7 module for customized min-content-types (aka “widgets”) that can be placed within your content won’t be ported to Drupal 8. Thanks to the new-and-improved Block module, which allows for custom fields and block types, there’s no need for another module that can do this.
How to Use Panels in Drupal 8
After installing both Panels and Panelizer, you can get started customizing the layout (Display) for each content type. For each content type, under “manage display” you’ll find the option to “Panelize” your content. Once checked, you can start making your changes. The two areas you’ll want to pay most attention to are “Layout” and “Content.”
With Layout, you can assign a new page template to each content type. You can start by choosing 1-column, 2-column or 3-column layouts, and extend it from there to include dozens of variations in layout. Each page layout has its own set of style rules and regions for content.
Using “Content,” you can start rearranging the fields of your content type into different regions, as well as adding existing or custom block content to the page. Some settings can be made to fields here as well, such as the size of image. Note that In Drupal 8, everything you add to Panelizer is a Block, and not a Panel pane, as in Drupal 7.
Using Panelizer and IPE allows you to change the appearance of any content type without going into code and altering the page template files. Fields can be dragged and dropped into different regions, or rearranged in different orders. By changing the page layout, existing fields can be moved into different configurations and regions. So much power at your fingertips!
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.
Display Suite has long been an alternative to the complexities of Panels, with some of the same key features. At its core, Display Suite allows editors to choose different page layouts for each content type, and then drag-and-drop fields into new regions (e.g. - moving an image to a sidebar, or a text field to the footer).
Another advantage of Display Suite in Drupal 7 was the ability to create custom Display Modes. As you may recall from the previous article, Drupal comes with default Display Modes for content types, such as Teaser and Full Content. But if you wanted to have a special Display Mode for a list of News articles (for example), you would have to use a module like Display Suite to create them. Since Drupal 8 now has custom Display Modes in core, this feature is no longer required in Display Suite.
The Drupal 8 version of Display Suite also handles page layouts from the Layout plugin, and are not specific to Display Suite. Like Panels, Display Suite is only for the main (middle) content and not the overall site header or footer.
An experimental Drupal Core module, Field Layout, has been introduced that duplicates the features of Display Suite. I’m not certain if this will eventually replace Display Suite entirely, but it does seem likely.
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
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.
If you’re a veteran coder who doesn’t need to offer layout control to non-technical editors, you can do a lot of layout via custom page templates and Twig. But if you want both the power and flexibility of these additional layout tools, you’ll give your site builders and site editors a lot of great options.
Join the Discussion +