Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Currently doing a clean install or update to the latest Gutenberg version shows that the layout is visually broken compared to what it originally was in 2.x.
It appears that we are missing some of the generated styles which the WordPress version generates.
On first glance two issues pop out:
- The styles generated here are not actually used or added to the page similar to the Style engine used in #3424110: Add Style Engine for style rendering on server-side.
- Update the
LayoutProcessor::isSupported()so that it supports existing content which might not have thelayoutorstylesupports by checking if the block definition actually supports it.
Steps to reproduce
Spin up a new Gutenberg instance either in gitpod.io or simplytest.me/tugboat, and attempt to add 3 columns with background colours - the UI will be a bit broken.
Proposed resolution
Update the styles so that they have parity with the upsteam WordPress version for the same piece of content.
Due to how Gutenberg WP now works (requiring lots of custom block alterations to the the HTML via WordPress filters), we've had to incorporate a lightweight WordPress hook/filter system.
Remaining tasks
Currently exploring an option of bootstraping the Gutenberg WordPress plugin and WordPress as a dependency, and making the appropriate calls - that should increase feature parity as well as reduce the number of bugs introduced with the local ports.
This is available under the https://git.drupalcode.org/issue/gutenberg-3463527/-/tree/3463527-includ... branch, it's still a messy work in progress, but working.
It still needs work cleaning up, off the top of my head:
1. Caching.
2. Handling certain metadata.
3. Implementing a table to store certain user metadata.
4. Leveraging Drupal's library API to load the WordPress ones (e.g. hook_library_info_build() can build all the known WP/Gutenberg scripts and have them referenced that way).
5. Handle user roles/permissions in a manageable manner.
6. Weigh the best way to ship the patched version of Gutenberg/WordPress with Drupal with the least amount of complication.
User interface changes
UI should no longer be broken for existing blocks which support the layout feature.
API changes
1. WordPress filters are now supported. There's now a hook_gutenberg_init() hook which allows modules to safely call certain wordpress functions and filter which may be used to manipulate how certain things work.
2. There's now a hook_gutenberg_image_styles_alter hook to use to dynamically filter image styles.
| Comment | File | Size | Author |
|---|
Issue fork gutenberg-3463527
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #2
thorandre commentedThanks for submitting. I tried to recreate with DG 3 and Drupal 10 with the Gutenberg starter theme and I cannot recreate it.
Maybe I just miss out on the part of the UI you're thinking about?
Comment #3
codebymikey commentedHi Thor,
I also couldn't replicate the issue in the latest version, and on doing some further investigation, a fix for the missing styles was added in this commit.
I think my tests at the time of writing were based off
3.0.0-beta5which didn't have the fix, and was only added in3.0.0-beta6.The
LayoutProcessor::isSupported()review part was added for a reason though, I haven't worked on the 3.x branch in a while, but I'll be sure to update the issue summary accordingly if I run into any specific issues when I attempt an upgrade.Comment #4
codebymikey commentedUpon upgrading to the latest 3.0.5 version, I was finally able to replicate what my original issue was.
And can be replicated by creating the attached piece of content on a WordPress installation running Gutenberg 10.7.0 (equivalent of Drupal's v2.14) and WP 5.9, then later viewing the same content after updating to Gutenberg 16.7.0 (equivalent of Drupal's 3.0.5).
The frontend styles and HTML has changed enough that it no longer uses margins for the spacing, however, those same classes are currently missing in the current Drupal implementation and messes up the layout:
The expected HTML should be something along the lines of this and the styles and visual layout shouldn't have changed between upgrades:
14/02/2024 edit: It seems like the gap settings is now specified in the theme settings, however it seems to be missing the default Gutenberg theme.json which acts as the default settings.
I think this needs to be documented on the main README so that sites can effectively migrate to the new version without too many breaking changes.
Comment #6
codebymikey commentedWork done so far in the MR provides a way to provide theme.json support in Drupal (it can be added as a
theme.jsonfile or the<theme>.gutenberg.theme.ymlfile.But requires pulling in a bunch of WordPress code in in order to properly render and manipulate the blocks as WordPress does.
This provides the side effect of us essentially needing to reimplement a lightweight version of the wordpress filter system in order to get things to function as they should.
Comment #7
codebymikey commentedWhilst working on this, looked into an alternative approach which involves leveraging WP/WP Gutenberg directly in the code and working that way.
It requires patching them to work, but it's functional.
Comment #8
marcofernandes commentedFor 4.0.x the whole build system was refactored and it was implemented scripts to sync block supports processors and style engine from upstream.
https://git.drupalcode.org/project/gutenberg/-/blob/4.0.x/scripts/sync-s...
https://git.drupalcode.org/project/gutenberg/-/blob/4.0.x/scripts/sync-b...
So, the block supports script will get upstream function, transform it and place at src/BlockProcessor/block-supports
And the block processor, for example, LayoutProcessor.php will require the transformed layout.php.
Comment #9
codebymikey commentedThat's interesting to know! I like the npm-based approach.
I still need to sandbox it properly to see how it compares to the WordPress-based version.
But from a quick look, it seems like the regression from the sample test case in #4 still happens, since it requires special styles and logic which might not currently be accounted for.
The WordPress approach seemed like the best way at the time to keep future updates going without too many regressions since some of their features required PHP code, and aren't directly noticable until you manually test for it.