Connnect gutenberg widgets screen to widget area endpoints#15074
Conversation
youknowriad
left a comment
There was a problem hiding this comment.
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.
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.
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.
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
youknowriad
left a comment
There was a problem hiding this comment.
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.