WordPress.org

Make WordPress Core

Opened 2 weeks ago

Last modified 3 days ago

#51506 accepted enhancement

Add new block widgets editor

Reported by: isabel_brison Owned by: noisysocks
Milestone: 5.7 Priority: normal
Severity: normal Version:
Component: Widgets Keywords: has-patch early
Focuses: Cc:

Description

Add the edit-widgets package and the necessary changes to display the block widgets editor by default.

Change History (21)

This ticket was mentioned in PR #588 on WordPress/wordpress-develop by tellthemachines.


2 weeks ago

  • Keywords has-patch added

Adds @wordpress/edit-widgets package and the PHP changes necessary to display the block widgets editor by default.

In progress: block widgets currently not displaying.

Trac ticket: https://core.trac.wordpress.org/ticket/51506

#2 @TimothyBlynJacobs
2 weeks ago

We usually do the REST API endpoint merges in a dedicated ticket, #51460.

#3 @noisysocks
2 weeks ago

  • Owner set to noisysocks
  • Status changed from new to accepted

#4 @prbot
2 weeks ago

noisysocks commented on PR #588:

Spoke with @tellthemachines and am taking this one over. Nearly there, patch incoming.

This ticket was mentioned in PR #603 on WordPress/wordpress-develop by noisysocks.


2 weeks ago

Trac ticket: https://core.trac.wordpress.org/ticket/51506

Supersedes https://github.com/WordPress/wordpress-develop/pull/588.

This moves the the block-based widget editor over from Gutenberg into Core.

Broadly speaking, there's three parts to this:

  1. @wordpress/edit-widgets is added as a dependency. This is what contains the editor UI.
  1. wp-admin/widgets.php has been modified to branch between the old form-based editor wp-admin/widgets-form.php and the new block-based editor wp-admin/widgets-block-editor.php depending on get_theme_support( 'widgets-block-editor' ) and use_widgets_block_editor.
  1. Supporting infrastructure such as WP_Widget_Block and widgets.php?widget-preview={} has been copied over from Gutenberg.

This PR contains WP_REST_Sidebars_Controller and WP_REST_Widget_Utils_Controller so that it's easier to test, but these parts should be committed separately.

Tasks remaining:

  • [ ] Fix crashes in the editor by using latest @wordpress/* packages.
  • [ ] Fix appearance of block widgets in widgets-form.php.

#6 follow-up: @prbot
2 weeks ago

noisysocks commented on PR #603:

OK, I think this is ready to be reviewed and committed. The REST API endpoints are included so that it's easier to test, but these should be added separately via https://core.trac.wordpress.org/ticket/51460 before this PR is committed.

#7 in reply to: ↑ 6 @azaozz
11 days ago

Replying to prbot:

OK, I think this is ready to be reviewed and committed.

Yes, "played" with this for a while, all seems to be working pretty well.

One thing is the AYS when trying to navigate away from the screen before saving the changes don't seem to be in yet (I remember a discussion about it somewhere). Another is the Tests_WP_Customize_Widgets tests either need be bypassed or would need a utility function to switch to the old widgets code in the Customized.

#8 @noisysocks
11 days ago

Thanks for testing @azaozz!

The "Are you sure?" prompt issue was fixed in GB26081 which will make its way into Core when packages are published today or tomorrow.

I'll have a look today at addressing the failing tests.

#9 @noisysocks
11 days ago

I've addressed all of the test failures except for one in Tests_HTTP_Functions which is failing in `trunk`.

#10 @prbot
10 days ago

talldan commented on PR #603:

@noisysocks Just noticed we'll also have to make sure $current_screen->is_block_editor() is set to true for the widget screen as per https://github.com/WordPress/gutenberg/pull/26263

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


10 days ago

#12 @prbot
10 days ago

noisysocks commented on PR #603:

@noisysocks Just noticed we'll also have to make sure $current_screen->is_block_editor() is set to true for the widget screen as per WordPress/gutenberg#26263

I'm a little unclear on whether $current_screen->is_block_editor() should mean _this page is the post block editor_ or _this page has a block editor on it_. I'll set it for now and let's see how that goes.

#13 @noisysocks
10 days ago

  • Keywords early added
  • Milestone changed from 5.6 to 5.7

I spoke with @chanthaboune, @tellthemachines, @talldanwp and @kevin940726 and we decided to leave the block-based widgets editor out of 5.6. This will give the team more time to build a good experience for using blocks in the Customizer. See GB25818. The screen will remain enabled by default in the Gutenberg plugin.

This ticket was mentioned in Slack in #core by noisysocks. View the logs.


10 days ago

#15 @helen
9 days ago

For history and for when we return to this, I'm going to leave my "didn't make it for 5.6" thoughts here because they are to inform how we see the feature for core readiness:

My question for features that affect the front-end is "can I try out this new thing without the penalty of messing up my site?" - that is, user trust. At this current moment, given that widget areas are not displayed anything like what you see on your site without themes really putting effort into it and that you have to save your changes live without revisions to get an actual contextual view, widget area blocks do not allow you to try this new feature without penalizing you for experimenting.

Add to that that the customizer currently includes jumping to edit in context (avoiding the need to map esoteric names to visual areas that might change in different screen sizes), live and even real-time previewing of changes, saving a draft of your changes, and scheduling your changes for later, and it makes it really hard to justify making updates to what is, frankly, the subpar experience of the separate widgets screen. It also is very jarring to visit the customizer after having added blocks to widget areas because of the way blocks are displayed and handled in that context, and users should be able to flow between whatever works for them freely, not be forced into one or the other without benefit to them.

So, when we come back to this again, let's keep sight of what it means to keep users feeling secure that they can get their site looking the way they want with WordPress, and not like they are having to work around what we've given them.

#16 @paaljoachim
9 days ago

I believe what is being said above here is that the new widget screen will not take over the existing core widget screen in 5.6, but be punted to early 5.7.

I breath a sigh of relief, because the new widget screen needs a lot more testing out in the wild before it becomes the new default widget screen in core. We need to get it working properly with the user interface, user flow and functions testing it in the Gutenberg plugin. It also needs to fully work with the customizer (and also Full Site Editing) before a totally new experience of using widgets can be incorporated into core. As beta 1 is today I was a bit worried that a not fully tested and functioning feature was on its way into core. I am glad to hear that we are holding off on including the new widget screen. In the mean time we still need to get it working for people who use the Gutenberg plugin.

In relation with helping the user feel secure....
We need to make sure that a user can easily switch between a new (experimental) screen that has become default using the Gutenberg plugin to the old widget screen. As in having an easy way to switch between new <-> old screen. Atleast for a while while testing is going on. (Something to remember for the Navigation screen when that becomes the new default nav screen in the Gutenberg plugin.) I believe at present stage we were forcing the user who does not have a correct functioning widget screen to add code to the functions file to get the old widget screen back. Many users feel uncomfortable adding code to the functions file. One can perhaps force the user to do so when a widget screen is ready and bugs have been fixed, but not when it in a sense is still in a testing phase. It makes the user feel worried about using the Gutenberg plugin when an experimental feature has become default when it really should have been experimental a while longer.

Thank you for holding off on incorporating the new widget screen and punting it into 5.7. It feels like the correct move to make.

Last edited 9 days ago by paaljoachim (previous) (diff)

#17 @azaozz
9 days ago

Frankly I'm sad to see this pushed to the next release. Still, must agree with @helen:

...widget area blocks do not allow you to try this new feature without penalizing you for experimenting.

Just not sure "penalizing" is the right word here. It's true, we, as users, want *everything* to be WYSIWYG as much as possible. The Customizer's "instant preview" kind of helps, but still feels quirky and hacky (and is far from being WYSIWYG). However agree that every "Save" would need to have an "Undo", no matter what.

The good part of this is that now widgets can continue to be "re-imagined" for 5.7, and get even more enhancements. Not sure how many people have tested this for a bit longer but having blocks in the widgets areas (a.k.a. sidebars) opens up many new possibilities and makes a lot of the old, limited widgets obsolete. The "widget areas" become something like "specialized posts with more dynamic content", letting users (and designers) do a lot of stuff that was either hard or impossible with the old widgets.

Last edited 9 days ago by azaozz (previous) (diff)

This ticket was mentioned in Slack in #core-editor by annezazu. View the logs.


8 days ago

This ticket was mentioned in Slack in #core by annezazu. View the logs.


8 days ago

#20 @prbot
3 days ago

adamziel commented on PR #603:

@noisysocks it means this page _is a full-screen block editor_ - potentially specific to post/page. It does not mean _this page has any block editor somewhere on it_. the entire reason for this change: https://core.trac.wordpress.org/ticket/51330

#21 @prbot
3 days ago

noisysocks commented on PR #603:

@noisysocks it means _this page is a full-screen block editor_ - potentially specific to post/page. It does not mean _this page has any block editor somewhere on it_. the entire reason for this change: https://core.trac.wordpress.org/ticket/51330

Got it. We'll need to take a different approach in https://github.com/WordPress/gutenberg/pull/26263, then. cc. @talldan

Note: See TracTickets for help on using tickets.