Add separate widgets endpoint #25958
Conversation
There is some more clean up I'd like to do, but I wanted to get this open so that the changes to the Gutenberg client can be discussed. As I see it, the Client will now need to do a batch request to update all dirty widgets. Then if the order of widgets has changed, a |
@TimothyBJacobs I can't see this working in postman. Don't we need to load the file here Lines 35 to 37 in c1390e0 and setup the class here Lines 191 to 198 in c1390e0 If you can do this, I will continue my testing. |
@spacedmonkey yep its completely broken at the moment, sorry for the early ping. Working on a fix. |
'id' => $widget_id, | ||
'id_base' => '', | ||
'sidebar' => $sidebar_id, | ||
'widget_class' => '', |
spacedmonkey
Oct 8, 2020
Member
Add a unit test for namespaced widget class.
Add a unit test for namespaced widget class.
Huzzah, PHPunit is now passing! Will start on your suggestions @spacedmonkey in a bit. |
In my testing, a widget with namespace works.
|
@spacedmonkey looks like the tests need to be updated for the new fields. |
@TimothyBJacobs I am thinking about creating that widget_type api and moving some of the fields out into that. |
|
…int. This allows for sending and receiving full widgets objects in the sidebars endpoint directly to allow for an easier transition on the client.
Widgets need to be in a valid sidebar to have the necessary context to render.
…point a proxy to the new endpoint.
It is part of the inactive sidebar which doesn't support rendering.
3c4dbd3
to
97d5df3
The failing test is |
I checked out this PR and tested adding, removing and updating blocks and legacy widgets in the widgets editor. The only problem I could spot is that reference widgets (widgets registered without using You can test this by adding this code, going to Appearance → Widgets, inserting a Marquee Greeting into a widget area, then clicking Save. wp_register_sidebar_widget(
'marquee_greeting',
'Marquee Greeting',
function() {
$greeting = get_option( 'marquee_greeting', 'Hello!' );
printf( '<marquee>%s</marquee>', esc_html( $greeting ) );
}
);
wp_register_widget_control(
'marquee_greeting',
'Marquee Greeting',
function() {
if ( isset( $_POST['marquee-greeting'] ) ) {
update_option(
'marquee_greeting',
sanitize_text_field( $_POST['marquee-greeting'] )
);
}
$greeting = get_option( 'marquee_greeting' );
?>
<p>
<label for="marquee-greeting">Greeting:</label>
<input
id="marquee-greeting"
class="widefat"
name="marquee-greeting"
type="text"
value="<?= esc_attr( $greeting ) ?>"
placeholder="Hello!"
/>
</p>
<?php
}
); |
Reference widgets always have an id, so they end up being routed to the update_item endpoint instead of the create_item endpoint. We now allow for saving reference widgets that aren't yet assigned to a sidebar if they include their desired sidebar in the request.
…nberg into add/widgets-endpoint
Thanks for testing @noisysocks! I've pushed a fix. The issue was that reference widgets always have an ID, so it was detected as an update. However, the widget wasn't yet assigned to a sidebar which the update endpoint expects. I've fixed this to allow for reference widgets to pass the sidebar id to update and treat that as creation. |
Tested the widgets editor again and nothing breaks |
9d8d9e5
into
WordPress:master
Thanks for testing @noisysocks! |
TimothyBJacobs commentedOct 8, 2020
•
edited
Description
This separates the widgets handling from sidebars into a dedicated widgets controller.
Fixes #25232.
How has this been tested?
Automated tests in progress.
This will require changes to the client.
Types of changes
Breaking change.
Checklist: