Add new block widgets editor

[isabel_brison]

Add the edit-widgets package and the necessary changes to display the block widgets editor by default in both the stand alone admin screen and in the customizer.

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

[TimothyBlynJacobs]

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

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

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.

2. 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.

3. 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.

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.

[azaozz]

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.

[noisysocks]

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.

[noisysocks]

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

@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

@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.

[noisysocks]

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.

[helen]

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.

[paaljoachim]

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 into 5.6!
Punting it into an early 5.7 phase feels like the correct move.

[azaozz]

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.

@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

@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

@noisysocks @adamziel What does 'full-screen' mean in this context? The class seems to have been added in WordPress 5.0 quite a long time before the post editor was full screen by default (https://core.trac.wordpress.org/changeset/44133, https://core.trac.wordpress.org/ticket/45037), so it seems like it should be perfectly fine to have a non-fullscreen block editor but still have is_block_editor() return true. Core also doesn't have any styles related to is-fullscren-mode, it's all handled by the interface package.

I just want to question the assumptions here since I don't see why the widgets screen would have is_block_editor() return false when it _is_ a block editor.

I think what we can all agree on is that it definitely seems like this one boolean has way too much responsibility, and it should probably be made more granular along the lines of https://core.trac.wordpress.org/ticket/51330. Full screen should also not be implicit to is_block_editor() == true IMO.

However, as part of that, I think we should try to make is_block_editor() return the right thing, or deprecate it entirely.

What does 'full-screen' mean in this context?

The is-fullscreen CSS class, not sure if anything else. I remember setting is_block_editor true caused JS errors in the widgets editor for me a few months back, but I am unable to reproduce this behavior now so maybe we're good. I just went through all the usages of is_block_editor() and it doesn't seem like there is much more to it after all...?

I just want to question the assumptions here since I don't see why the widgets screen would have is_block_editor() return false when it is a block editor.

@talldan you hit the nail on the head. I'm all for marking the widgets editor as a block_editor in some way as you @talldan mentioned. Saying it's not an editor when it is one is counter-intuitive. Maybe the implicit fullscreen mode is the only blocker for that - how about another boolean parameter to control just this aspect of displaying? e.g. is_full_screen_editor() that defaults to true

[hellofromTonya]

As widgets in core is not targeted for 5.7 but is within the GB plugin, should this ticket to be punted to Future Release with a target of 5.8? cc @noisysocks

[hellofromTonya]

Moving to 5.8 as widgets in core are targeted for 5.8, not 5.7.

[andraganescu]

The new, and improved, block based WIdgets Editor is back. There is a new call for testing here: ​https://make.wordpress.org/core/2021/05/12/help-test-the-widgets-editor-for-wordpress-5-8/

The aim of the call for testing is to see if there are any blockers abour the new Widgets editor before 5.8's feature freeze.

The major news are:

• the Customizer's widgets panel is updated and alows editing blocks and widgets at the same time
• adding blocks to widget areas in the Customizer works with all the features present: previewing, scheduling, sharing
• the block based Widgets editor (both the stand alone and the Customizer panel) have very good back compat

Thanks for testing! Looking forward to feedback :)

🚧 WIP 🚧

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

Includes ​https://github.com/WordPress/wordpress-develop/pull/1118.

[noisysocks]

Working on this now in ​https://github.com/WordPress/wordpress-develop/pull/1284.

Not sure why tests on PHP 8 are hanging. It seems to be happening on all branches. I verified locally that tests pass using PHP 8.

[noisysocks]

In 50996:

Adds the widgets block editor to widgets.php and customize.php

Moves the widgets block editor from Gutenberg into WordPress Core.

• Adds @wordpress/edit-widgets, @wordpress/customize-widgets and @wordpress/widgets.
• Modifies wp-admin/widgets.php to branch between the old editor and new editor depending on wp_use_widgets_block_editor().
• Modifies WP_Customize_Widgets to branch between the old editor control and new editor control depending on wp_use_widgets_block_editor().

Fixes #51506.
Props isabel_brison, TimothyBlynJacobs, andraganescu, kevin940726, talldanwp.

[noisysocks]

In 50997:

Adds the widgets block editor to widgets.php and customize.php

Moves the widgets block editor from Gutenberg into WordPress Core.

• Adds @wordpress/edit-widgets, @wordpress/customize-widgets and @wordpress/widgets.
• Modifies wp-admin/widgets.php to branch between the old editor and new editor depending on wp_use_widgets_block_editor().
• Modifies WP_Customize_Widgets to branch between the old editor control and new editor control depending on wp_use_widgets_block_editor().

Follows [50996] which was missing these files.
See #51506.
Props isabel_brison, TimothyBlynJacobs, andraganescu, kevin940726, talldanwp.

[peterwilsoncc]

In 51028:

Widgets: Ignore CSS files in legacy widgets block.

Add SVN ignore property to match existing rule in .gitignore.

Follow up to [50997].
See #51506.

[noisysocks]

In 51037:

Widgets: Remove unnecessary enqueue of 'format-library' assets

It is not necessary to enqueue 'format-library' assets here as this is done when
triggering the 'enqueue_block_editor_assets' action.

Follows [51028].
See #51506.
Props isabel_brison.

[noisysocks]

In 51038:

Widgets: Perform 'widgets_admin_page' action in block widget editor

Perform the 'widgets_admin_page' action just prior to outputting markup for the
widgets block editor so as to maximise backwards compatibility with the old
screen.

Follows [51037].
See #51506.
Props isabel_brison.

[SergeyBiryukov]

In 51039:

Docs: Use a duplicate hook reference for widgets_admin_page in wp-admin/widgets-form-blocks.php.

Follow-up to [51038].

See #51506.

[SergeyBiryukov]

In 52297:

Docs: Use a duplicate hook reference for theme_file_path in WP_Theme::get_file_path().

Follow-up to [38578], [52279].

See #51506, #53399.