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).
Having inhouse’ experience with both Drupal, WordPress and React, we started porting Gutenberg to Drupal 8. Spoiler alert: It worked, and it’s smooth.
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:
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.
Not only do the page blocks have a search box top left, but they are accessible inline using “/”.
Embed social posts or videos by simply pasting the URL. Watch it expand!
Visual editor and code editor
Switch to code editor to tweak the output. Note that the markup is clean and nice.
Blocks can have child blocks, making it easy to split your blocks into columns on a grid:
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.
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?
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.