I realized that when switching the theme (in my case to a child theme) some things don’t stay the same:
At least this is what I found out so far:
Widgets
Don’t lose widgets when switching themes
Avoid losing widgets when switching themes
Menus
Switching to child theme breaks menu names
My question is if there is anything else that is stored on the basis of active themes and where I can find more information on this whole behaviour.
After doing some research this answer became a bit longer than expected, but this is the essence:
TL;DR: Menu placement and Widget placement/order is saved on a Theme basis and can therefore be restored when switching Themes. This does not include the individual settings of Menus and Widgets, so if you change them these changes are global to your WordPress site and can’t be rolled back.
Before I go into the details of all of this let me make one more thing clear: These are the things that are saved by default on a Theme basis. This doesn’t mean that there are no other things that might be saved on a Theme basis or that change or break when switching Themes. Just a short and non-exhaustive list of things that might get saved, changed or that break when switching Themes:
- Custom Post Types (that are registered in one Theme but not the other)
- Shortcodes (that are registered in one Theme but not the other)
- Custom Theme settings of a Theme (some Themes save their settings on a Theme basis which might not transition when e.g. switching to a Child Theme)
- Plugins (that are not supported by the new Theme)
- …
Now that we have this out of our way let’s have a look at the details of Menus and Widgets
Menus
Actually the data structure behind Menus isn’t trivial. For more details have a look at this answer
That being said I’ll recap on the main relevant things:
- Menus are named sets of Menu-items
- Theme locations are named places defined in a Theme where you can place Menus
- Menus can be associated with these Theme locations in the WordPress backend under Appearance > Menus
- these associations are then saved on a Theme basis
Let’s look at an example:
- Menus M1, M2, M3
- Theme A (Theme Locations A1 and A2)
- Theme B (Theme Locations B1, B2 and B3)
You have Theme A active with these associations set:
M1 -> A1
M2 -> A2
M3 -> A2
Now you activate Theme B. This Theme doesn’t have any associations set yet:
M1 -> inactive
M2 -> inactive
M3 -> inactive
We now change this to:
M1 -> B2
M2 -> B2
M3 -> inactive
If we switch back to Theme A we’ll again have:
M1 -> A1
M2 -> A2
M3 -> A2
Now we delete M1 which affects Theme A and Theme B. Therefore if we again switch to Theme B we’ll only have:
M2 -> B2
M3 -> inactive
I’ve created an animation to illustrate all these changes:

Pitfalls
- As already said the only thing that is saved on a per Theme basis are those associations. If you change or delete a Menu this change will be global affecting this Menu no matter which Theme is active.
- Child Themes are handled as being different Themes. So if you setup all your Menus and then switch to your Child Theme you’ll need to re-associate Menus to Theme Locations.
Widgets
With Widgets the situation is a bit different and even if not drastically more complex still more confusing.
The main difference is that with Menus these groupings of Menu items exist independent of their usage in Themes.
With Widgets on the contrary this Theme-independent intermediate step doesn’t exist. Widgets are directly assigned to Widget Areas which are Theme-specific. So switching Themes might cause a bit more of a mess than with Menus. Let’s recap again:
- There are Widgets
- There are Widget Areas (a.k.a Sidebars)
- Widgets can be associated with Widget Areas in the WordPress Backend under Appearance > Widgets
- These Associations are then saved on a Theme basis.
What happens on Theme change is this:
- If the new Theme has a different number of Widget areas Widgets are moved according to order ignoring ids. So no matter how the Widget Areas are named, what was in the first Widget Area in Theme A will be in the first Widget Area in Theme B.
- Widgets that don’t have a corresponding Widget area are moved to inactive sidebar areas.
- In this process of switching Themes before any changes are done the old configuration is saved with the old Theme.
Let’s look at an example again:
- Widgets W1, W2, W3, W4
- Theme A (Widget Areas TOP, RIGHT, BOTTOM)
- Theme B (Widget Areas HEADER, FOOTER)
You have Theme A active with these associations set:
W1 -> TOP
W2 -> RIGHT
W3 -> BOTTOM
Now you activate Theme B. Widgets are automaticaly transfered according to the rules mentioned before.
W1 -> HEADER
W2 -> FOOTER
W3 -> inactive sidebar
We now change this to:
W1 -> HEADER
W2 -> FOOTER
W3 -> FOOTER
If we switch back to Theme A the former configuration is restored, so we’ll again have this:
W1 -> TOP
W2 -> RIGHT
W3 -> BOTTOM
Now we delete W3 which affects Theme A and Theme B. Therefore if we again switch to Theme B we’ll only have:
W1 -> HEADER
W2 -> FOOTER
I’ve again created an animation to illustrate all these changes:

Pitfall
- Again, as with Menus the only thing that is saved on a per Theme basis is Widget placement and order. If you change or delete a Widget this change will be global affecting this Widget no matter which Theme is active.
I tried to make this as clear and extensive as possible but if you have anything to add or any feedback for the animations please leave a comment or file an edit!