wp-rest-blocks
wp-rest-blocks copied to clipboard
spacedmonkey
Plugin breaks on block editor WordPress 5.9 RC
Hey! I'm testing out the latest version of WP, 5.9 on a small project. And right now it seems like this plugin breaks the block editor. This plugin seems to prevent rendering post content in the editor at all.
I think the issue is naming the field in the api blocks. Because if I rename the field to something different the editor works as expected again. I haven't been able to find the real issue in the gutenberg code. But I'm guessing that they somehow populate the blocks property in the code. But when it is already set initially they don't touch it. I'm not sure but will keep digging deeper.
I did some more testing and my assumption seem to be more or less correct.
The following code in the terminal when editing a post:
window.wp.data.select('core/block-editor').getBlocks()
Prints a block with the same shape and structure as this plugin generates. But that is not the shape that the editor expects.
@erralb No proper fix. I brought the whole plugin into my own source and renamed the api field to something like wp_blocks instead.
@adambrgmn thanks for your response.
As a workaround, I installed the "Free Soul Deactivate Plugins" plugin and I deactivated the WP Rest Blocks plugin when editing posts / using Gutenberg : https://wordpress.org/support/topic/deactivate-plugins-on-editor-gutenberg/
It's fixing the block editor, but I still have to check if the blocks are correctly queried through the API.
For now I am using this hotfix plugin that renames the blocks attribute to parsed_blocks (but only if we are in the block editor).
https://gist.github.com/lukasbesch/ed9cdd5c7df0eb620b2b9cb48fd7935c
I could not find out yet why exactly blocks does not work as an attribute. As the fix is only needed for the block editor I assumed it has something to do with the internal/preloaded requests. But even if I forcefully do not preload the current post with edit context, it does not work. So somewhere in the initialisation of the block editor something breaks with the blocks key.
I am seeing this issue on Wordpress 6.0.1.
I love this plugin, I was able to make an awesome website with it by pulling the images out of the gallery block. But now, on both the Wordpress website and the Wordpress app, my posts don't show the gallery blocks. I have to disable the plugin to be able to edit or see anything.
It would be great if this feature could make it as an official Wordpress feature in the REST api. I believe this is the ticket on the Wordpress tracker.
I am seeing this issue on Wordpress
6.0.1.I love this plugin, I was able to make an awesome website with it by pulling the images out of the gallery block. But now, on both the Wordpress website and the Wordpress app, my posts don't show the gallery blocks. I have to disable the plugin to be able to edit or see anything.
It would be great if this feature could make it as an official Wordpress feature in the REST api. I believe this is the ticket on the Wordpress tracker.
That ticket was last modified 2 years ago. This is not looking good.
It's a shame, this one little feature could really modernize WordPress a lot, by allowing Gutenberg to be used as a headless CMS editor.
I have since migrated to Sanity, but if someday all block data comes through over the API on Wordpress, I'll be right back to using it!
I have since migrated to Sanity, but if someday all block data comes through over the API on Wordpress, I'll be right back to using it!
I'm currently working on a starterkit using Astro as the front-end and WordPress as the backend.
So far I'm not running into any problems whatsoever. I do however stick to ACF blocks instead of Gutenberg blocks, since the Gutenberg API & structure changes way too frequently and is more prone to bugs.
Also in a headless setup, native Gutenberg doesn't make too much sense anyway, since you'd have to maintain the live preview mode in WordPress as well.
Hope this helps, if you're ever planning to use WordPress with this plugin again. :)