I really don’t like WYSIWYG editors. I know that I’m not alone, most developers and site builders feel this way too. Content creators always request a wysiwyg, but I am convinced that it is more of a necessary evil and they secretly dislike wysiwygs too. You all know what wysiwygs (What You See Is What You Get) are right? They are those nifty fields that allow you to format text with links, bolding, alignment, and other neat things. They also can have the ability to add tables, iframes, flash code, and other problematic HTML elements. With Drupal we have been able to move things out of a single wysiwyg body field into more discrete purpose-built fields that match the shape of the content being created and this has helped solve a lot of issues, but still didn’t cancel out the need for a versatile body field that a wysiwyg can provide.
Content creators yearn for the flexibility of creating a page that matches their vision for how they want the layout. Front-end developers and designers want to be able to rigidly style a site that always looks good, and that clashes with the unexpected markup that a WYSIWYG can produce. These differing priorities can resulting in a real mess of a page. It’s been a struggle as old as the CMS itself.
Solutions of the Past
As I mentioned above, the Drupal solution to runaway WYSIWYG markup is purpose-built fields to catch all specific sections of content that you can.Instead of allowing the whole page to be created in one WYSIWYG field, we would have a field for an image, a summary, some various highlight sections, etc. One problem still remains, content creators want to be creative and have various patterns of content depending on what they are writing about. This includes images floating in every which-way, videos in the middle of an article, quote blocks, content in columns, and the list goes on. You can’t just build a bunch of types of fields for this problem. In the past, I tried using Field Collections and custom form alters to build a user interface that allowed them to select and only see the relevant fields, but this still proved to be too rigid.
The Modern Solution
Enter Paragraphs, the Drupal contributed module that can ultimately solve this problem. I started using Paragraphs with Drupal 7 back around 2014 and it really changed the way I thought about editing and creating content on a Drupal site.
With Paragraphs you can define little entities of fields much like the Field Collection module but less static. The difference is that you can access all or some of the different paragraph entity types from a single field on your content type. This single Paragraph content field will replace your body content wysiwyg field entirely. The Paragraph content field will allow you to endlessly add in different paragraph types and provides a method to reorder after creation. Working with your content creators, you can determine an unlimited number of content patterns that they would like to use. For example, you can create paragraphs with the fields required to make a slideshow, embedded video block, accordion content, or another that is an entity reference field to related articles, and one more that is simply a text area field. With this toolkit of content patterns your content creators can build content in any array of patterns they wish.
Paragraphs will satisfy the creative control that the editors of your site desire and will make them finally admit that they too hate that weird little wysiwyg field. When the situation arises that they want to do something new, it’s just a small revision to create a new paragraph type. Your frontend developers and designers will also be happy that they can strictly control the visual aspects of the individual Paragraphs with specific template files and targeted SASS styling.
Extending the Concept
An overlooked but very powerful use of Paragraphs is using it without any fields at all. Let's say that you want to add a newsletter signup form in the middle of your article. Simply define a paragraph called Newsletter signup then with a bit of custom code write a signup form, you could even have it automatically pass the signup source of the article in a hidden field. Next, all the article writer needs to do is drop the Newsletter signup Paragraph wherever they want it to appear within the article content. Another example of a field-less paragraph that we have used in the past is an about the author section. There are no fields needed, just add the paragraph and write code to look up the article’s author and write a template file to display a bit of author info with a headshot, simple as that.
I could write on and on about the possibilities and use cases for paragraphs, but you should really just download it and give it a test drive. It’s like introducing a mini block system into an individual article of content. If you are planning a new build or have an existing Drupal site, don’t hesitate to add Paragraphs. Your content creators and editors will love you for it.