Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#45373 closed defect (bug) (fixed)

New reusable block creation returning blank white screen

Reported by: umakantsharmamwb's profile umakantsharmamwb Owned by: pento's profile pento
Milestone: 5.1 Priority: normal
Severity: normal Version: 5.0
Component: Editor Keywords: has-patch
Focuses: rest-api Cc:


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

Attachments (1)

45373-edit-posts.patch (601 bytes) - added by aduth 5 years ago.

Download all attachments as: .zip

Change History (19)

#1 @matveb
5 years ago

  • Milestone changed from Awaiting Review to 5.0.1

#2 @SergeyBiryukov
5 years ago

  • Component changed from General to Editor

#3 @pento
5 years ago

  • Milestone changed from 5.0.1 to 5.0.2

#4 @pento
5 years ago

  • Milestone changed from 5.0.2 to 5.0.3

#5 @audrasjb
5 years ago

  • Keywords needs-patch added
  • Milestone changed from 5.0.3 to 5.1

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.

#6 follow-up: @desrosj
5 years ago

  • Keywords reporter-feedback added

@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?

#7 in reply to: ↑ 6 ; follow-up: @umakantsharmamwb
5 years ago

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!

#8 in reply to: ↑ 7 @juankvillegas
5 years ago

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

Last edited 5 years ago by juankvillegas (previous) (diff)

#9 @desrosj
5 years ago

  • Focuses rest-api added
  • Keywords reporter-feedback removed

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.

This ticket was mentioned in Slack in #core-restapi by desrosj. View the logs.

5 years ago

This ticket was mentioned in Slack in #core-editor by aduth. View the logs.

5 years ago

#12 @aduth
5 years ago

  • Keywords has-patch added; needs-patch removed

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:

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

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

#13 @pento
5 years ago

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.

#14 @peterwilsoncc
5 years ago

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().

#15 @peterwilsoncc
5 years ago

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.

#16 @pento
5 years ago

  • Owner set to pento
  • Status changed from new to assigned

#17 @pento
5 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

#18 @desrosj
5 years ago

#45514 was marked as a duplicate.

Note: See TracTickets for help on using tickets.