Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Try Legacy widget block #13511
This PR is a proof of concept of a legacy widget block. A block that allows existing WordPress widgets to be added as Gutenberg blocks.
The design is similar to the one proposed by @melchoyce in #4770 (comment) (option 1). Although it seems option two was preferred, it would require to expose each widget as a block similar to what embeds do, and it would increase the technical complexity and make testing/debugging harder, so I preferred to use option 1 for now. I will gladly iterate on the UX after this proof of concept gets more stable.
Some technical details
The available widgets are preloaded to Gutenberg similar to what happens with page templates.
REST-API user story
I want to able to pass a widget identifier to an endpoint, pass the existing widget attributes and the changes the user is making if any, and receive from the rest API, the sanitized new widget attributes ready to save and an HTML form that allows the user to edit the widget in the new state.
A very simple REST-API endpoint was implemented. The endpoint receives the previous instance of a widget (previous attributes) the changed instance of a widget (changed attributes if any) and returns the new instance of the widget and the HTML form that allows editing this widget.
The edit component of the block handles the start placeholder that allows selecting a widget, and the tab mechanism that allows switching between edit and preview.
On front end widget are rendered with a simple call to the_widget.
Awesome work here. What's the plan to move forward here.
And let's get some technical feedback here.
referenced this pull request
Jan 29, 2019
I think it should be divided into 3 parts:
The third part although smaller than this PR is still huge, but I don't think there is a possible usable logical division for this part.
I agree this provides a good use case for feature flags. Besides conditional JS code, we may also need some conditional PHP code. I'm not sure if feature flags will/should touch PHP logic. Probably for PHP code we can keep it in the plugin without conditions and don't merge it to the core. It will be an additional source of friction if later we need to move some PHP code to core as we will need to carefully select the parts of the code that will be moved.
Hi @mapk, the widget settings at least for the core blocks should just work and appear without problems. I tested in chrome and safari and they are working correctly in my case.
Hi @mapk, It turns out that my WordPress local install was modified with a display: none commented that I need to overwrite here. My last push adds a
2. The two "edit" buttons are a bit awkward.
3. Select to change widget loses settings.
For the REST API endpoint, you can cross-reference with some prior art in https://github.com/xwp/wp-js-widgets/blob/develop/php/class-js-widgets-rest-controller.php
Is there any need for the Update button? The Customizer normally does not include it, for example. It just listens to
Feb 8, 2019
requested review from
Feb 8, 2019
earnjam left a comment
Not sure if this is an issue with
Seems like some legacy widgets could have conditional output that would sometimes return nothing.
I updated the PR:
Users that don't have permissions to access the widget screen will not be able to set a widget on the legacy widget block. If they are editing a post with a legacy widget already inserted in posts they have permission to edit they can see the preview of the widget but not change the widget and are not able to change its settings.
We don't have PHP feature flags so I added comment blocks to make porting code to core in a release that doesn't include this phase 2 item easier.
This problem is caused by the ServerSideRender and we have an issue for it #13870. Given the already big size of this PR it is better to address this issue in a different PR.