New reusable block creation returning blank white screen

[umakantsharmamwb]

When trying to create a new reusable block, at the time of creating a new post, in wordpress5.0-beta5, the screen goes blank with js error -

Unhandled promise rejection Error: "[object Object]" wp-pollyfill.min.js-2:29718

[audrasjb]

Hello, welcome to WordPress Trac and thank you for this ticket,

5.0.3 is going to be released in a couple of weeks. We are currently sorting the remaining tickets in the milestone. It doesn't appear that ticket can be handled in the next couple of weeks (still needs a patch). Let's address it in 5.1 which is coming in February. Feel free to change/ask to change the milestone if you think the issue can be quickly resolved.

[desrosj]

@umakantsharmamwb I have not been able to reproduce the issue you have described. Can you please see if you are still able to produce the bug?

If you are, can you please give some more detailed instructions so others can reproduce exactly what you are seeing?

[umakantsharmamwb]

Replying to desrosj:

@umakantsharmamwb I have not been able to reproduce the issue you have described. Can you please see if you are still able to produce the bug?

If you are, can you please give some more detailed instructions so others can reproduce exactly what you are seeing?

@desrosj I have attached a gif with the steps, and tested it on fresh new wordpress - 5.3, with no other plugins!

​https://ibb.co/KVSMwLy

Thanks!

[juankvillegas]

I have exactly this same issue in a clean WordPress 5.0.3 installation with SSL and only 1 plugin enabled: Really Simple SSL

​https://ibb.co/KVSMwLy

[desrosj]

Thanks for the details, @umakantsharmamwb. I am able to reproduce what you are detailing!

So I did some digging on this. Looks like there is already an ​issue opened on the Gutenberg GitHub for this, but I am going to leave both open because I think there needs to be an update in both locations.

The REST API request to the blocks endpoint is returning a 403 error. I believe that this is causing the error in wp-polyfill that you are seeing. This should be fixed upstream. A REST API error should not cause a white screen for the user. At a minimum, an error message should be displayed with a path forward.

@designsimply also discovered a strange aspect of this. If the Gutenberg plugin is activated, the Add New Block page work and it continues to work even after the plugin is deactivated. This happens because the plugin block adds 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.

A related issue is #45423, which could potentially fix this problem.

[aduth]

The above patch adds a missing capabilities mapping from the registered wp_block post type from edit_blocks to edit_posts, since a role will never have the edit_blocks capability in a default installation.

As noted by @desrosj / @designsimply , this cannot be reproduced if you had ever had the Gutenberg plugin activated on a site. To work around this, you must deactivate the Gutenberg plugin and reset user roles to their default values. I used the following plugin to achieve this:

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

I detailed some more specific debugging information at the corresponding GitHub issue, relevant to the rationale for this change, and considerations for additional revisions.

​https://github.com/WordPress/gutenberg/issues/12324#issuecomment-455631774

The above patch is intended to serve as a most minimal fix to the issue.

[pento]

Ugh, this was ugly when I worked on it originally.

I vaguely recall there being a problem doing this with edit_posts, I'll need to dig into a bit.

The alternative was to add the edit_blocks caps the same way that the plugin does (#45423), but I haven't had the time to thoroughly investigate that, either.

[peterwilsoncc]

For reference:

The REST controller returns the 403 from src/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php:L404

The post type's capabilities are a bit of a mix.

• the three meta caps each end in _block
• the primitive caps are a 50/50 mix of *_blocks and *_posts

$ wp eval "var_dump( get_post_type_object( 'wp_block' )->cap );"

class stdClass#1635 (15) {
  $edit_post =>              "edit_block"
  $read_post =>              "read_block"
  $delete_post =>            "delete_block"
  $edit_posts =>             "edit_blocks"
  $edit_others_posts =>      "edit_others_posts"
  $publish_posts =>          "publish_blocks"
  $read_private_posts =>     "read_private_blocks"
  $read =>                   "edit_posts"
  $delete_posts =>           "delete_blocks"
  $delete_private_posts =>   "delete_private_blocks"
  $delete_published_posts => "delete_published_posts"
  $delete_others_posts =>    "delete_others_posts"
  $edit_private_posts =>     "edit_private_blocks"
  $edit_published_posts =>   "edit_published_posts"
  $create_posts =>           "publish_posts"
}

In map_meta_cap() some of the *_blocks are mapped to *_posts but I am not convinced they're being replaced there as intended as the replacement is occurring in the capability being checked rather than the capabilities (plural) that get passed to \WP_User::has_cap().

[peterwilsoncc]

After some testing and chatting to @pento, it looks like the better approach is custom caps for reusable blocks per #45423. A new patch has been uploaded on that ticket that solves the white screen errors on this one.

This ticket can remain open until a fix is committed against one ticket or the other.

[pento]

In 44687:

Blocks: Define the edit_posts capability on the wp_block post type.

Meta capability mapping doesn't recurse through multiple meta definitions, which creates a situation where the capabilities test is looking for the non-existent primitive capability edit_blocks, which should instead be mapped to edit_posts.

Defining the edit_posts capability when the wp_block post type is registered causes this check to change to to the edit_posts capability.

Props aduth.
Fixes #45373.

[desrosj]

#45514 was marked as a duplicate.