The editorial experience becomes more and more important for each CMS. Users want more control but easier interfaces. In Drupal, one of the biggest and most popular OpenSource CMSes on the market, the search for the best experience continues until today. Various approaches are tested by the community and with each edition, some new approaches are investigated and some are abandoned. From the perspective of a Drupal agency, it is quite interesting to watch this process unfold.

Let’s explore how Drupal editorial experience got to where it is today and where it is heading.

Drupal beginnings

Initially, Drupal pages were built on nodes. Think of a node as an article or page in a typical CMS. A node had a Title and a Body. You titled the node and inserted all the content in one big text field. Typically people would type in the body field the content of the page – this would be mostly text, but you could stick anything you like in there (HTML, images etc) Quite quickly people incorporated WYSIWYG editors into the body (CKEditor, TinyMCE and other ones were integrated as community-contributed modules). You could now author a quite complex page without knowledge of HTML.

The WYSIWYG’s were so popular, that in Drupal 7 CKEditor was added into Drupal core.

On the database side, everything  was still quite simple. A node table with title and an additional table for the body. That is how WordPress stayed pretty much till today. In Drupal however, the evolution continued. 

Drupal 6 – the domination of CCK & templating

At the time of Drupal 5, an initially small module was created, which in Drupal 6 completely changed the rules of the game (the Content Construction Kit module, aka. CCK).

CCK was a contributed module which allowed to add additional fields to nodes. This does not sound too exciting, but it was. The absolutely brilliant CCK module allowed users to add various fields (number, text, bool, select etc) and it was creating a separate database table for each field. The table field was matching what you wanted to store in it (A decimal, a float, a varchar, a text etc). On top of that, it was adding the field to the default content form. 

This was magnificent because you could create a form with multiple fields and then display the data in a template pre-built by the developer (an image on the right, stats on the left, long tests at the bottom — that sort of thing). This is how one was building pages in Drupal. The editor did not have to ‘design’ the layout in WYSIWYG anymore. You could just fill in a form with fields and the template took care of the rest. 

Moreover, you could now query in SQL for particular nodes by the field content. Eg. if you created a City node type and added a population decimal field to it, you could search for all cities with a population larger or smaller than a set amount. 

Very quickly after CCK, another module was created – the Views module. Views allowed users to build the queries in the admin interface. You could now create a list of cities ordered by population with a title and a teaser and some other data without the need to code anything. This was a massive breakthrough which allowed developers to create very compelling websites without writing a line of code. 

CCK was so popular that is was incorporated into Drupal in version 7 and Views followed in Drupal 8.

This is how Drupal websites were built for quite a while. Many are still built like this today.

Drupal 7 – First attempts at page layouts 

From Drupal 7 fields were considered a standard. Templating, however, was not sufficient for the community and clients. Drupal developers began searching for solutions to allow more control over the content display with just the UI.

The main reason for the search efforts is the way websites began to be built. The knowledge that an additional click reduces the chance the customer will get to the content was propagating. The approach of having a sidebar and dividing information into pages was no longer interesting. Long scrollable pages were born.

The advent of long landing pages with content in sections began somewhere in 2010. It was, however, the mobile that effectively killed the sidebar. You just could not fit a submenu in a sidebar on mobile. You now had to stick everything on one long scrollable page with multiple sections (scrolling on mobile is much easier than clicking links). And each section had to be interesting, compelling and different.

Drupal developers started to search for solutions on how to allow the editors to create sections on pages easier.

The initial solutions were:

• Panelizer – a module based on another one (Panels) which was effectively taking over the node display. Instead of just fields, you could now design your page to include blocks, fields, static images, views and various other elements Drupal renders. Editors could override “the default’ predefined layout on a node by node basis. The solution was great and got a lot of traction in the Drupal world.
• Paragraphs – a bit late to the party on Drupal 7, paragraphs nonetheless made a splash. It started to gain popularity very quickly. The main reason for that was that it was bridging the 2 worlds: drupal form building experience and freedom to add blocks while maintaining ease of use for the editors, which the above solutions did not have. 
• Context – Context a more general module, which gave users a mechanism for well – acting on contexts (eg what page you are on, what user or role you are etc. ) Using these conditions, one could add reactions (eg. show this block, set this setting). Context was very widely used for a while to arrange blocks on pages. If I am on this page, I want to see these blocks. The downside was you managed the layouts from a central location, needed admin privileges to manage the layouts and the UI was not straightforward. Not suitable for large websites.
• Blockreference – a simple yet powerful module which allows referencing blocks from a node and effectively stacks them one over the other. This solution did not get a lot of traction.

Current state in Drupal 8 and onwards

Drupal 8, being a very big re-write of Drupal has evened out the playing field a little, allowing the community to vote again on what it thinks should be the approach to building pages. 

Blockreference did not get a D8 version, mostly because entityreference module was now in Drupal 8 core and blocks became references. One could theoretically build pages like this using what Drupal gives out of the box, but that did not catch on.

Context did not manage to gather a lot of usages in D8 and until today does not have a stable release.

Paragraphs – initial winner

The paragraphs module came out as a clear winner. It was stable very quickly and became the de-facto standard in Drupal 8 for over a year. With over 140k installations it now runs one-third of all the drupal websites. It is also worth mentioning that popular Drupal distributions created on Drupal 8 chose paragraphs as the base of their content editing experience. These would be in particular Thunder – distro for publishing houses and Droopler – for building corporate websites. 

Here is an overview of how paragraphs work in Drupal 8. A lot of work is also being done to further improve the editorial experience in the Experimental widget.

Panelizer moved to the core (became Layout Builder)

Panelizer took a different road. It lingered on behind paragraphs in term of the number of installs but because of its popularity in D7 work was underway to migrate it into Drupal core (just as CCK in d7). It was however only in Drupal 8.5 that Layout Builder became available (as an experimental module). At Drupal 7.8 it became stable. 

Layout Builder offers great flexibility and great promise, but the UI even as of writing still has a long way to go to be self-explanatory (one needs a bit of training as many things are not obvious). Also, there is no clear “best practice” as to how to manage content now and what should be composing the pages. Integrations are also lagging, most importantly with search modules. 

Currently, there is no clear winner and best practice is not established yet. There is the paragraphs module with 100k installations, multiple integrations and a clear UI. On the other hand, there is the Layout Builder which is in Drupal core, what is an incredible strength. 

Still, though there are many modules which did not stand the test of time and were removed from the core.

Gutenberg (a WordPress editor)

Last but not least there is the Gutenberg project. It is the newest of the interesting editors in Drupal. It was ported from WordPress where it is the main editor.

Gutenberg is a React-based editor which takes over the whole editing experience giving the user a WYSIWYG like an experience. It differs in approach to Paragraphs and Layout Builder in that it does not store the layout or entities in the database, but it stores the generated HTML. You create the content with a WYSIWYG editor and the resulting HTML is saved. This makes it a true WYSIWYG readability of the content for machines (automatic updates or migrations of such content may be troublesome). Nonetheless, it continues to be integrated into Drupal better and better. With 900 or so installs it is by no means comparable to the two above but the speed of adoption is impressive. Check out a quick overview of Gutenberg in Drupal.

As you can see, there is no clear winner. Drupal community is still testing various approaches to building websites and empowering the editors. On the one hand, this is fantastic because competition helps the best solution win. On the other, the efforts of developers are spread over multiple various approaches, making progress slower. What is best? I do not know.