-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Connnect gutenberg widgets screen to widget area endpoints #15074
Connnect gutenberg widgets screen to widget area endpoints #15074
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't take a deep look yet, but that's a great start. Let's not add too much features and try to ship it step by step.
STORE_KEY, | ||
'getWidgetAreas' | ||
); | ||
for ( const widgetArea of widgetAreas ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes me wonder if we needed a "batched" save endpoint. I know there's no precedent in the REST API endpoints about this though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess most of the times the user will not change all the areas, and soon as we have some kind of "isDirty" dection we will only save the changed areas.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was contemplating having a POST
endpoint which can update multiple areas while writing #14812. Probably best to not get ahead of ourselves, though, as the design may yet change.
Hi @youknowriad, I guess this is the simples version we can have with just reading and write features without complex logic like "isDirty" and undo. This PR looks bigger because it contains the CPT and the endpoints which are going to be merged in #15014 and #15015 respectively. With these changes merged this PR is going to look much smaller. |
56f0948
to
b84a588
Compare
21b434e
to
627f0cd
Compare
347a161
to
6f67d60
Compare
627f0cd
to
4d3f032
Compare
4d3f032
to
f71ce9c
Compare
ac4967d
to
9b918ae
Compare
c9f9d2d
to
56b91da
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the updates, I have a last small remark
5afd069
to
5dfee2c
Compare
* Add new @wordpress/data-controls package * include new package in main package.json * Implement new package with @wordpress/editor store - this might be extracted to its own pull but added initially for testing. * docs tool generating this for some reason * include new package with doc generation tool * updated manifest from doc generation * updated package-lock.json * not sure why docs build tool is doing this. * use ternary * data-controls added to manifest by docs build tool * update README for editor package * updates to editor store actions tests - to use new data-controls package * add missing `@example` tag and regenerate docs * add tests for package * fix typo in changelog for package name * fix typo for package name in readme * more typos * Use lower version for initial release. Co-Authored-By: Grzegorz (Greg) Ziółkowski <grzegorz@gziolo.pl> * Add heading for API. Co-Authored-By: Grzegorz (Greg) Ziółkowski <grzegorz@gziolo.pl> * Update CHANGELOG.md version reference. Follows repo conventions about using Master as the version heading for unreleased changes. * add data-controls to webpack plugin config * Revert "add data-controls to webpack plugin config" This reverts commit 36a0b98. * use named export for controls object * update docs * woop fix import on tests
44ac2f2
to
4f2c6cc
Compare
Description
Depends on: #15435
This PR adds a store to keep the state in edit-widgets module, and connects the edit widgets screen to the widget-area endpoints being implemented in #15015.
It allows us to have PoC of the widget screen using blocks, covering the retrieving of legacy widgets, showing them and migrating the structure to blocks.
Legacy widgets are not working as expected because we have a bug on the widgets screen. The attributes of server-side rendered blocks are not correctly parsed in this screen.
If we paste
wp.blocks.parse('<!-- wp:latest-posts {"postsToShow":34,"displayPostDate":true} /-->');
on the console while the editor is open the attributes are correctly parsed on the gutenberg-widgets screen the attributes are not parsed.