Template Parts: Add an option to import widgets from the sidebars #45509
Conversation
|
|
Mamaduka
requested review from
mtias,
jasmussen,
jameskoster,
noisysocks and
kevin940726
and removed request for
spacedmonkey and
ajitbohra
Mamaduka
added
[Type] Enhancement
|
Size Change: +886 B (0%) Total Size: 1.32 MB
ℹ️ View Unchanged
|
|
Nice one. How can I best help or provide feedback? Thanks for including a video. It sounds like you don't have to do the widget importing before switching to a new block theme, is that right? The term "Import" makes it sound one-way. But what if I sneakily rememberd the URL of the widget editor, and added new blocks there, would they appear in the template part mapped to the area? Not suggesting this is a good flow, just wondering if we can learn anything from the navigation block here, in terms of how it handles classic menus and importing. I.e. is there a way for the entire "import" panel to disappear once you've imported all widget areas? |
|
Thanks for working on this. My first thought is that the import functionality seems a bit too prominent, but I don't have a better suggestion right now. The UI could do with some help text to explain what is going on. "Select sidebar" may not be the best language – not all widget areas are sidebars.
I think it probably should be one-way? Syncing a template part with a widget area sounds like a potential can of worms :D I agree, it would probably be best for the import UI to disappear after a successful import. Adding the Needs Design label as I think this needs a little more exploration to get the UX right. |
|
@jasmussen, any feedback is more than welcome. For example, does the panel design look okay?
That's correct. No action is required before switching themes.
Yes, the import is one-directional. As a result, the template part won't be in sync with the imported sidebar. But if you add more widgets to the sidebar, the following import will contain those widgets.
I also put a similar item on the PR's to-do list. I think the option should be only visible for the blank template part.
@jameskoster, you're right! I was just using REST API terminology here. |
That was my initial thought as well. The 'import' UI might be better placed in the placeholder:
|
If I remember correctly, Navigation's "Import classic menu" changed places from Placeholder -> Block Toolbar -> Inspector Controls (as part of the general menu dropdown). I'm not against the idea, but we should probably see if the same placement logic applies here as well. |
I think there are some dots we can connect here! The thing is: if you have unimported widgets, it seems okay that the UI is very prominent. Especially if we can hide it entirely once you've imported widgets. I imagine there's a challenge there: do we delete widgets once they are imported as blocks? Or do we leave them, and what then happens if you add a new widget to an area: does the importer appear again? And if it does, does it then import only new widgets, or all widgets once again? Of course we'll want to lean towards the simplest solution in all of this. But it would be nice if we could hide the import control upon successful import. |
Only for empty template parts though, right? I don't think we should surface the import interface this prominently when you've selected an existing template part.
I don't think it needs to be so complex. The 'import' should merely be a shortcut to pull blocks from a widget area into an empty template part. The two things remain entirely disconnected. If we wanted to keep them connected (not my preference) then I would consider an entirely different approach: surface widget areas in the Inserter as template part variations. No 'importing'. |
Do you not think it may be common to want to import widget areas to footer template parts which already has blocks? Like updating a default footer instead of needing to create a new. |
|
Yes that's a fair point. It should probably be possible to repeat the process somehow. Though in that particular use case I would question whether the imported widget areas need to be template parts in their own right, considering they're being placed inside one? The current implementation still feels way too prominent to me though, given how infrequent this task will be performed in the grand scheme of things. It's generally going to be a one-time thing per widget area, and as above it's not even guaranteed that the imported widget areas need to remain synchronised. That really depends on things like how the classic theme was set up, and what kind of widget area you're migrating. A different approach entirely – as @Mamaduka suggests – would be to do something like the Navigation block, whereby you insert a "Widget Area" block (which is possible only if widget areas already exist), and via the Inspector select which area you want to display:
It makes some sense conceptually seeing as both blocks are offering a migratory path from legacy functionality. The unique thing with widget areas is that they really make no sense unless some already exist at the site. In the world of full-block themes their functionality replaced entirely by the Template Part paradigm, and crossing those streams feels a bit troublesome to me. |
|
Using widget areas was initially suggested by @noisysocks as one of the options (#39270 (comment)). I personally like the idea of importing the blocks and forgetting about sidebars/widget areas 😄 |
On balance that is my preference as well. Let's explore the design a bit more. |
|
Here's a potential design: tp.mp4When widget areas exist, The Template Part placeholder provides an option to migrate them into the new template part. The description outlines that a new template part will be created when you migrate which hopefully clarifies the unidirectional nature of the action. To satisfy the flow @carolinan mentioned above you'd simply repeat the process: Insert a Template Part block, and select the widget area you want to migrate. I think this seems reasonable, but keen to hear thoughts! |
Ah, damn, yeah that's a really good point.
It won't work, no. |
There was a problem hiding this comment.
Let's get this in for now.
I don't love that we're duplicating the transformWidgetToBlock code and that we're always registering Legacy Widget even though it's hidden and/or won't function properly. But this seems to be the most practical approach for now and the changes are minimal meaning they don't preclude us from changing the approach in the future.
Thanks for your patience while we've worked through the details of this and explored different ideas 😅 And nice work!!
|
Thanks for testing and reviews, @noisysocks! |
…5509) * Template Part: Introduce an option to import widgets * Only display active sidebars with widgets as options * Use the sidebar name as the new template part title * Support legacy widgets * Prefix imported template parts to avoid name collision * Add missing docblock * Update labels * Move settings into the advanced inspector controls panel * Update API response for sidebars and mark them as 'inactive' * A minor design adjustments * Fix the rendering order bug * Transform legacy widgets before importing * Avoid hardcoding names of the blocks with wildcard transformations * Skip 'wp_inactive_widgets' widget area * Use 'HStack' * Allow overriding Legacy Widget block settings during registration * Override only supports settings * Improve spacing * Add the legacy widget to the post editor Co-authored-by: Robert Anderson <robert@noisysocks.com>
|
Had a problem with first try (even with fresh WP install) and Gutenberg 14.9 and 14.9.1 |
|
Thanks for contributing, @burnuser! Do you mind creating a new issue with reproduction steps? |
When switching to a block theme, classic sidebars were orphaned and their widgets remapping to the `'wp_inactive_widgets'` sidebar . This changeset preserves the sidebars and their widgets, providing a migration path to a block theme without losing the widgets. Classic sidebars are now: * Stored in a new theme mod called `'wp_classic_sidebars'`; * Restored to the `$wp_registered_sidebars` global variable when the `'widgets_init'` action fires (via a new internal function called `_wp_block_theme_register_classic_sidebars()`); * And marked as `'inactive'` when interacting with sidebars REST API endpoint. References: * [WordPress/gutenberg#45509 Gutenberg PR 45509] which adds an option for importing widgets from sidebars into template parts. Follow-up to [50995], [6334]. Props mamaduka, audrasjb, hellofromTonya, ironprogrammer, jameskoster, joen, matveb, mukesh27, noisysocks, poena, youknowriad. Fixes #57531. git-svn-id: https://develop.svn.wordpress.org/trunk@55200 602fd350-edb4-49c9-b593-d223f7449a82
When switching to a block theme, classic sidebars were orphaned and their widgets remapping to the `'wp_inactive_widgets'` sidebar . This changeset preserves the sidebars and their widgets, providing a migration path to a block theme without losing the widgets. Classic sidebars are now: * Stored in a new theme mod called `'wp_classic_sidebars'`; * Restored to the `$wp_registered_sidebars` global variable when the `'widgets_init'` action fires (via a new internal function called `_wp_block_theme_register_classic_sidebars()`); * And marked as `'inactive'` when interacting with sidebars REST API endpoint. References: * [WordPress/gutenberg#45509 Gutenberg PR 45509] which adds an option for importing widgets from sidebars into template parts. Follow-up to [50995], [6334]. Props mamaduka, audrasjb, hellofromTonya, ironprogrammer, jameskoster, joen, matveb, mukesh27, noisysocks, poena, youknowriad. Fixes #57531. Built from https://develop.svn.wordpress.org/trunk@55200 git-svn-id: http://core.svn.wordpress.org/trunk@54733 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When switching to a block theme, classic sidebars were orphaned and their widgets remapping to the `'wp_inactive_widgets'` sidebar . This changeset preserves the sidebars and their widgets, providing a migration path to a block theme without losing the widgets. Classic sidebars are now: * Stored in a new theme mod called `'wp_classic_sidebars'`; * Restored to the `$wp_registered_sidebars` global variable when the `'widgets_init'` action fires (via a new internal function called `_wp_block_theme_register_classic_sidebars()`); * And marked as `'inactive'` when interacting with sidebars REST API endpoint. References: * [WordPress/gutenberg#45509 Gutenberg PR 45509] which adds an option for importing widgets from sidebars into template parts. Follow-up to [50995], [6334]. Props mamaduka, audrasjb, hellofromTonya, ironprogrammer, jameskoster, joen, matveb, mukesh27, noisysocks, poena, youknowriad. Fixes #57531. Built from https://develop.svn.wordpress.org/trunk@55200 git-svn-id: https://core.svn.wordpress.org/trunk@54733 1a063a9b-81f0-0310-95a4-ce76da25c4cd
bph
added
the
Needs Dev Note
When switching to a block theme, classic sidebars were orphaned and their widgets remapping to the `'wp_inactive_widgets'` sidebar . This changeset preserves the sidebars and their widgets, providing a migration path to a block theme without losing the widgets. Classic sidebars are now: * Stored in a new theme mod called `'wp_classic_sidebars'`; * Restored to the `$wp_registered_sidebars` global variable when the `'widgets_init'` action fires (via a new internal function called `_wp_block_theme_register_classic_sidebars()`); * And marked as `'inactive'` when interacting with sidebars REST API endpoint. References: * [WordPress/gutenberg#45509 Gutenberg PR 45509] which adds an option for importing widgets from sidebars into template parts. Follow-up to [50995], [6334]. Props mamaduka, audrasjb, hellofromTonya, ironprogrammer, jameskoster, joen, matveb, mukesh27, noisysocks, poena, youknowriad. Fixes #57531. Built from https://develop.svn.wordpress.org/trunk@55200 git-svn-id: http://core.svn.wordpress.org/trunk@54733 1a063a9b-81f0-0310-95a4-ce76da25c4cd
What?
Resolves #39270.
PR introduces a new option to import sidebar widgets into a template part.
Note: This feature is only available for the block inspector and cannot be used in the template part focus mode. There it should be a part of the Template Inspector tab. I think we can do this separately as part of #36951.
Why?
See #39270.
How?
The previous sidebars are stored as a "theme mod" when a user switches to a block theme. The block theme will register fake sidebars and let WordPress do all the remapping for us. See WP-17979.
The new block inspector panel fetches these sidebars and displays them as import options. The sidebars with
inactivestatus or without the widgets aren't displayed.I've adapted the transformation method from the widget editor and had to add the
@wordpress/widgetspackage as a site editor dependency to handle legacy widgets.Todos
Support all theme variations that can use Template Parts.Does this feature make sense outside of the site editor?Testing Instructions
Repeat the same steps with Classic Widget enabled.
Screenshots or screencast
CleanShot.2022-11-03.at.12.34.49.mp4