Widgets: Don't delete a widget if it is moved to a different area #32608
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
noisysocks
added
[Type] Bug
noisysocks
requested review from
adamziel,
draganescu and
kevin940726
as code owners
|
Size Change: -214 B (0%) Total Size: 1.04 MB
ℹ️ View Unchanged
|
noisysocks
added
the
Backport to WP 6.7 Beta/RC
kevin940726
reviewed
Jun 11, 2021
| for ( const widget of areaWidgets ) { | ||
| const widgetsNewArea = yield select( | ||
| editWidgetsStoreName, | ||
| 'getWidgetAreaForWidgetId', |
There was a problem hiding this comment.
This is surprising to me that getWidgetAreaForWidgetId actually uses getEditedEntityRecord under the hood so it's returning the latest edited state rather than the stored one. Is it intentional? Should we make it more explicit?
There was a problem hiding this comment.
Hm yes probably it shouldn't. What do you mean by make it more explicit? Happy to accept a ```suggestion 😛
There was a problem hiding this comment.
Oh I mean to rename getWidgetAreaForWidgetId to something like getEditedWidgetAreaForWidgetId. That's the easiest fix 😆
There was a problem hiding this comment.
Hm, we can't simply rename because it's a public function. We'd have to deprecate getWidgetAreaForWidgetId and add getEditedWidgetAreaForWidgetId. I'm not sure if it's worth it? What do you think?
I kind of want to change how all of this works after 5.8... I don't think we should have select( 'core/edit-widgets' ).getWidgetAreaForWidgetId() at all because we already have e.g. select( 'core' ).getWidgetArea() which can do the job if we add blocks to the widget area entity type.
There was a problem hiding this comment.
Sure! Whatever you think is the best 👍
|
I'm still able to reproduce the issue. Widgets are removed from They reappear in the "Inactive Widgets" area after switching the theme. |
|
I'm also able to reproduce the issue. I'm not sure the deletion that happens when moving the widgets is the problem, because if we just move widgets from one area to another without explicitly deleting them they don't reappear in inactive widgets. I suspect this is a bug with how the actual deletion works in the REST API, because I can reproduce it by directly adding a bunch of blocks in Inactive Widgets, saving, deleting all the blocks and then switching themes. A minimal test case could follow the steps I outlined above, and check that Inactive Widgets is empty in the new theme. |
|
@tellthemachines, you're right. It was the issue with the REST API It looks like widget REST API controllers are out of sync. Let's update them in the plugin since we have to support the old version of WP. |
|
Aha, nice solve. If you are using |
kevin940726
approved these changes
Jun 16, 2021
youknowriad
removed
the
Backport to WP 6.7 Beta/RC
youknowriad
pushed a commit
that referenced
this pull request
Jun 21, 2021
youknowriad
pushed a commit
that referenced
this pull request
Jun 21, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Fixes #32583.
saveWidgetArea()was issuing theDELETE /wp/v2/widgets/:idrequest whenever a widget had no associated block within the area being saved.gutenberg/packages/edit-widgets/src/store/actions.js
Lines 123 to 129 in 5940426
gutenberg/packages/edit-widgets/src/store/actions.js
Lines 188 to 194 in 5940426
This isn't right though because the block might not be in the area being saved because it was moved to a different area e.g. Inactive Widgets.
This means we delete the widget and then try to reference the deleted widget when sending
PUT /wp/v2/sidebars/:id.How has this been tested?
I tested by inspecting the stored widget data using WP CLI, which is a little convoluted, but here's a video:
Kapture.2021-06-11.at.15.18.34.mp4
I tried to write an E2E test but couldn't get one to fail with the bug present. I think this is because, in our simple E2E environment, everything looks visually OK because the block is deleted and then re-created...
On Monday I might spend some time making sure we have E2E tests for creating, updating, moving between areas, moving to inactive, deleting.
Checklist:
*.native.jsfiles for terms that need renaming or removal).