Add New Reusable Block interface displaying blank page

[willdelphia]

Describe the bug

Add new (reusable) block feature seems to be broken. When accessing through link on Manage All Reusable Blocks page or directly at .../wp-admin/post-new.php?post_type=wp_block

Error in console:

api-fetch.min.js?ver=2.2.5:1 GET http://gutentest.local/wp-json/wp/v2/blocks/43?context=edit&_locale=user 403 (Forbidden)

redux-routine.min.js?ver=3.0.3:1 Uncaught (in promise) Error: [object Object]

To Reproduce Steps to reproduce the behavior:

1. Go to any post or page
2. Click on Three Dots (More tools and options) icon
3. Click on "Manage All Reusable Blocks" (..../wp-admin/edit.php?post_type=wp_block)
4. Click add new (.../wp-admin/post-new.php?post_type=wp_block)
5. See completely blank page and errors in console.

Expected behavior I would expect a new reusable block creation interface.

Desktop (please complete the following information):

• OS: MAC OS Mojave
• Browser: Chrome Version 70.0.3538.102 (Official Build) (64-bit)

Additional context

• Wordpress beta 5.0-RC1-43944

[designsimply]

I tested with WordPress 4.9.8 and Gutenberg 4.5.1 using Firefox 63.0.3 on macOS 10.13.6 and was able to go to Reusable Blocks > Add New without any problems.

^{Seen at https://tan-otter.jurassic.ninja/wp-admin/edit.php?post_type=wp_block running WordPress 4.9.8 and Gutenberg 4.5.1 using Firefox 63.0.3 on macOS 10.13.6.}

Testing note: try testing with Chrome and then try testing with WordPress 5.0-RC1 to see if it is a problem happening only with one of those constraints.

[mrwweb]

This certainly deserves more testing, but I couldn't replicate this bug or find that error in the console.

Win 10, Firefox 63.0.3, WordPress 5.0-RC1-43944, Twenty Nineteen, no plugins.

[willdelphia]

I think it's worth mentioning that I am running the wordpress instance on a "Local By Flywheel" VM. (https://local.getflywheel.com/)

Also here's a complete copy of the console output, in case this helps illuminate the cause.

``` JQMIGRATE: Migrate is installed, version 1.4.1 [Violation] Forced reflow while executing JavaScript took 38ms api-fetch.min.js?ver=2.2.5:1 GET http://bugtest2.local/wp-json/wp/v2/blocks/13?context=edit&_locale=user 403 (Forbidden) (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 tryCatch @ wp-polyfill.min.js?ver=7.0.0:3 invoke @ wp-polyfill.min.js?ver=7.0.0:3 t.(anonymous function) @ wp-polyfill.min.js?ver=7.0.0:3 n @ api-fetch.min.js?ver=2.2.5:1 c @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 g @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 i @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 m @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 i @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 _ @ api-fetch.min.js?ver=2.2.5:1 API_FETCH @ core-data.min.js?ver=2.0.14:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 n.any @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 n.any @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 n.any @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 Promise.then (async) (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 t @ redux-routine.min.js?ver=3.0.3:1 n.iterator @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 n.any @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 t @ redux-routine.min.js?ver=3.0.3:1 n.iterator @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 t @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ data.min.js?ver=4.0.1:1 tryCatch @ wp-polyfill.min.js?ver=7.0.0:3 invoke @ wp-polyfill.min.js?ver=7.0.0:3 t.(anonymous function) @ wp-polyfill.min.js?ver=7.0.0:3 n @ data.min.js?ver=4.0.1:1 c @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 w @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 fulfill @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 tryCatch @ wp-polyfill.min.js?ver=7.0.0:3 invoke @ wp-polyfill.min.js?ver=7.0.0:3 t.(anonymous function) @ wp-polyfill.min.js?ver=7.0.0:3 n @ data.min.js?ver=4.0.1:1 c @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 a @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 (anonymous) @ edit-post.min.js?ver=3.1.2:12 n @ data.min.js?ver=4.0.1:1 r @ data.min.js?ver=4.0.1:1 zf @ react-dom.min.js?ver=16.6.3:69 Mf @ react-dom.min.js?ver=16.6.3:87 ph @ react-dom.min.js?ver=16.6.3:98 eg @ react-dom.min.js?ver=16.6.3:125 fg @ react-dom.min.js?ver=16.6.3:126 wc @ react-dom.min.js?ver=16.6.3:138 fa @ react-dom.min.js?ver=16.6.3:137 gg @ react-dom.min.js?ver=16.6.3:135 Ca @ react-dom.min.js?ver=16.6.3:133 og @ react-dom.min.js?ver=16.6.3:150 Rd @ react-dom.min.js?ver=16.6.3:150 bb.render @ react-dom.min.js?ver=16.6.3:200 (anonymous) @ react-dom.min.js?ver=16.6.3:153 mg @ react-dom.min.js?ver=16.6.3:148 Bc @ react-dom.min.js?ver=16.6.3:153 render @ react-dom.min.js?ver=16.6.3:202 Zn @ edit-post.min.js?ver=3.1.2:12 (anonymous) @ post-new.php?post_type=wp_block:1696 api-fetch.min.js?ver=2.2.5:1 Fetch failed loading: GET "http://bugtest2.local/wp-json/wp/v2/blocks/13?context=edit&_locale=user". (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 tryCatch @ wp-polyfill.min.js?ver=7.0.0:3 invoke @ wp-polyfill.min.js?ver=7.0.0:3 t.(anonymous function) @ wp-polyfill.min.js?ver=7.0.0:3 n @ api-fetch.min.js?ver=2.2.5:1 c @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 g @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 i @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 m @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 i @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 (anonymous) @ api-fetch.min.js?ver=2.2.5:1 _ @ api-fetch.min.js?ver=2.2.5:1 API_FETCH @ core-data.min.js?ver=2.0.14:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 n.any @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 n.any @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 n.any @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 Promise.then (async) (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 t @ redux-routine.min.js?ver=3.0.3:1 n.iterator @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 n.any @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 t @ redux-routine.min.js?ver=3.0.3:1 n.iterator @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 r @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 t @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ data.min.js?ver=4.0.1:1 tryCatch @ wp-polyfill.min.js?ver=7.0.0:3 invoke @ wp-polyfill.min.js?ver=7.0.0:3 t.(anonymous function) @ wp-polyfill.min.js?ver=7.0.0:3 n @ data.min.js?ver=4.0.1:1 c @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 w @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 fulfill @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 tryCatch @ wp-polyfill.min.js?ver=7.0.0:3 invoke @ wp-polyfill.min.js?ver=7.0.0:3 t.(anonymous function) @ wp-polyfill.min.js?ver=7.0.0:3 n @ data.min.js?ver=4.0.1:1 c @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 a @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 (anonymous) @ edit-post.min.js?ver=3.1.2:12 n @ data.min.js?ver=4.0.1:1 r @ data.min.js?ver=4.0.1:1 zf @ react-dom.min.js?ver=16.6.3:69 Mf @ react-dom.min.js?ver=16.6.3:87 ph @ react-dom.min.js?ver=16.6.3:98 eg @ react-dom.min.js?ver=16.6.3:125 fg @ react-dom.min.js?ver=16.6.3:126 wc @ react-dom.min.js?ver=16.6.3:138 fa @ react-dom.min.js?ver=16.6.3:137 gg @ react-dom.min.js?ver=16.6.3:135 Ca @ react-dom.min.js?ver=16.6.3:133 og @ react-dom.min.js?ver=16.6.3:150 Rd @ react-dom.min.js?ver=16.6.3:150 bb.render @ react-dom.min.js?ver=16.6.3:200 (anonymous) @ react-dom.min.js?ver=16.6.3:153 mg @ react-dom.min.js?ver=16.6.3:148 Bc @ react-dom.min.js?ver=16.6.3:153 render @ react-dom.min.js?ver=16.6.3:202 Zn @ edit-post.min.js?ver=3.1.2:12 (anonymous) @ post-new.php?post_type=wp_block:1696 redux-routine.min.js?ver=3.0.3:1 Uncaught (in promise) Error: [object Object] at redux-routine.min.js?ver=3.0.3:1 at redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 (anonymous) @ redux-routine.min.js?ver=3.0.3:1 Promise.then (async) n @ data.min.js?ver=4.0.1:1 c @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 a @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 (anonymous) @ data.min.js?ver=4.0.1:1 (anonymous) @ edit-post.min.js?ver=3.1.2:12 n @ data.min.js?ver=4.0.1:1 r @ data.min.js?ver=4.0.1:1 zf @ react-dom.min.js?ver=16.6.3:69 Mf @ react-dom.min.js?ver=16.6.3:87 ph @ react-dom.min.js?ver=16.6.3:98 eg @ react-dom.min.js?ver=16.6.3:125 fg @ react-dom.min.js?ver=16.6.3:126 wc @ react-dom.min.js?ver=16.6.3:138 fa @ react-dom.min.js?ver=16.6.3:137 gg @ react-dom.min.js?ver=16.6.3:135 Ca @ react-dom.min.js?ver=16.6.3:133 og @ react-dom.min.js?ver=16.6.3:150 Rd @ react-dom.min.js?ver=16.6.3:150 bb.render @ react-dom.min.js?ver=16.6.3:200 (anonymous) @ react-dom.min.js?ver=16.6.3:153 mg @ react-dom.min.js?ver=16.6.3:148 Bc @ react-dom.min.js?ver=16.6.3:153 render @ react-dom.min.js?ver=16.6.3:202 Zn @ edit-post.min.js?ver=3.1.2:12 (anonymous) @ post-new.php?post_type=wp_block:1696 ```

[mrwweb]

My tests were also with Local.

[willdelphia]

Update:

If I spin a completely new wordpress install with local and then add the Beta testing plugin and update to "Bleeding Edge Nightly" (In this case 5.0-RC1-43944) I get the error behavior.

However if after taking the steps above I also install the plugin called "Gutenberg" the error stops and I am able to see the appropriate page at wp-admin/post-new.php?post_type=wp_block

[willdelphia]

Same results when I tested on a new Amazon Lightsail instance. At first broken, then I added the 'Gutenberg' plugin and error stopped.

[designsimply]

I tested with WordPress 5.0-RC1-43945 on Chrome 70.0.3538.110 on macOS 10.13.6 and still cannot replicate. Host is Bluehost.

I noticed a 403 error in the console output you posted:

GET http://bugtest2.local/wp-json/wp/v2/blocks/13?context=edit&_locale=user 403 (Forbidden)

Can you verify the API isn't being blocked for some reason?

[willdelphia]

When I go directly to that url I see json:

{"code":"rest_forbidden_context","message":"Sorry, you are not allowed to edit this post.","data":{"status":401}}

[designsimply]

🤔 ok, the API needs to be accessible. I'm not 100% sure whether we're on the right track, but do you have a local firewall or security rules or a security plugin in your local setup even which might be the source of the trouble in this case?

I re-tested with a local install running WordPress 4.9.8 and Gutenberg 4.6 master @ 4178f2da4 and I was able to go to /wp-admin/edit.php?post_type=wp_block and click "Add New" to create and publish a reusable block using my local dev setup.

[dhirenpatel22]

I was able to generate the same issue in new fresh WordPress 5.0 setup. When I tried to add 'Reusable Block', it ended up showing me a blank screen. /wp-admin/post-new.php?post_type=wp_block

[willdelphia]

@dhirenpatel22 thanks for posting. I also get the same behavior with the new 5.0 release.

[vikaskhunteta]

I got the same issue on Windows 7 x64, PHP 7.2.12, MySQL 5.6.24, am I supposed to add 'Gutenberg' plugin?

[M1k3xUr]

I have a website already for testing themes and plugins and updated to 5.0. Testing Gutenberg by creating a new post from a theme with custom meta blocks to check it works, I get the "update failed" but, it's already published. Not sure what is the problem and the error comes from tinymce. Here are the view and the result.

and the console

[designsimply]

@M1k3xUr your issue looks unrelated to the rest of the thread here. Based on the error, it appears to be related to this TinyMCE bug https://github.com/tinymce/tinymce/issues/2194. Please try testing with all plugins turned off and using the default theme and again with your custom theme to verify the theme is truly the source of the problem. From there you can either wait for an update from TinyMCE or try adjusting your code to work around the problem defined in the TinyMCE issue.

[designsimply]

I re-tested a few more times and was able to confirm that going to Posts > Add New > More (top toolbar) > Manage All Reusable blocks > Add New results in a blank page and the following console errors but only from some servers and not others. In my case, I cannot see the problem if I use a local setup outlined in the Local Environment section in the Contributing documentation, and I cannot see the problem from one of my test sites hosted at Bluehost but I do see the problem if I create a temporary WordPress site using https://jurassic.ninja/. (1m38s)

Failed to load resource: the server responded with a status of 403 () https://little-shrimp-363.jurassic.ninja/wp-json/wp/v2/blocks/21?context=edit&_locale=user

Uncaught (in promise) Error: [object Object] redux-routine.min.js?ver=3.0.3:1

^{Seen at https://little-shrimp-363.jurassic.ninja/wp-admin/post-new.php?post_type=wp_block running WordPress 5.0.2 and no active plugins using Safari 12.0.2 on macOS 10.13.6.}

I also see the same failed API request for /wp-json/wp/v2/blocks/24?context=edit&_locale=user that @willdelphia noted earlier:

{"code":"rest_forbidden_context","message":"Sorry, you are not allowed to edit this post.","data":{"status":403}}

^{Seen at https://little-shrimp-363.jurassic.ninja/wp-admin/post-new.php?post_type=wp_block running WordPress 5.0.2 and no active plugins using Chrome 70.0.3538.110 on macOS 10.13.6.}

[jarekherisz]

I have the same issue, but when i installed plugin https://pl.wordpress.org/plugins/gutenberg/ it start work correct. Even I disabled or remove this plugin, it still works. Then it not nginix problem but some wordpress. Something what is changed by installing plugin https://pl.wordpress.org/plugins/gutenberg/

[meijerwynand]

Greetings,

Did a vanilla install of WordPress 5.0.2 via Softalicious installer on Cpanel.

Once WP was up, I installed and activated the recommended plugins.

Edited the "Sample Page"

• Able to "Add to reusable block"

Open "Manage All Reusable Blocks"

• Unable to create "New" - only provides a blank page
• If saved block is edited and saved as 'draft'/unpublished the block can not be selected to edit and the export json function does not work.

Edited the "Sample Page" - reopening

• Reusable blocks options are not available when you select the (+) to add blocks

Same error as reported here in dev tools

[heydey]

Hello, Similar experience with vanilla 5.0.2 installation on MAMP/Macos/Mojave. Click to add new block: {"code":"rest_forbidden_context","message":"Sorry, you are not allowed to edit this post.","data":{"status":401}}

[meijerwynand]

Solved my issue

@heydey

After the vanilla install mentioned above I installed the Gutenberg Plugin and I was able to make use of the reusable blocks.

[denmette]

So, I have the same issue. I solved my issue like @meijerwynand explained, so maybe take a look what you missed ... in the plugin.

[kjnedrud]

I've been getting the same issue and did some digging. I noticed that the request URL contains a post ID which is interesting because this only happens when trying to create a new reusable block (editing existing blocks works fine). So I checked my database for the post ID in question and there is a post with that ID with the status auto-draft. Additionally, when I checked the wp_postmeta table for the same post ID, I found an _edit_lock row. So it appears that this is caused by WordPress creating an auto draft for a new wp_block post and locking it for editing. I'll keep looking into this further but hopefully this sheds a bit more light on the situation.

[designsimply]

I re-tested today using WP 5.0.4-alpha-44523 and also with WP 5.0.3 using test sites created using https://jurassic.ninja/ and I can still repeat the problem but I found something interesting… if I activate the plugin at any point then it starts working normally even if I subsequently deactivate and delete the plugin! (1m55s)

Steps to reproduce:

1. Go to https://jurassic.ninja to create a new test site.
2. Delete all plugins.
3. Go to Posts > Add New > More > Manage All Reusable Blocks.
4. Click the "Add New" button and note the blank screen and the error in the console.
5. Go to Plugins > Add New and search for Gutenberg.
6. Install and activate Gutenberg then deactivate and delete it.
7. Go to Posts > Add New > More > Manage All Reusable Blocks.
8. Click the "Add New" button and note that it works normally.

Result: even if the "Add New" button on the "Manage All Reusable Blocks" wasn't working before, it starts working after the Gutenberg plugin is activated even if it is subsequently deleted. What a strange 🐛!!

^{Seen at https://bad-emu-474.jurassic.ninja/wp-admin/post-new.php?post_type=wp_block tested with WordPress 5.0.3 and with/without Gutenberg 4.8.0 using jurassic.ninja and checked from Firefox 64.0.2 on macOS 10.13.6.}

[desrosj]

So worked through this a bit today. I posted a lengthy description on the Trac ticket .

In summary: the REST API request to the blocks endpoint is returning a 403 error. I believe that this is causing the blank screen error that is being stumbled on. This should be fixed here. A REST API error should not cause a white screen for the user when editing a reusable block. At a minimum, an error message should be displayed with a path forward.

When the Gutenberg plugin is activated, the Add New Block page works and it continues to work even after the plugin is deactivated. This happens because the plugin adds block capabilities to the user roles, which are stored in the database. These are not cleaned up after the plugin is deactivated/removed, so they remain and the functionality continues to work.

This second issue brings up a bug that could probably be fixed in both locations (Core and the Gutenberg Plugin) so that there is consistency moving forward. The bug in core causing the 403 permissions issue should be fixed, and then, potentially, the plugin should have its capabilities updated to match what is currently in core.

[desrosj]

I'm adding this to 4.9 because IMO this is a bug that should be fixed in 5.1.

[youknowriad]

Agreed, this seems like a critical issue that should be backported to 5.1.

Just a small not on milestones and workflow, we use Gutenberg versions (4.9, 5.0...) for PRs and WordPress versions for issues.

[aduth]

There are a few contributing issues here:

• Core assigns is-fullscreen-mode to the block editor screen and relies on the editor to unset this class if the user is not using the fullscreen editing option. Thus, if the editor fails to load for any reason, the admin header/sidebar will not be visible, despite the markup being present.
• The editor does not render anything until the "post" (in this case, the new block) data is available. Since this is not accessible to the user by their capabilities, it will never render. This is why the editor gets stuck in fullscreen mode.
• As mentioned by @desrosj, Gutenberg explicitly adds the block permissions, while in core these are remapped to an equivalent post capability
  • These should be aligned. Specifically, this code ought to be removed from Gutenberg as part of a bump to require 5.0 as the minimum supported WordPress version.

To me then, the actionable items are:

• Gutenberg be made more tolerant to failed initialization
  • Render <FullscreenMode /> earlier to cancel fullscreen mode
    • Alternatively, avoid this being assigned by default in core
  • Avoid uncaught thrown error in failed request from data resolver
    • With fallback messaging about failed initialization?
• Core permissions need to be corrected for handling block editing
  • The capabilities mapping is hard to follow, but it seems to fail at a point of considering the user to have an edit_blocks capability
  • In my testing, the most direct fix is to add a new capabilities entry 'edit_posts' => 'edit_posts' to the core registration of the wp_block type.

There's still an open question as to whether this ought to have been handled already with the equivalent capabilities mapping. I think the issue here is that the capabilities mapping doesn't occur recursively. The triggering condition occurs on the singular 'edit_block' capability. Given the wp_block type is registered with map_meta_cap, this is then mapped to the edit_post capability and calls again to map_meta_cap. This in-turn maps back to 'edit_blocks' which is not an assigned capability for the user. My thinking is that either the wp_block type should not be registered with map_meta_cap, or the post-equivalent mapping should be reflected through the post type registration's capability property than in map_meta_cap, but I'm not too certain on how the current implementation was approached (cc @pento re: WP#43804).

[aduth]

For testing purposes: If you're unable to reproduce due to having once had the Gutenberg plugin active, installing the following plugin will reset all roles to their default set of capabilities.

https://wordpress.org/plugins/reset-roles-and-capabilities/

(You should probably only do this in a local development environment, since there may be unanticipated consequences of resetting roles)

[aduth]

I'm going to close this one as deferred to the corresponding Trac ticket, which has since been closed with a resolution slated for release as part of WordPress 5.1.

In #13468, Gutenberg's custom registration of the wp_block type will be removed, and thus fall back to the definition provided by core.

[condensed-io]

hope this helps someone because I ended up on this page when looking for the useless 'publishing failed' error message. For me it was because my session had timed out and all I had to do was refresh the page and retry publishing. Had this happen to clients recently too, not sure if the latest version of wordpress introduced something that's logging people out?

[designsimply]

not sure if the latest version of wordpress introduced something that's logging people out?

@condensed-io I don't think so. Also, the session timing out and being logged out are slightly different cases. Check out the issue at https://github.com/WordPress/gutenberg/issues/9260 which sounds to me like it's closer to what you've described.