Wp-calypso: Gutenberg: Reusable block uneditable in post or page

Created on 14 May 2019  路  3Comments  路  Source: Automattic/wp-calypso

1) Use the Block Editor with a simple WordPress.com site in either /block-editor, or /wp-admin
2) Insert a reusable block
Screen Shot 2019-05-13 at 3 30 02 PM
3) Click on the reusable block to gain focus

Screen Shot 2019-05-13 at 3 29 01 PM

Expected: Edit button is clickable
Actual: Edit button is disabled

[Goal] Gutenberg [Pri] High [Type] Bug

All 3 comments

Some initial investigation:

The <ReusableBlockedit /> component decides if the author can edit its given reusable block.

canUpdateBlock: !! reusableBlock && ! reusableBlock.isTemporary && !! canUser( 'update', 'blocks', ref )

This is used to determine the enabled/disabled state of that button. This also limits our problem domain to whether we thing a reusable block isTemporary or if we aren't getting sufficient permission.

In some console debugging I discovered that isTemporary and ref were fine which led me to investigate the permissions check.

In Core the wp_block API endpoint call returns permissions information in a request header as Allow: GET, [PUT], [POST], [DELETE], [鈥

Screen Shot 2019-05-16 at 6 03 46 PM

On WordPress.com / public-api.wordpress.com that header is not coming through and thus the permissions information isn't getting set inside of Gutenberg. The editor doesn't consider the absence of the header information as a failure but rather as a positive confirmation that the requisite permissions are missing.

Screen Shot 2019-05-16 at 6 06 59 PM

However, we can see that due to the _envelope query argument we _are_ getting the Allow header but it's coming in as a headers property on the message body vs. in the actual HTTP section of the packet.

Screen Shot 2019-05-16 at 6 09 04 PM

I'm not sure if we should already be able to safely use the _envelope query arg and not have it impact the editor but we should probably make sure that the _envelope is handed in the appropriate apiFetch middleware and that it's working as we expect.

Nice investigation @dmsnell!

We were already handling enveloped responses for the fetchAll middleware. The problem was caused by our custom apiFetch middleware always parsing the response and returning an object with the body data rather than a fetch-like object with all the info needed, including the headers.

D28355-code should fix that.

Closed via D28355-code.

Was this page helpful?
0 / 5 - 0 ratings