WordPress.org

Make WordPress Core

Opened 7 months ago

Last modified 18 hours ago

#39693 assigned enhancement

Fix missing assignment of widgets on theme switch

Reported by: melchoyce Owned by:
Milestone: 4.9 Priority: normal
Severity: normal Version:
Component: Widgets Keywords: has-patch needs-testing has-unit-tests
Focuses: Cc:

Description (last modified by westonruter)

Switching themes will cause widgets to be "lost" in theme switch. See this post for examples.

Related: #19912, which focuses on one specific solution — I'd like to see us step back from that and think about other ways to approach this problem.

Related: #39692, for the same problem with nav menus.

Related: #27404, Widget Customizer: Allow adding inactive widgets to widget areas

Attachments (7)

customizer-widget-presets-i2.png (245.8 KB) - added by folletto 6 months ago.
Customizer widgets "Presets" area i2
quantity-of-themes-having-sidebar-counts.png (65.1 KB) - added by westonruter 6 months ago.
39693-tests.diff (7.6 KB) - added by obenland 3 days ago.
39693.diff (16.8 KB) - added by obenland 42 hours ago.
39693.2.diff (18.4 KB) - added by obenland 39 hours ago.
39693-tests.2.diff (9.7 KB) - added by obenland 35 hours ago.
Updated tests for original retrieve_widgets().
39693.3.diff (17.4 KB) - added by obenland 19 hours ago.

Download all attachments as: .zip

Change History (80)

#1 @melchoyce
7 months ago

Also related: #39692

#2 follow-up: @westonruter
7 months ago

  • Description modified (diff)
  • Milestone changed from Awaiting Review to 4.8

If we don't use the concept of a widget group (#19912), what's an alternative to what core currently does in trying to guess a sidebar to re-assign the widgets to? Add a user step to ask where they'd like widgets (and nav menus) to appear as an interstitial when doing a theme switch? That doesn't seem ideal either.

#3 follow-up: @SergeyBiryukov
7 months ago

Switching themes will cause widgets to be "lost" in theme switch.

This was previously fixed in #17979 for 3.3, sounds like there was a regression somewhere.

#4 in reply to: ↑ 2 @melchoyce
7 months ago

Replying to westonruter:

If we don't use the concept of a widget group (#19912), what's an alternative to what core currently does in trying to guess a sidebar to re-assign the widgets to? Add a user step to ask where they'd like widgets (and nav menus) to appear as an interstitial when doing a theme switch? That doesn't seem ideal either.

Some ideas:

  1. Throw all the widgets into whatever widget area there is without asking (and additionally make some design enhancements to make switching widget area easier)
  2. Look for similar widget area IDs/names to map to

It would also help to introduce the inactive widgets area into the Customizer.

#5 in reply to: ↑ 3 @melchoyce
7 months ago

Replying to SergeyBiryukov:

Switching themes will cause widgets to be "lost" in theme switch.

This was previously fixed in #17979 for 3.3, sounds like there was a regression somewhere.

If you go from many widget areas down to one widget area, you still "lose" widgets (in that they're set inactive, which, if you're working in the Customizer, doesn't exist). This ticket probably needs a better description.

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.


7 months ago

#7 @westonruter
7 months ago

  • Description modified (diff)

To be worked on in conjunction with #27404.

#8 @celloexpressions
6 months ago

It seems like #19912 is still the best long term approach here. Wherever possible, widget and menu assignment should be automatic when switching themes. However, providing user control over menus/widget groups that can be assigned to locations is the only clean way to allow users to quickly restore their desired configurations when automatic assignment fails. The UX of menu locations could certainly use improvement, but unifying widgets with menus is a good first step.

This ticket would be a good place to explore additional ways to automate widget assignments, both with and without the concept of widget groups. The widget groups concept is very powerful in that it will facilitate separating the majority of widget information from specific instances on specific themes - like with menus, actual widgets could be more logically stored in posts with only the widget group being stored in a theme-specific option (theme_mod). In situations where a site may switch between different themes seasonally or for other reasons (even, say, going back and forth with child themes), changes made to a widget in one theme don't sync with similar widget instances in other themes currently.

#9 follow-up: @folletto
6 months ago

It seems like #19912 is still the best long term approach here.

I back @westonruter's comment as that ticket being more about the technical consolidation as separate from the UI, as menu locations is one of the most confusing interface concepts ever. I tried to explore alternatives on .com, but it didn't work very well. Unless we have a solid solution, I wouldn't introduce UI for it.

Regardless, I agree with you:

This ticket would be a good place to explore additional ways to automate widget assignments, both with and without the concept of widget groups.

As re-assignment is a big win regardless of the decision on the other ticket, I think groups could play into this as a way to achieve solid switching.

I'd use a logic similar as Mel outlined in #39692:

If your old theme only has one menu and your new theme only has one menu, just map them automatically
If your old theme and new theme share a similar IDs or names, map them automatically
If your old theme has more than one menu, or your new theme has more than one menu, map the menu in the first menu location in your old theme to the first menu location in the new theme.

Another way to say it: always associate the maximum number of existing items to the most likely location.
Since here we deal with individual widget and not menus, it's probably going to be trickier.

The extra considerations I'll do for both are:

  1. We need to make sure that when a user switches back to a previous theme the items relocate to exactly the same location. I'm not sure how this can be done, but it's very important as it's expected.
  2. In case of a switch to a theme with less locations, there should be a good default so ideally the user has as little as possible extra work to do.
  3. Previous widget configurations should be able to be retained in a way to be explored.

We need to explore how to make "dropped" widgets accessible to not make people lose the configuration they made.

One idea: as a different theme might have different areas, an idea would be to introduce a section inside the "Add widget" panel that lists previous configurations. In that way one can "Add" a pre-configured widget (or delete that pre-configuration), without introducing an additional concept of "an inactive widget area".

Incidentally providing an API to pre-configured widget could be a feature for multi-site installation too where there are some pre-configured templates provided at network level. But this escalates complexity, I'm throwing it in just as a potential vision.

#10 in reply to: ↑ 9 @melchoyce
6 months ago

Replying to folletto:

The extra considerations I'll do for both are:

  1. We need to make sure that when a user switches back to a previous theme the items relocate to exactly the same location. I'm not sure how this can be done, but it's very important as it's expected.
  2. In case of a switch to a theme with less locations, there should be a good default so ideally the user has as little as possible extra work to do.
  3. Previous widget configurations should be able to be retained in a way to be explored.

Agreed 👍

We need to explore how to make "dropped" widgets accessible to not make people lose the configuration they made.

One idea: as a different theme might have different areas, an idea would be to introduce a section inside the "Add widget" panel that lists previous configurations. In that way one can "Add" a pre-configured widget (or delete that pre-configuration), without introducing an additional concept of "an inactive widget area".

Any time or interest in exploring a design for this?

#11 @westonruter
6 months ago

  • Owner set to jonathanbardo
  • Status changed from new to assigned

#12 @westonruter
6 months ago

Comment on #27404 (Widget Customizer: Allow adding inactive widgets to widget areas):

I'm going to suggest that widgets most commonly get moved to inactive widget area as the result of a theme switch (#39693). It would be very useful if widgets that were made inactive as part of a theme switch could be grouped in a way to easily batch-add them to a sidebar in the new theme. By grouping them I don't mean widget persistent groups (#19912), but rather transient groupings that essentially are pulling the grouping of widgets from another theme's widget-sidebar assignments. Being able to easily and intuitively re-assign widgets from the previous theme's sidebars to the new theme's sidebars, maintaining their ordering, would be a huge.

If the old theme has 3 sidebars whereas the new theme as 2 sidebars, note that this could mean that 2 groupings of inactive widgets could be added to one sidebar on the new theme. Two additional questions then come to mind: should the best-guess re-assignment of widgets from the old sidebar's theme to a sidebar in the new theme be eliminated unless the sidebar IDs are exact matches (e.g. sidebar-1)? If not, then it is likely that a re-assignment of widgets in the new theme will be wrong and need to be re-assigned. In that case, there should have to be a way to bulk move all widgets from one sidebar to another.

It may be that this theme-switch grouping is out of scope for this ticket and should instead be addressed as part of #39693.

@folletto
6 months ago

Customizer widgets "Presets" area i2

#13 @folletto
6 months ago

Ok I uploaded a concept on how we could show the "inactive" widgets in a way that is fairly seamless. The goal here is exclusively to provide access to widgets that were dropped during a theme switch (or any other reason) with the additional restriction of having minimal impact.

Features of the "Presets" i2 concept:

  1. Inactive widgets have a special separated area in the "Add a widget" panel.
  2. They are searchable as the other widgets, content included if possible
  3. They can be removed, and the removal has an extra trick here: one can position the mouse in the top-right X and keep clicking, removing all the inactive widgets easily in sequence (we probably need a form of undo for the ideal experience).
  4. The second line of the widget instead of showing the details shows when they were removed, thus giving a simple indication of how old a widget is.
  5. I avoided subtitle labels for the sections, but we can introduce them if we want. The current state might still work well enough.

That's all. It's an approach "low key" enough to be effective, but at the same time very visible as it's inside the main "Add" flow: a user that "lost" a widget will get there, even just because they have to re-add them.

#14 @lukecavanagh
6 months ago

@folletto

How would this look in WP Admin?

#15 @folletto
6 months ago

I wasn't considering any change to the wp-admin interface as it already shows an "Inactive widgets" area. Maybe I'm missing something? :)

#16 @melchoyce
6 months ago

My only concern is, does it become unwieldy if you had a bunch of widgets? But I think we can figure that out via testing, and with better widget switching in #39693, that might not even be a big issue. Let's try it.

Worth including what theme you were using it with, or nah?

Edit: this is #39693. 😑 For some reason I thought we were in #27404. Want to move the mockup over to that ticket, @folletto?

Last edited 6 months ago by melchoyce (previous) (diff)

#17 @folletto
6 months ago

I didn't know there was a more specific ticket. So this is just about the re-assignment logic the other instead is about what happens when the reassignment logic can't find a spot? Ok.

Cross posted there.

#18 @melchoyce
6 months ago

  • Owner jonathanbardo deleted

#19 @edge22
6 months ago

#40009 was marked as a duplicate.

#20 @melchoyce
6 months ago

If your old theme and new theme share a similar IDs or names, map them automatically

@ipstenu grabbed some data for us from the theme directory. Logs here.

Most common widget area names seem to be:

  1. Sidebar (with Sidebar1, Sidebar2, etc being right down the line)
  2. Main (with a Main Sidebar being a very popular second)
  3. [Left|Right] Sidebar

Bottom, footer, header, and custom were clustered together in the list of widget areas. Many more are "Footer [something]."

Surprisingly, the data seemed to indicate that Left Sidebar was more common than Right Sidebar. I don't know if we should map Left to Sidebar, etc., and Right with Sidebar2, based on that, or go with my gut and do Sidebar --> Right, Sidebar 2 --> Left. Let's try the latter option and then test a bunch of themes.

I think, using this info and some research of my own, we could assume:

  • Sidebar, Sidebar 1, Main, Main Sidebar, Primary, Primary Sidebar, Right Sidebar, and First can all be mapped to each other
  • Sidebar 2, Left Sidebar, and Second can be mapped to each other
  • Footer and Bottom can be mapped to each other
  • Header and Top can be mapped to each other

And if always, if there's an exact match, it should map to that widget area. Or, if your old theme only has one widget area and your new theme only has one widget area, just map them automatically.

#21 @westonruter
6 months ago

Given the data gathered from themes, perhaps we can use this as an opportunity to codify recommendations in the theme handbook for how sidebars should be named? If a theme author knows that the way they name their sidebars is important, they can re-use the sidebar ids that are recognized in core for mapping and easy the switching into their theme.

#22 @westonruter
6 months ago

A very helpful way for hosts to provide support on this issue would be to share some statistics on the widget sidebars for the sites the host. WordPress stores the widget configurations for the sidebars in a PHP-serialized sidebars_widgets option in the DB that looks like:

<?php
array(
    'sidebar-1' => array(
        'search-2',
        'meta-2',
    ),
    'sidebar-2' => array(
        'archives-5',
        'calendar-10',
    ),
    'wp_inactive_widgets' => array(
        'text-3',
        'recent-comments-3',
    )
)

A host could run a script that iterates over each WP site, grabs out the sidebars_widgets option, and then collect stats on:

  1. Logs the sidebar IDs for the site (the array keys)
  2. Counts the number of widgets in each sidebar (the count for each nested array).

Then given that a script has done:

<?php
$sidebars_widgets = get_option( 'sidebars_widgets', array() );
if ( empty( $sidebars_widgets['array_version'] ) || 3 !== $sidebars_widgets['array_version'] ) {
    return;
}
unset( $sidebars_widgets['array_version'] );

Then, if we can get stats on:

  1. The most commonly used sidebar IDs (array_keys( $sidebars_widgets ))
  2. The number of sidebars registered (count( $sidebars_widgets ))
  3. Counts the number of widgets in each sidebar (array_map( 'count', $sidebars_widgets ) )) and perhaps a sum of them (call_user_func_array( 'array_sum', array_map( 'count', $sidebars_widgets ) ) )).

The wp_inactive_widgets sidebar is also a special case which will help with designing #27404.

This ticket was mentioned in Slack in #meta by westonruter. View the logs.


6 months ago

#24 @Ipstenu
6 months ago

Oh I see why you asked me about DH.

A host could run a script that iterates over each WP site, grabs out the sidebars_widgets option, and then collect stats on:

Sure we could. But that runs into some SERIOUS privacy concerns, and my knee-jerk reaction is "I am absolutely not giving you customer data like that."

To explain why the search from the theme slurper is kind of junk, it's basically that people format code in different ways.

Example:

themes/aaron/functions.php:46:          register_nav_menus( array(
themes/abacus/functions.php:77:         register_nav_menu( 'top', __( 'Top Menu', 'abacus' ) );

And if I hop into the aaron theme:

                register_nav_menus( array(
                        'header' => __( 'Primary Menu', 'aaron' ),
                        'social' => __( 'Social Menu', 'aaron' ),
                ) );

Scanning for both of those can be a bit tricky. Getting all that data and outputting it into something useful and readable is doubly so.

Two options for you to download and search for it yourself though:

https://github.com/aaronjorbin/WordPress-Theme-Directory-Slurper
https://github.com/Ipstenu/WordPress-Theme-Directory-Slurper

Mine's a fork of the current plugin slurper.

#25 @fjarrett
6 months ago

@Ipstenu Correct me if I'm misreading what @westonruter is asking for, but such stats would be delivered in aggregate and not personally-identifiable. I think it's important for hosts to try to provide anonymous/aggregated trend data back to the community when they can, similar to https://www.godaddy.com/garage/wordpress-hot-100/

#26 follow-up: @Ipstenu
6 months ago

Listing what plugins are installed is somewhat of a different order of magnitude. And while I laud GoDaddy for doing that, I personally find it right on the edge of things where I'm violating privileged information. Like disclosing how many users, on average, people have on a site is different. @mikeschroder may have a different opinion of course, but like I said, I'd have to ask and my (PERSONAL) knee-jerk reaction is "No."

If all you care about is the themes hosted on .org, then someone can grab the slurper and figure out a better search than I did. The data is right there for y'all to search and you don't need me for that. I happened to have some of it handy when Mel asked is all.

#27 in reply to: ↑ 26 @westonruter
6 months ago

Replying to Ipstenu:

If all you care about is the themes hosted on .org, then someone can grab the slurper and figure out a better search than I did. The data is right there for y'all to search and you don't need me for that. I happened to have some of it handy when Mel asked is all.

Thanks, I'll try to figure out something to grab the sidebar IDs. And thanks for doing that initial getting the initial rundown of the sidebar Names. That gave us the initial direction we needed.

#28 @westonruter
6 months ago

I've forked the slurper and have written a parser for obtaining the sidebar args for the themes: https://github.com/xwp/WordPress-Theme-Directory-Slurper/tree/master/feature-stats/registered-widget-sidebars

Here are stats from the parsing : https://docs.google.com/spreadsheets/d/1sjm95-P7ocEL1m1TlAToL83TLNEijo9RKyBmERMA5hs/edit#gid=0

The most common number of sidebars is 1. Half as common is to have 2, with a little bit less common to have 0 sidebars. Here are the top 10 sidebar counts:

Sidebar Count Theme Quantity
1 1308
2 748
0 612
4 444
5 377
3 365
6 236
7 129
8 90

Plotted:


As for the most popular sidebar IDs used, here are the top ~30:

Sidebar ID Count
sidebar-1 2234
sidebar-2 810
sidebar-3 416
sidebar-4 299
sidebar 234
footer-1 233
footer-2 224
footer-3 218
sidebar-5 203
primary-widget-area 162
footer-4 134
first-footer-widget-area 132
second-footer-widget-area 131
third-footer-widget-area 124
sidebar-6 120
fourth-footer-widget-area 97
secondary-widget-area 96
right-sidebar 80
sidebar-widget-area 76
footer 70
footer-widget-area 70
primary-sidebar 69
sidebar-left 68
footer-right 66
footer-left 65
sidebar-right 60
sidebar-7 56
footer-sidebar 52
primary 51

There is a degree of normalization that can be done for these, such as replacing “fourth” with 4, removing hyphens, removing “sidebar” and “widget area” and so on.

Last edited 5 months ago by westonruter (previous) (diff)

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.


6 months ago

#30 @westonruter
6 months ago

The function that will be the focus of the work here is retrieve_widgets(): https://developer.wordpress.org/reference/functions/retrieve_widgets/

#31 follow-up: @alexvorn2
5 months ago

My idea is to store widgets settings into theme_mod_[theme_name] option, see my ticket: https://core.trac.wordpress.org/ticket/40067

#32 in reply to: ↑ 31 ; follow-up: @westonruter
5 months ago

Replying to alexvorn2:

My idea is to store widgets settings into theme_mod_[theme_name] option, see my ticket: https://core.trac.wordpress.org/ticket/40067

Beyond what I commented on that ticket, I don't see how this will help the situation. It seems like your proposing creating theme-specific sets of widgets, where each theme has its own parallel universe of widgets. The problem were are trying to solve here is how to teleport widgets between the theme multiverse, not introduce the need to maintain a multiverse of widget doppelgangers. 😉

#33 in reply to: ↑ 32 ; follow-up: @alexvorn2
5 months ago

Replying to westonruter:

Beyond what I commented on that ticket, I don't see how this will help the situation. It seems like your proposing creating theme-specific sets of widgets, where each theme has its own parallel universe of widgets. The problem were are trying to solve here is how to teleport widgets between the theme multiverse, not introduce the need to maintain a multiverse of widget doppelgangers.

If you look in the recent default theme: "Twenty Seventeen" you can find out that this theme have theme-specific sets of widgets settings, so this is not something new, you can check by yourself when you make a theme preview of this theme... a you find that some widgets are loaded with text in the specific sidebars.

I, of course like this idea and I am looking further in this direction as it need a lot of improvements.

#34 in reply to: ↑ 33 @westonruter
5 months ago

Replying to alexvorn2:

If you look in the recent default theme: "Twenty Seventeen" you can find out that this theme have theme-specific sets of widgets settings, so this is not something new, you can check by yourself when you make a theme preview of this theme... a you find that some widgets are loaded with text in the specific sidebars.

These starter content widgets are only applied to Twenty Seventeen in the case of a site being fresh, without any content on it. These are not intended to be used when a site already has content. They should not overwrite existing widgets that someone may already have in another theme when switching to Twenty Seventeen. Any re-use of the starter content widgets would have to be opt-in, per #38624.

#35 @westonruter
5 months ago

I've created a new repo to contain a parent theme and eventually child themes that exhibit all of the test scenarios: https://github.com/xwp/wp-theme-nav-menu-widget-sidebar-permutations

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


5 months ago

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


3 months ago

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


3 months ago

#39 @jbpaul17
3 months ago

  • Milestone changed from 4.8 to 4.8.1

Punting to 4.8.1 per today's bug scrub.

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.


2 months ago

#42 @westonruter
2 months ago

#19846 was marked as a duplicate.

#43 @westonruter
2 months ago

See also #19846 which suggested that an is_primary arg be added to registered sidebars. I think the ideas being explored here in this ticket are better because they account for multiple widget areas, not just the primary one.

#44 @melchoyce
2 months ago

  • Milestone changed from 4.8.1 to 4.9

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


2 months ago

This ticket was mentioned in Slack in #core-customize by obenland. View the logs.


8 weeks ago

This ticket was mentioned in Slack in #core-customize by melchoyce. View the logs.


3 weeks ago

#48 follow-up: @westonruter
12 days ago

@melchoyce If we improve the widget-sidebar assignments on theme switch, I think it is important to note that it would only improve the situation when switching to a brand new theme that hasn't been active before. Once a theme is active, it gets its own copy of which widgets are in which sidebars (stored in the sidebars_widgets theme mod, and used in retrieve_widgets()).

Improving the logic for switching will not improve the user experience when switching to a theme that was previously active. If I was on theme A and had widgets 1,2,3 in a sidebar “Foo” and then I switch to a new theme B, where widgets 1,2,3 get added to “Bar”, and I add widget 4 to that sidebar as well… if I switch back to theme A then widget 4 will be be absent from “Foo” in the re-activated theme. I can imagine this being really confusing for users, and really confounding for users who try to preview a theme switch via the Customizer. The only way I can think of to permanently that issue is to implement widget groups (#19912), but that then introduces another layer of abstraction which I understand confuses users in the nav menus system.

All of this to say, it feels like delivering this without also implementing #27404 (Allow adding inactive widgets to widget areas) will be an incomplete solution.

This ticket was mentioned in Slack in #core-customize by obenland. View the logs.


12 days ago

#50 in reply to: ↑ 48 ; follow-up: @alexvorn2
11 days ago

Replying to westonruter:
Maybe you would like to reconsider my idea - https://core.trac.wordpress.org/ticket/40067
I don't see other straight solution to the widgets problem.

#51 in reply to: ↑ 50 ; follow-up: @westonruter
11 days ago

Replying to alexvorn2:

Maybe you would like to reconsider my idea - https://core.trac.wordpress.org/ticket/40067
I don't see other straight solution to the widgets problem.

Thanks, but I don't think so. As I just noted there now, requiring a user to re-create all of their widgets every time they switch to a new theme just isn't going to go over well.

#52 in reply to: ↑ 51 ; follow-up: @alexvorn2
11 days ago

Replying to westonruter:

Replying to alexvorn2:
Thanks, but I don't think so. As I just noted there now, requiring a user to re-create all of their widgets every time they switch to a new theme just isn't going to go over well.

When switching to a new theme we can insert default widgets with their setting OR to take from the previous theme. So the user will not be required to re-create all of their widgets.

#53 in reply to: ↑ 52 ; follow-up: @westonruter
11 days ago

Replying to alexvorn2:

When switching to a new theme we can insert default widgets with their setting OR to take from the previous theme. So the user will not be required to re-create all of their widgets.

Taking widgets from the previous theme is the problem being addressed in this ticket. If there is to be an option (and UI) to reset widgets to a theme's defaults, then this should be tackled in #38624.

#54 in reply to: ↑ 53 @alexvorn2
11 days ago

Replying to westonruter:

Replying to alexvorn2:

When switching to a new theme we can insert default widgets with their setting OR to take from the previous theme. So the user will not be required to re-create all of their widgets.

Taking widgets from the previous theme is the problem being addressed in this ticket. If there is to be an option (and UI) to reset widgets to a theme's defaults, then this should be tackled in #38624.

Yeah but everything (in my idea) is different compared to what is now and will make everything less confusing.

The new approach I would like to see like this:

  1. If you switch to new theme for the first time - you will get widgets from previous theme.
  2. If you switch back to the old theme - you get old widgets from that theme not from this new theme

So it is not the same.

Now what we have and it makes everyone confusing and frustrated:

  1. If you change/edit/remove widgets and you switch back to the old theme - you can not get the old widgets for that old theme.
  2. After a theme switch you get all other theme widgets in the "Inactive Widgets" section in the widgets.php page and if you remove them you will not have them anymore if you switch back to the old theme.
Last edited 11 days ago by alexvorn2 (previous) (diff)

@obenland
3 days ago

#55 @obenland
3 days ago

I wrote tests for the existing version of retreive_widgets(), in an effort to understand the function better and hopefully maintain backwards compatibility with future changes. Not sure if I achieved 100% code coverage, but it should be pretty close.

It seems like the function has four(!) different contexts from which it's called from and behaves differently based on that context. I'll dive a bit more into the history of that function to get a better understanding, but for now the tests should at least give a little better footing to build on.

#56 @obenland
3 days ago

@azaozz @melchoyce @westonruter What do you think about moving away from the concept of orphaned widgets, and just adding any orphaned ones to the inactive sidebar?

@obenland
42 hours ago

#57 follow-up: @obenland
42 hours ago

  • Keywords has-patch needs-testing has-unit-tests added

Added a first pass in 39693.diff. It still needs some more unit tests around the mapping part.

#58 in reply to: ↑ 57 @alexvorn2
41 hours ago

Replying to obenland:

Added a first pass in 39693.diff. It still needs some more unit tests around the mapping part.

Thanks for the patch, I think my other ticket is related to this ticket... #40177
Maybe the patch will fix both tickets.

#59 @obenland
40 hours ago

I just tested it and it doesn't look like it fixed $40177. I'll try to write a test case for it and see if I can cover that too.

@obenland
39 hours ago

#60 follow-up: @obenland
39 hours ago

@alexvorn2 Could you test with 39693.2.diff and see if you can still replicate #40177?

#61 in reply to: ↑ 60 ; follow-up: @alexvorn2
38 hours ago

Replying to obenland:

@alexvorn2 Could you test with 39693.2.diff and see if you can still replicate #40177?

I get some warnings after theme install:

Warning: array_merge() expects at least 1 parameter, 0 given in D:\Dropbox\htdocs\wordpresslastmu\wp-includes\widgets.php on line 1149

Warning: array_diff(): Argument #2 is not an array in D:\Dropbox\htdocs\wordpresslastmu\wp-includes\widgets.php on line 1150

Warning: Invalid argument supplied for foreach() in D:\Dropbox\htdocs\wordpresslastmu\wp-includes\widgets.php on line 1152

Warning: array_merge(): Argument #1 is not an array in D:\Dropbox\htdocs\wordpresslastmu\wp-includes\widgets.php on line 1159

#62 @alexvorn2
38 hours ago

Strange the warning come from nowhere...

Maybe I patched twice...

Can't replicate the warnings, today first time patched a file, for WordPress.

I tested twice and it seems to work nice for me. So after making all steps in the #40177 ticked all file changes seems to work and I get the right widget in the sidebar I was looking for.

#63 in reply to: ↑ 61 ; follow-ups: @obenland
38 hours ago

Replying to alexvorn2:

I get some warnings after theme install:

Hm, I hoped I had those fixed. You said you can't reproduce them anymore?

#64 in reply to: ↑ 63 @alexvorn2
37 hours ago

Replying to obenland:

Replying to alexvorn2:

I get some warnings after theme install:

Hm, I hoped I had those fixed. You said you can't reproduce them anymore?

I can! It seems when there a not widgets in any sidebars - warnings occur.
How to replicate:

  1. Remove all widgets in every theme.
  2. Activate another theme.

#65 in reply to: ↑ 63 @alexvorn2
36 hours ago

Replying to obenland:
Can you please tell me what you think about my idea that was closed by westonruter: #40067

#66 @obenland
36 hours ago

Thanks! I'll have it fixed in the next version of the patch

@obenland
35 hours ago

Updated tests for original retrieve_widgets().

#67 follow-up: @alexvorn2
22 hours ago

Thanks for update.

I tested and what I can say it works better than it was before when after a theme switch all widgets move to Inactive Widgets sidebar.

Does it mean we can get rid out of it? I have a ticket for this too and it was closed again by westonruter in #40219 .

Last edited 22 hours ago by alexvorn2 (previous) (diff)

#68 in reply to: ↑ 67 ; follow-up: @obenland
20 hours ago

Replying to alexvorn2:

Does it mean we can get rid out of it?

I don't think so. I feel like there should be a place for widgets that have active settings but are currently not shown.

#69 in reply to: ↑ 68 @alexvorn2
19 hours ago

Replying to obenland:

Replying to alexvorn2:

Does it mean we can get rid out of it?

I don't think so. I feel like there should be a place for widgets that have active settings but are currently not shown.

Yeah! but how will these widgets show in the Inactive Widgets sidebar now with this new patch?

Or you mean the widgets that are currently in the Inactive Widgets widget area so after WordPress update they will show there..., but after a theme switch they will not be there anymore, right?

#70 @obenland
19 hours ago

There is still a possibility for widgets to end up there if we can't match one sidebar up to another, it's just less likely. Also users might decide to "park" a widget there, regardless of a theme switch.

#71 @obenland
19 hours ago

In 41266:

Widgets: Add tests for retrieve_widgets().

Helps with maintaining back compat when making changes in the future.

See #39693.

@obenland
19 hours ago

#72 @alexvorn2
18 hours ago

OK, then I will close my ticket - #40177.

#73 @alexvorn2
18 hours ago

#40177 was marked as a duplicate.

Note: See TracTickets for help on using tickets.