Gutenberg: Site Editor - editing a specific Post dirties the home page instead.

Created on 15 Jul 2020  路  8Comments  路  Source: WordPress/gutenberg

Describe the bug
In the Site Editor: Editing and saving changes to a post dirties/saves the home page instead.

To reproduce
Steps to reproduce the behavior:

  1. Go to the site editor.
  2. Navigate to a specific Post via the top nav toolbar.
  3. Edit the content of the post.
  4. Click 'Update Design' to open the save sidebar.
  5. Click 'review changes' in the save sidebar.
  6. Verify that the entity staged for changes is a page and not the post.
  7. Save and verify the page content was overwritten and the post content unchanged.

Expected behavior
The post to be the dirtied / saved entity.

Screenshots

wrong-thing-saved

Editor version (please complete the following information):

  • WordPress version: 5.5
  • If the Gutenberg plugin is installed, which version is it? Master (~8.5+)
[Feature] Full Site Editing [Status] In Progress [Type] Bug

Most helpful comment

Yep, that was it. PR should fix that scenario and I added a test to make sure it doesn't break in the future

All 8 comments

I'm currently not able to replicate this... One difference in my setup is that when I switch to a post, it shows the "singular" template rather than the "index" template. I wonder if it could be related

2020-07-15 12 18 40

Sounds like it could, since index is the catch-all fallback for all template types. Maybe try with 2020 Blocks (since I think that's what Addie is using, judging from her gif)?

I was able to replicate this by using the index template with a static homepage. Then, when I switched to an individual post, an edit to post content actually updated the homepage.

I also wanted to note that you don't have to edit the homepage first - you can just load the editor, navigate directly to an individual post, and then editing it will dirty the homepage.

Mid-way down the stack, the issue is coming from here:
https://github.com/WordPress/gutenberg/blob/79271eb7b36323743c68cf1ed51d66446ba0cb1f/packages/block-library/src/post-content/inner-blocks.js#L8-L12

I believe that onChange is not updating when postType changes (even though blocks does).

If we add a key (to force react to destroy and remount the component when the key changes) to this line, then it works correctly.

https://github.com/WordPress/gutenberg/blob/79271eb7b36323743c68cf1ed51d66446ba0cb1f/packages/block-library/src/post-content/edit.js#L14

I'm looking into useEntityBlockEditor to see which hook or component isn't updating correctly when postType changes.

I believe that onChange is not updating when postType changes (even though blocks does).

I am mistaken about this. onChange is updating when postType changes, so I think that the inner block controller is not handling this correctly.

Yep, that was it. PR should fix that scenario and I added a test to make sure it doesn't break in the future

Was this page helpful?
0 / 5 - 0 ratings