Drupal needs a modern UI for rich content creation. This fall WordPress 5 is out with the brand new Gutenberg editor, a decoupled React based editing experience. It works great! And: It's open source, so we ported it to Drupal. Combining Drupal and Gutenberg is a killer combination, empowering content authors to build rich landing pages inside a rock solid CMS framework.
All Drupal project owners want to provide the best editing experience possible for their users. Whether your site is a university site, a non-profit site or a high traffic news outlet: You want to empower your editors to grow your digital presence.
Drupal 8 is a rock solid CMS framework packed with powerful admin features. Our only complaint? Drupal needs a modern UI for rich content creation.
Solutions based on Panels, Paragraphs or even the new Layout module contribute to a complex workflow. Drupal admin can feel quite overwhelming!
In 2018, you expect a CMS to be both flexible and easy to use. Building a shiny landing page shouldn’t be hard!
Gutenberg: A modern UI for content editing
We want to change this. We did a presentation on DrupalCamp a while back, and have explored quite a few different options. Surely, there must be some open source tools out there we could benefit from?
Early 2017 we were introduced to the WordPress initiative for improved editing experience. More functionality in a smoother UI? Hundreds of hours with user testing? Decoupled? React.js? Clean output? Open source? We were hooked.
Meet the ambitious WordPress Gutenberg project. The past few years, Automattic core devs have focused on:
- Simplifying the UI
- Making it simpler to build rich landing pages
- Learning from new platforms like Medium and Squarespace
- Decoupling the admin UI and attract new developers
Fast forward to 7000 commits later, Gutenberg is now in WordPress core (as of Aug/Sept 2018).
But why only WordPress – since it’s a highly decoupled JavaScript app, why shouldn’t it benefit other CMS-es as well?
Having inhouse’ experience with both Drupal, WordPress and React, we started porting Gutenberg to Drupal 8. Spoiler alert: It worked, and it’s smooth.
Demo time
Everything is a block
True to the Drupal paradigm, all elements on a page are (Gutenberg) blocks. A block is a piece of content that has a settings tray. Gutenberg comes with it’s own set of blocks, and so does Drupal core. This means all existing Drupal blocks are available in the Gutenberg UI. They can be inserted into a page wherever you please, alongside Gutenberg core blocks. And of course, you can extend them or build your own.
The block types working in the first release, are:
[demo]
Position content
There is no separation between what’s inside the editor and what is before or after. Positioning is a breeze!
Adjust font colors and sizes
The UI for tweaking fonts and colors is a pleasure to use.
[demo]
Searchable blocks
Not only do the page blocks have a search box top left, but they are accessible inline using “/”.
[demo]
Easy embed
Embed social posts or videos by simply pasting the URL. Watch it expand!
[demo]
Visual editor and code editor
Switch to code editor to tweak the output. Note that the markup is clean and nice.
[demo]
Layout handling
Blocks can have child blocks, making it easy to split your blocks into columns on a grid:
[demo]
The tech details
What about the architectural design? Well, glad you asked. While Gutenberg is mainly a React app, it is not built to be CMS-agnostic (yet; see my Github issue from 2017). We had to do this in multiple steps:
- Create a fork and clean out the WP specifics
- Create a standalone NPM package
- Create a Drupal module [coming soon; waiting to take over gutenberg namespace from Eaton :)]
This means we are maintaining a fork of the original Gutenberg project, and use this library as a depndency for the Drupal module. Each time Gutenberg is updated, the Drupal module gets a new release.
Some processing is needed to allow for this; the PHP is stripped away, and some JavaScript files are changed. Gutenberg runs on several JS modules and methods which are served client-side bundled on the WordPress global variable. Most of these modules were implemented with Gutenberg, but some of them are originally from Wordpress. To make Gutenberg truly CMS agnostic we had to re-implement those last ones.
After importing the @frontkom/gutenberg NPM package, there are 2 modules which had to be re-written for Drupal specifically. They are api-request which originally was made to talk to WP API, but now talks to Drupal, and url which define the editor routes (new page route, edit page route, preview page route, etc). The details are well documented in the NPM package README.
The wrapping Drupal module works as a text editor that can be enabled per content type. It only requires a long text field to work it’s magic. Once enabled, it completely replaces the node edit UI for the content type. It does however play nicely with the node edit sidebar.
[content type enable screenshot]
We aim to re-use Drupal styling for UI elements wherever we can. We want it to feel Drupal native – without missing out on any of the Gutenberg goodness.
What about existing initiatives?
The need to re-think aspects of Drupal admin has long been acknowledged by core. There even is a formal initiative: Admin UI & JavaScript Modernisation. People interested in the strategic initiative can get an overview in this Lullabot article: Drupal JavaScript Initiative: The Road to a Modern Administration UI).
However, re-building the full admin UI will probably take a year or two, and so far, the repos for the new admin theme and the JS based UI only have a handful commits.
We wanted to move faster. Building out a contrib solution outside of core gave us the freedom to experiment and release a version without any overhead. And while Proudly built elsewhere is a thing, bringing a WordPressUI into Drupal might not be for everyone. Gutenberg should probably stay in contrib.
Still, exchanging ideas is key. We would like to engage more in the #javascript Drupal Slack channel and proper issue queues.
