As a writer or editor for your organization’s website, you should be able to quickly write articles or build pages that are collections of smaller elements. You should be able to write some text, add a slideshow, write some more text, perhaps list a few tweets, and finish things off with a list of related content. Or maybe you paste in a pull quote, add a couple full-width images with captions, or even put together an interactive timeline. Your content management system should let you do all that, easily. But chances are, it won’t be with the WYSIWYG you’re used to right now.

What You See Isn’t What You Get

WYSIWYG editors still fall short when it comes to doing much more than simple formatting and embedding a few images. Anything beyond that, and the underlying technology has to leverage some kind of proprietary “smart code” or “token” and do some find-and-replace magic that makes slideshows, media players, or other more complex blocks of content show up right to the editor. These tokens aren’t typically based on any adopted standard. It’s just this custom, arbitrary formatting shortcut that programmers decided to use that tells the CMS, “Replace this snippet with that other piece of content.”

If it sounds complicated, that’s because it is. It’s hard to get right. It’s hard to build in a sustainable way. It’s hard – impossible, really – to make it look right and work well for authors. It’s REALLY hard to migrate.

Here’s an example: In earlier versions of Drupal, Node Embed was a way to embed one piece of content (say, an image) inside the body of another (like an article). The “smart code” [[nid: 123]] tells Drupal, “replace this with the piece of content that has an ID of 123.” It worked, but the authoring experience was janky. And it really wasn’t structured content, since your markup would end up littered with these proprietary snippets referencing objects in the CMS. Somewhere down the line, someone would inevitably have to migrate all of that and write regular expressions and processors to parse it back into a sane structure for the new system. That gets expensive.

Fieldable Entities and Structured Content

The thing that lets you, the web editor, write content that is both manageable and flexible is breaking your content into discrete, single-purpose fields. In Drupal it’s called “fieldable entities.” You don’t dump everything into the WYSIWYG (which would be hard to do anyway). Instead, there’s a field to add the author’s name, a field for attaching images, and a field for the text (that last part gets the WYSIWYG). More generally, this serves an important concept called “structured content.” Content is stored in sensible chunks. It adapts to a variety of contexts, like a mobile app or a news aggregator or (of course) your website. In the case of your website, your CMS pushes all those fields through a template, and voila, the page is published beautifully and your readers eat it up.

What If My Fields Have Fields?

Here’s where it gets interesting. Back to our earlier example: let’s say your article has a couple slideshows. Each slideshow has a few images, captions, and links. Suddenly your discrete, single-purpose field (slideshow) has its own fields (images, captions, links). And, you may want to add a slideshow virtually anywhere in the flow of the page. Perhaps the page goes text, slideshow, text. Or maybe it’s text, slideshow, text, some tweets, another slideshow. And now you want to swap some things around. Again, you should be able to do all that, easily.

Drupal Paragraphs

Enter the Drupal Paragraphs module. Paragraphs takes the approach of creating content bundles, or collections of fields, that can be mixed and matched on a given page in virtually countless configurations. They’re called “Paragraphs” because they are flexible, structured building blocks for pages. The name is a little misleading; in fact, they are 100% configurable groups of fields that can be added, edited, and rearranged however you want on a given article. You can have paragraph types for slideshows, pull quotes, tweets, lists of related content, or virtually anything else. Paragraphs are building blocks: smaller elements that can be combined to build a page. And like I said earlier, you should be able to easily make pages from collections of smaller elements.

Drupal Paragraphs is Sort of Easy

We use Drupal Paragraphs whenever a particular type of content (a news article, blog post, etc.) is really built up of smaller, interchangeable collections of other fields (text, slideshows, videos, etc.). Drupal Paragraphs are flexible and organized. They let authors create whatever kinds of pages they want, while storing content in a way that is structured and adaptable. Migrations with Paragraphs are generally easier than migrations with special, proprietary embed codes. Breaking content types into Paragraphs gives authors the flexibility they need, without sacrificing structure. You don’t end up with a bunch of garbage pasted into an open WYSIWYG field.

So what’s the catch? Well, the interface isn’t awesome. Using Drupal Paragraphs can add a lot of complexity to the authoring experience. Forms will have nested forms. It can be overwhelming.

Alternatives to Drupal Paragraphs

As I’m writing this, another approach to page building is gathering momentum in the Drupal universe. Layout Builder is currently an experimental module in core, and slated to ship as a stable release with Drupal 8.7. Layout Builder provides a slick drag-and-drop interface for editors to build pages from blocks and fields. We’re excited to see how Layout Builder develops, and to see how well it performs for large editorial websites. For websites with hundreds or thousands of articles, managing pages with Layout Builder may be difficult. As Drupal’s founder, Dries Buytaert, pointed out in a post late last year, “On large sites, the free-form page creation is almost certainly going to be a scalability, maintenance and governance challenge.”

Other open source CMS communities are seeing a similar rise in the demand to provide authors with flexible page-building tools. WordPress released Gutenberg, a powerful drag-and-drop editing experience that lets authors quickly build incredibly flexible pages from a massive library of components. It’s worth noting Gutenberg is not without challenges. It poses accessibility issues. Antithetical to the themes in this post, it does not necessarily produce structured content. It relies on proprietary tokens for referencing embedded blocks of content. But it is very flexible, and offers an expressive interface for authors. For Drupal users, there’s a Drupal port for Gutenberg.

For us at Aten, the balance comes back to making sure content is stored in a way that is structured, can be adaptive, is reusable, and is relatively easy to migrate. And that you, the writer, can easily build flexible web pages.

Structured and Adaptable: Drupal Paragraphs with Layout Control

We’ve been working on an approach that keeps Paragraphs in place as the primary way content is managed and stored, but also gives authors the ability to easily control layout. Using Drupal’s core Layout Discovery system, Entity Reference with Layout is a custom field type that combines layouts and Paragraphs. It’s still in very early experimental development, but we’re excited about the impact this approach might have on making it even easier to create flexible pages. And it uses Paragraphs for content storage, with the benefits we’ve already touched on: content is well-structured and relatively easy to migrate. It’s not as flexible or robust as Layout Builder, but might be a great option for authoring flexible pages with Paragraphs. (More on this in a future post.)

Reusable and Flexible: Advanced Paragraphs

Since Drupal Paragraphs are themselves collections of flexible fields, there are all kinds of interesting ways they can be applied to building complex publishing features. We’re working with a client in publishing who needs the ability to completely customize the way content appears on their home page. They would like to promote existing content to the homepage, but they may want to override article titles, images, and summaries. Since the article authors aren’t the same people editing the home page and other key listing pages, they didn’t want authors to have to think about all of those variations. The way content is presented on an article page isn’t always the best-suited for the homepage and other contexts. We used paragraphs to give home page editors the ability to drop articles onto the page, with fields for overriding everything they need to.

Where to Go From Here

Your CMS should make it easy to write content and build pages. If you’re interested in seeing a demo of Drupal Paragraphs, Layout Builder, or Gutenberg, drop us a line. We’d love to help.