Widgets shift when new sidebars added/removed

[batmoo]

When an *empty sidebar* is removed or a *new sidebar* is adding next to an empty sidebar, widgets will shift down one sidebar.

Steps to reproduce:

1. Add a bunch of sidebars, sidebar-1, sidebar-2, sidebar-3, sidebar-4 (using register_sidebar)
2. Add text widgets to all of them (title them 1, 2, 3, 4 respectively)
3. Remove the widget from sidebar-2 (so that it’s completely empty)
4. Remove sidebar-2 (remove or comment out the register_sidebar call)
5. The widgets will “shift” (sidebar-3 will be empty, sidebar-4 will have text widget titled “3″)

You can also reproduce the issue by adding a new sidebar-1.5 (instead of removing) at step 4.

It's a bit of an edge-case but is particularly a problem when you have dynamically generated sidebars (based on custom post types and taxonomies, for example) or during theme development. The first use case is becoming more common, for displaying sidebars specific to different single and archive pages.

[batmoo]

functions.php with register_sidebar calls for testing

[batmoo]

Patch attached.

[batmoo]

Alternate patch also works. Addresses the use of array_shift, which assumes that registered sidebars are the same as the sidebars in options.

[lancewillett]

See also #19092.

[azaozz]

In [19334]:

Prevent errors in assigning widgets to sidebars for themes with dynamic sidebars, props batmoo, fixes #19274

[azaozz]

Replying to batmoo:

Changed the test for existing sidebar from empty() to !isset() to avoid processing sidebars that are really empty, could you see if that still works as expected.

Alternate patch also works.

We may need to add this patch too. If a user switches themes but doesn't go to the widgets page (as we advise), the sidebars may remain messed up. This case needs more testing.

[azaozz]

Chatted with @batmoo, works as expected now.