Hey really great comparison of the 3 methods. Nice job!
"With Drupal, on the other hand, you can choose all three. You can even have all 3 on the same website!"
^ probably one of the best reasons I have heard as to why Drupal is a plus.
Glitzy websites are all the rage these days. Everybody seems to be looking for easy ways to create multimedia-rich pages with ease. Yet there is a big downside to the current trend of page builders -- if you're not careful, you might end up making your long term content management far harder than it should be.
WordPress 5 made its Gutenberg "Block editor" the standard for all WordPress sites going forward. Drupal 8.7 added a new "Layout Builder" in its core, adding sophisticated layout capabilities. Both of these are playing catchup to Software-as-a-Service (SaaS) offerings like Squarespace and Weebly -- and a whole bunch of 3rd party modules and plugins that have been filling the gap so far.
The goal for all of these is to make it easy to interleave text with photography, video, galleries, and animations using something approaching a drag-and-drop interface. Yet how they go about doing this varies drastically under the hood. In broad strokes, you can group all of these layout builders into one of 3 categories:
|Module or Plugin
Drupal "Layout Builder"
Drupal Panels, Panelizer
Custom themes, page-type templates
Entity References/Inline Entity Form
Drupal Entity Embed
Vast majority of WP layout plugins
|Where items are stored
|Individual fields are in individual database tables/columns
|`Multiple entities are linked together to build up a page
|Everything is dropped into a huge text field
|Managing huge numbers of similar items
|Keeping content and presentation separate, to allow re-skinning down the road, while still making rich authoring relatively easy
|Very easy authoring
|Slightly less flexible -- harder to change up the sequence of rich elements
|Not as organized as field-based layouts, harder to extract, search, and aggregate information
|Very poor at reusing information on other pages, inconsistent look across the site, hard to update overall look and feel, finicky to use and get "just right", often has accessibility issues
That's the summary. Now let's take a look under the hood...
How do layout builders store their data, and why should I care?
Which is the best tool -- Excel or Word? Entirely depends on the job you're trying to do, of course. Yet these layout builders are as different as Word and Excel -- some are excellent at creating long documents with lots of variation, while others are far better at preserving data so you can show it in a chart, do math, and more. You wouldn't pick Excel to write an essay, for example, and you shouldn't pick Word to track your finances.
If you are creating a rich landing page for a campaign, a layout builder that takes the Embedded approach can get you there quickly. Lots of support for drag-and-drop, lots of ways to quickly get a result. You can build 5 more while you're at it -- but now try to compare things across 50 of these one-off pages -- now suddenly not having a template and simple fields to fill in makes the job much harder. You create pages for a bunch of products, and then you go to create a product comparison chart, and you're building that table by hand, cut-and-paste.
Or say for example you are a research institution, publishing research papers from dozens of contributors. You can make a nice landing page for each paper, with sections for the author's biography, the category, methodology, supporting organizations, and various other items -- but if you don't put each of these in its own field, it gets a lot trickier to build a nice search interface that will help your visitors find what they are looking for.
What is Content Management?
There are plenty of definitions of Content Management out there, mostly by vendors looking to sell you on a specific system, or pedantic descriptions of how big companies (Enterprises) need all this sophisticated stuff. While we are a vendor trying to sell you on something, let's take a moment to clear away all the B.S.
Website Content Management is about creating, maintaining, curating, and cultivating on your website for the entire life of the website. The problem with this focus on Layout Builders is that all the focus is on that very first step -- Creating. It ignores the rest of the lifecycle of your content.
At Freelock, we believe the longer you keep good content on your website, the more valuable it becomes. And keeping old content maintained and relatively fresh is a big part of that job. A Content Management System can help you keep your old content fresh -- keeping it looking consistent with rest of your site, bringing in new traffic, guiding people down your sales funnel to become customers, providing reputation and longevity that assure your customers you're not just another fly-by-night operation.
Embedding all of your rich content into one-off pages hampers this very process, especially when you want to change the look-and-feel of your website -- or find, re-use, or change the overall experience of your oldest content. Let's drill down into these different types of builders to see how they compare, for the longer term.
Field Oriented Layout Builders -- the Excel approach
Drupal excels at information architecture, and so the layout builder Drupal chose to include in its core supports this way of thinking about content. With the ability to easily create fields on different content types, and aggregate content using the powerful "Views" module, Drupal is all about information reusability.
There are dozens of different kinds of fields out there, and an even larger number of ways to use each one. For example, if you add a date field for an event, you can show it on a list of upcoming (or past) events automatically. You can show it on a calendar view. You can show it in a list, or a set of cards.
Add a geolocation field, and now you can show it on a map -- and you can filter that for upcoming events near me. Add a price and now you can create a "facet" that lets you see items between certain price ranges. All of this power builds on all of the other kinds of information stored in fields, and makes it easy to manage hundreds, thousands of similar items.
The new Drupal Layout Builder lets you easily create a template for showing each of these fields in a particular spot on the page, create multiple columns, drag-and-drop items around. In addition, you can create one-off blocks to highlight certain items, and reuse that on other items -- change up the layout entirely on a single item, if you wish.
Managing field layouts in the future
Down the road, if a product is no longer a special snowflake, hit a button and it reverts to the same layout as all the rest of your products -- the layout is stored in "just" another field on the item.
If you want to show a Google Map or a thumbnail linked to a file, you would have a field for the location to show and another field for the media. Then when you place the location field on the layout template, you would pick the "map" renderer to show a map for the field, and when you want to show the downloadable file, you could specify the size to generate the thumbnail and place it where you want it -- and it will look consistent across all the items in your site.
Want to change your design? Swap out the Google Map renderer for OpenStreetmaps, and all of the maps on your site use the new service immediately. Change the thumbnail size for the document, and move it to the left sidebar, and it's done across your site.
Embedded Layouts - the Word approach
The new WordPress Gutenberg editor is the poster child for the opposite way of creating rich layouts. Instead of having a field for each kind of data, you start with a blank page and a collection of blocks you can drop into it.
Honestly, I like using Gutenberg -- once you figure out the basics, it's mostly fun to use. Its killer feature is management of "Reusable Blocks" -- create a chunk of boilerplate, save it as a reusable block, and then you can reuse it on any other Gutenberg page. You can keep it in your page as a "reusable block" or you can convert it to a regular block and edit it.
You can create entire templates this way.
This... this is awesome for creating proposals! Or reports, or anything you need to do once, and don't care much about how it will look in 5 years.
It's very rapid for creating pages, and if you are constantly editing some key landing pages, Gutenberg seems like a fine way to go.
However, for content that's going to stick around for years, especially through a site redesign, it's going to be a bit of a nightmare. And right from the start it stops being useful for a huge number of scenarios modern sites are trying to support.
Very little design control
One thing a CMS attempts to do is make your site look consistent. One challenge with Gutenberg and other approaches that largely dump styles as well as content into a big text area is that it makes it much easier to violate your site's design, leading to ugly, confusing, jarring sites. Having spent several years as a professional writer, seeing garish colors and inconsistent fonts and font sizes makes me shudder. I don't want to have to think about what it looks like -- I just want to write it and trust the designer to make it look good.
Useful data is embedded, hard to reuse
I see blocks for "Product Comparisons" for Gutenberg. Wow, drop these in and you get some boxes where you can enter stuff -- cool!
But... you have to enter that stuff. And it already exists, on the product pages. Wait a second -- I thought this was supposed to make my job easier? And... hey, I have a new product that just varies in two of these areas. Which page did I put that product comparison on?
Managing changes in the future
Back to the earlier scenarios, now I want to switch from Google Maps to OpenStreetmap. To make this change, I need to do a search and replace -- find every map on my site, and generate a new widget from the new map provider. Lots of manual work. Maybe I can find or create a script, but even so, it feels a little brittle -- if I chose a different map style on one page, I might not find that one. And change my document thumbnail to move it to the other side of the page and shrink the thumbnail? Geez, I have dozens of those to do now.
This is the big "mistake" of embedded layouts -- managing content down the road.
And this is not new to Gutenberg -- the vast majority of page builders for WordPress essentially work the same way, embedding "short codes" into the body, and the only way to find them is search.
This is part of why I've heard many shops say you just need to start over and redo your website from scratch every few years.
If you've kept your content separate from the design, that is entirely not true -- having to rebuild your site is entirely the result of having your design too entwined with your content.
Repeating Templates -- a Hybrid
In between these two extremes, there is a third way. The best current example of this approach is the Paragraphs module for Drupal.
Compared to field-based layouts, you can easily make pages with a bunch of varied layouts, changing the layout as desired, one row at a time. If you do this very much with a field-based layout, you end up with a bunch of blocks hanging out that can clutter other parts of your CMS, and you end up constantly tweaking the design to get a result that looks good.
Compared to Embedded layouts, your content is still entirely separate from the design, making it easy to re-skin down the road. And you can still use fields that can be extracted and compared/searched/reused, although doing that effectively takes a fair amount of upfront planning.
We typically create a set of paragraph types, such as:
- Plain text
- Pull quote
- Image and text (image to the left or right)
- Photo Gallery
- Large media (video or image)
- Columns, cards
- Tab set, Accordion set
- Slide carousel
- Embed a view
When creating your content, you can add these in any order you like. We can provide particular classes for color variations, locked down to your brand's style guide.
The design remains very tightly controlled. Data is not necessarily easily reused -- but you can have a section of Paragraphs on content that still uses fields for all of the data management scenarios you like.
Because everything is templated, a re-skin of the site can make changes to one of these templates and it instantly applies everywhere it is used.
So which layout type should I use?
Should you use Excel or Word? Well, of course, you should use both, if you need them. There are very compelling reasons to use fields -- they are essential to Content Management, and many, many ways they make your work much easier. But there are times when dashing out a quick document, or web page, is needed right now.
By making Gutenberg its default editor, WordPress has gone entirely to the right side of that table -- they are trying to focus on being a good page builder, potentially at the expense of content management. Do you need content management? Depends on how much content you have to manage! If you're only talking about having a nice brochure site, and a steady stream of blog or news posts, this is all fine. But the more sophisticated your needs, the more you're starting to go against the grain. You can add fields to WordPress, and create views of content -- but this involves either creating some code or finding plugins that will help you do this -- many of which are not free/open source (a discussion for another post).
With Drupal, on the other hand, you can choose all three. You can even have all 3 on the same website! We are already using Gutenberg in Drupal on some sites, and we're using Paragraphs almost everywhere. Meanwhile we are very impressed with the new Layout Builder, and find it just the thing for making attractive layouts for certain types of content. You can have your Word, and your Excel too!
Hey really great comparison of the 3 methods. Nice job!
Really good summary. Thank you. We've also built an enhanced editing experience for Drupal (As part of our end to end site building tool for Drupal 8). www.cohesiondx.com
We agree choice is key for a healthy ecosystem and how you build should depend on use case as should the way you deliver an editing experience. DX8 has lots of other advantages such as the ability to reuse components, templates, content types etc site to site and many many more. When competing against other platforms it really helps place Drupal ahead of other options.
So hopefully you'll take a look at option 4! Let me know what you think.
Thanks for your comment! It looks like this is a proprietary system -- not available on Drupal.org, requires an API key? That makes it a bit harder to evaluate, among other things!
I like seeing the power and variety coming to Drupal, but one big reason I think Drupal is better is that the community largely isn't fragmented into lots of smaller proprietary vendors, leading to a lot of silos of functionality.
Any chance you'll make your solution more open?
It's not the first time we've been asked this! The module is open source just not on drupal.org but yes the API is propriety. The issue is that the DX8 is much more than a page layout system - its' and end to end site builder - templates, components, views, styles and more - all through low code and all reusable site to site (build once, use everywhere and forever.) Its also taken 3-4 years of Dev so needs a commercial model to be viable. Having said that we have an MVP of DX8 components working with layout builder etc so we're defiantly thinking about how it works with Drupal Core. Layout builder didn't exist when we started building!
You can assess for free though. If you request a demo you get a fully featured environment in a few seconds https://www.cohesiondx.com/get-demo
[Admin edit: accidentally deleted when cleaning up spam, restored via cut/paste]
I use the toolset plugins when building Wordpress sites. With it you can create custom content types with custom fields (other plugins provide similar functionality). Toolset has updated the types plugin so now you can template your content type using Gutenberg which provides for a consistent way of laying out a particular content type.
[Admin edit: accidentally deleted when cleaning up spam, restored via cut/paste]
Thanks for the comment! This toolset approach does make WordPress far more useful as a CMS... I haven't tried mixing this with Gutenberg, but I'm assuming it ends up similar to Drupal Gutenberg -- which moves fields into a section on the "Documents" sidebar to fill in.
With Drupal Layout Builder, you can place these fields within your layout. With Gutenberg, these fields end up above or below the Gutenberg-managed part of the page...
If you install the new plugin Toolset Block, you can use the Toolset fields (and views) directly in a Gutenberg layout. Also, Toolset recently updated Content Templates so you can use them to define the layout of a content type. Content Templates can be edited using Gutenberg.
Thanks for posting, John. These are great thoughts. I've never been a fan of Gutenberg....always thought it was a cool concept with poor execution. I hadn't considered the re-usability or cataloguing issues that Gutenberg would present for content moving forward, though...certainly something that clients of a certain scale would need to consider. I feel like WordPress launched a race to the bottom with Gutenberg: they're attempting to compete for small sites and blogs, but they've made it all but impossible to build complex applications, because they removed the choice that Drupal is so great at preserving.
Having built Drupal and WordPress websites for clients for a few years, these new layout / content structures get me really excited! And this is an excellent comparison. Thank you, and well done :)
We're a Drupal shop.
Our enterprise clients for the most part have zero interest in letting their content editors create new page layouts, so we've generally resisted the drag-n-drop approach of the consumer page builders and the like. Also these things seem to bring a lot of overhead... not to mention support calls.
What we have found useful is well-defined content types with a selection of Paragraphs components available to each. We can port data into these using Views (Views is possibly the leading reason we use Drupal altogether) or entity embeds, and if we're clever about it, create a very usable experience for our content editors.
We're starting to experiment with building our front-ends in React now, and evaluating the Drupal Emulsify project, which works with Storyboard and Webpack to manage a component library for a site or sites.
There's always a trade-off between freedom for content creators and control of the brand. Given the massive branding and UX consistency considerations our clients face, I don't think the Gutenberg-like builders are in the cards for us.
@Sam Thanks for sharing!
Paragraphs sounds like a great solution for your clients, for the reasons you cite. The one area where Layout Builder might have an edge is if any of your content types have a need for more structured information architecture -- e.g. products, with variations, prices, sizes, etc. Layout Builder combined with Paragraphs and Paragraph Blocks puts more control in the hands of your editors without sacrificing the underlying information architecture -- you can place individual paragraphs wherever you like on the page, mixed in with product details (or other fields on your content types).
We now have a couple projects going for creating components for the site editors to use to build up rich product pages, using Layout Builder.
Great info, John.
Have you seen any negative implications for headless or partially headless CMS installations? We're moving towards react in the front end, at least for our more promotional sites, which of course brings up all kinds of issues for site editors - but I'm also a bit nervous about some builder software adding all kinds of crap into the outgoing JSON.
Yet another area where Layout Builder is a much better solution than the others. The impact it has on headless? Zero. Zilch. Nada.
The layouts that Layout Builder provides are applied to the structure, from the outside -- not messy shortcodes/garbage inside text fields.
Layouts are stored in two different places:
- In a configuration object, for layouts that apply to entire content types, or layout library, etc.
- In a special field type attached to the entity, as a serialized blob, when you allow an entity to override the default layout
At this point, I don't think the field__layout is even available through the JSON API -- I think there's an issue open to make this available, but it's not yet in core. So that means layout builder will have no effect whatsoever on content you access through the API (but in the future you may be able to access layout builder layouts from a headless app).
The only way you can get this from an API is by requesting rendered entities instead of regular entities (e.g. using GraphQL you can access rendered entities to get the generated HTML for an entity)...