Drupal Gutenberg is the newest shiny editor introduced into the Drupal community, attempting to improve the default authoring experience by combining Drupal's powerful entity/field architecture with the WordPress' Gutenberg editor. In this post, I'll be sharing my own experience with the editor, what I feel are its current limitations and my hopes for its future.
Gutenberg was initially released into the content management system community as part of WordPress 5.0’s release; it was presented as a replacement for the simple but reliable TinyMCE editor that WordPress had been using for years.
It introduced an innovative approach to content editing where website components could be visually inserted into the page in an intuitive manner in the form of individual blocks rather than relying on basic HTML, WordPress shortcodes or custom input fields (through plugins like Advanced Custom Fields, CMB2 or Meta Box). It opened up a world of possibilities with regards to creating dynamic content layouts without having to resort to multiple fields, or requiring HTML knowledge in order to add the relevant styles.
The initial release was unfortunately met with mixed to negative feedback, with some users avoiding the upgrade to 5.0 and actively looking for ways to switch back to the TinyMCE-based Classic Editor which their content editors had grown familiar with.
It wasn’t encouraged by the fact that the initial product was a little buggy accessibility-wise, had some HTML implementation patterns which certain users weren’t comfortable with e.g. inlining the CSS styles rather than implementing them as a class - classes would be the preferred implementation as it ensures that the site theme decides how to it's displayed. There also wasn't an easy upgrade path for existing sites which made use of the custom field approach without incurring significant development costs.
Gutenberg has undergone a lot of development/iteration since its initial launch, attempting to address the various issues it had with its release - at the time of writing, it has over 11,000 commits. It's also gaining a lot of traction with the WordPress community, with more and more plugins providing integration for it.
Drupal Gutenberg's dynamic editing experience
Drupal Gutenberg is a definite improvement over Drupal core’s CKEditor 4 in terms of a visual content editing experience as a WYSIWYG editor. It comes with a range of built-in blocks for basic components which editors are familiar with such as tables, lists and paragraphs. It also allows editors to insert raw HTML if required, its implementation of the raw HTML editor isn't currently as sophisticated as the WordPress version - the WordPress version still allows the usage of the Classic TinyMCE editor inside Gutenberg.
The main strength of the Gutenberg editor is its flexible UI API which is powered by React - a popular JavaScript framework that's been garnering a lot of traction with the front-end developer community.
The typical Drupal solution is to create content fields and Paragraphs components which can be inserted into the content in order to build the final page output. Paragraphs is a contributed module which allows editors to insert content into a page as Paragraphs components, these components can have their own fields and configurations which are then used to produce semantic HTML.
However, when the client has requirements for an easy way to allow their content editors to insert really dynamic content as Paragraphs, it's extremely easy to run into “Paragraphs hell” - a situation where a lot of Paragraph components are inserted into the page each with individual fields/configurations which become unwieldy for editors to use, this particular problem is solved by using Gutenberg.
Gutenberg to Drupal field mapping
One of the main concerns we had regarding switching to Drupal Gutenberg was the fact that most of the internal fields typically used in most of our content types would now have to be hidden away into a small accordion at the bottom of the page, which isn't good from a user experience point of view - especially when the page contains a lot of text.
In one of the most recent releases, the module exposed an API for mapping Gutenberg block content to internal Drupal fields so that they can be used for things like the page title, featured image, content summary etc. This feature is a definite step in the right direction, however I feel there's still more that could be done in terms of improving the UX integration of Drupal's fields into Gutenberg in order to make it a more cohesive experience.
Potential blockers
Although the module is functional and provides some added benefits, there are still some potential points that site developers need to weigh before going all in and using it on their site as the sole content editing solution.
Slower release cycle
Due to the fact that the upstream plugin is still under a lot of active development, and the nature of the Drupal plugin being a port handled by a handful of developers, it'll always be slower to integrate any of the changes that have been implemented/released by the main plugin. There's currently no easy way to update Gutenberg in Drupal without waiting for the module developer to integrate, test and publish the WordPress changes to Drupal.
Template migration
This particular issue isn't specific to Drupal Gutenberg itself, but Gutenberg as an editor. Most of the blocks are saved as semantic HTML in the backend - this is fine for simple components like paragraphs and quotes where the semantic structure is standard and unlikely to change substantially in the future in order to meet design needs.
However when complex custom blocks are involved e.g. an accordion/tabset, or a block with multiple subcomponents which produce sizable output markup, there’s a possibility that the markup will need to change in order to meet specific global iterative design/functional changes in the future, with the default implementation which saves and serves the static HTML to the user, there’s no easy way to automatically migrate the HTML structure into a new format for all the frontend content without manually resaving the content/block on a page by page basis.
My general rule of thumb is that if your block's frontend HTML is:
- Likely to drastically change semantically in the future.
- Being reused across hundreds of pages.
Then the recommended approach is to implement the blocks as dynamic blocks i.e. blocks that are rendered dynamically by the backend, reusing all the attributes entered into the admin editor.
The ability to render any blocks through the backend is currently not available in Drupal Gutenberg, however it is an open issue that should hopefully be addressed in the near future.
Some features might be missing
While the Drupal module attempts to integrate the majority of the functionality of the WordPress version, there might be certain features which might be missing or behave slightly different for certain architectural reasons. The most of obvious example of this is the lack of a page title block. The Drupal Gutenberg editor keeps the title on the sidebar in line with default Drupal admin.
Another notable feature that hasn't been implemented on the Drupal version is the internal WYSIWYG HTML editor block which provides a way for existing content editors to use the classic editors in order to create content that might not be easily created in Gutenberg e.g. tables with headers on both axis. This currently would have to be done through the Custom HTML block.
Unsupported by certain third-party modules
Due to a mixture of the fact that most Drupal installations use CKEditor as the default editor and Drupal Gutenberg being relatively new to the scene, there might be some issues integrating it with third party modules which expect a certain content editor to be used. An example of this is the Real-time SEO for Drupal module - it unfortunately does not support Gutenberg at the moment due to it only supporting CKEditor's API. The good thing about Drupal as a platform being open-source is that features like these can be easily implemented and contributed back to the module for others to also benefit and improve upon.
Accessibility issues
There are also some slight accessibility issues which I’ve encountered by being somewhat of a “power user”. I tend to make use of keyboard shortcuts where possible to make life a lot easier, there’s been some occasional issues where pressing Ctrl + A, causes the entire content to be selected instead of the block which was actively being edited.
An example of this behaviour is exhibited while editing a Gallery image caption and attempting to select the text in order to copy and paste it:
As mentioned at the start of the post, there’s still some work being done to the project in terms of improving its accessibility/usability features, so hopefully this is addressed in an upcoming release.
Conclusion
Although far from perfect, I find that Drupal Gutenberg in its current iteration definitely provides an improved user experience and is perfect for situations where the content design and structure is well-defined and won't require a lot of dynamic configurations.
I also haven't ran into any site breaking bugs so far that would raise red flags regarding integrating it into production-level sites, I feel it's stable enough that I'm comfortable using it on them.
If the content type requires a lot of dynamic configurations referencing a lot of content/taxonomies, then there's still a use case for keeping the default Drupal fields/Paragraphs solution, whereas if the content type is particularly text-heavy with the occasional image/quotes e.g. Blog posts, then Gutenberg would be the perfect fit. If you do want to take it out for a spin, I'd recommend enabling it on a dedicated content type with a handful of custom fields at most.
If the project can gain more community support, I can definitely see it being a popular solution for sites with a lot of static content where there’s a priority on a flexible editor experience. And with the module being an open-source project, the sky really is the limit for its future!