I had a user trying to figure out how to adjust the spacing between their header and the rest of their content within FSE, but every time they changed the measurement and saved the change would revert back to the default state. I tested this with an Atomic site which would accept the changes, but every theme I tried on a Simple site resulted in the same issue. I tested Disco, Appleton, Archeo and Meraki and they all could reproduce the error.
Global Styles > LayoutBLOCK SPACING amount and save the changesThe changes would be retained upon saving.
The settings revert back to default instantly.
36731616-hc
https://user-images.githubusercontent.com/51870544/188231646-7fcb9a9d-42d3-40b7-a8db-bf0a4f02f234.mp4
Simple
No response
Replicated across Chrome, Firefox, and Safari.
Consistent
All
Yes, easy to implement
Depending on how much they are wanting to change the only thing I've found to work is CSS - this user was fine with just CSS to address the issue with their header block but if they're expecting it to work on all of their blocks that would get complicated quickly.
I was doing some dogfooding on a site and ran into this, and wanted to add a little more information.
This actually seems to affect every setting under the Global Style Layout panel, not just block spacing. For example, you can't change the content width.
I also would recommend considering this for a higher priority, as the workaround for some of those settings can get a little tricky. For example, if you want to change the content width style, you have to do some pretty-involved CSS to override the values (because of how the base CSS rules are applied).
I also tested this, and I could replicate it on a simple site, on more than one theme, 'TwentyTwentyTwo' and 'Thriving Artist' (a paid theme).
Support References
This comment is automatically generated. Please do not edit it.
Another report where the layout dimensions change did not work.
@Addison-Stavlo I think it makes sense if Ajax grabs this issue. Feel free to remove it from your backlog, if you agree! 🙂 Also, on the off-chance someone has already started working on this, please reach out to us for pointers, suggestions, and whatnot!
I think it makes sense if Ajax grabs this issue. Feel free to remove it from your backlog, if you agree! 🙂
Sounds great. Thanks @Copons !
I think this happens because Simple sites are still not fully updated to WordPress 6.1 and they are lacking this changeset which allows the blockGap property to be at any level. I cannot reproduce this on Atomic sites running WordPress 6.0 or self-hosted Jetpack sites running WordPress 6.1 and the lastest version of Gutenberg.
@david-binda do you have any idea about how long would it take to have that changeset in wpcom?
EDIT: Also asked in p94tqY-sD-p2#comment-1385
EDIT2: After discussing it privately with David, he told me that the changeset should land in WPCOM anytime this week.
I took a deeper look at this since WP.com Simple sites are already running WP 6.1 and the issue is still present. Turns out that it's a Core bug that happens only when the KSES filters are active (which is the case of WP.com Simple sites), so I reported it in the Gutenberg repo: https://github.com/WordPress/gutenberg/issues/45520
I will close this issue for now because it's a Core bug tracked by a Core Gutenberg issue (also assigned to the Ajax board).
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?v=4)
