[wp-trac] [WordPress Trac] #17979: Avoid losing widgets when switching themes
WordPress Trac
wp-trac at lists.automattic.com
Thu Sep 8 01:23:06 UTC 2011
#17979: Avoid losing widgets when switching themes
-------------------------------------------------+------------------
Reporter: lancewillett | Owner:
Type: enhancement | Status: new
Priority: high | Milestone: 3.3
Component: Widgets | Version: 2.9
Severity: normal | Resolution:
Keywords: ux-feedback has-patch needs-testing |
-------------------------------------------------+------------------
Comment (by trevogre):
Azaozz,
"Having persistent widget configs wouldn't work well".
I hear what you are saying, but changing themes doesn't work well. I would
say that changing themes on a production site is almost completely wrong.
Selecting a theme is a staging task, modifying a theme is a staging task.
Pushing a theme from version control is where the changes should happen.
If that is the case, then preparing widgets should be a staging task as
well as on highly trafficked site you don't want to have to race to
update your widget configuration after you have changed a theme.
As for the usability issue, that could be solved by showing and loading
the widget configurations by theme. Which if you are staging a theme
change, you would want to do. Say, I'm thinking about switching to 2011, I
would want to prep a widget configuration before making the theme go live,
maybe even in functions.php, register the sidebars and the desired widget
configuration.
This is all really just broken, widgets are a bad idea because in their
current form they encourage onsite edits of something other than content
with zero version control. Because widgets are really code modifications.
Just because they are wrapped up and have a visual configuration for
running the function, doesn't make it any less a modification of which
code runs to build your page.
As for the existance of similar functionality in plugins. I agree that
this is a core issue. You don't make any progress on common theming
standards by leaving versioning of widget configurations in plugins.
Theme developers need a clear expectation of what is going to happen with
widgets when someone switches on their theme, if not total control.
The idea of a timeout and progressive mapping also irks me. Consider three
sidebars "header", "sidebar", "footer". Then you switch to a theme with
"header", "footer". Progressive mapping maps the "sidebar" to the
"footer". This is clearly wrong if you have matched names. Then even with
a timeout where widget settings magicly get restored, once the timeout is
over and you switch back, you now have two sidebars and your "sidebar" is
now your "footer".
That seems equally or more dangerous than a persistent configuration. With
a persistent configuration you know that you have made the choice of what
to put in each theme. And nothing random happens without deliberate user
action. So if you switch one or two times you quickly find out that each
theme requires a one time config of widgets and that they persist. That is
surprising people with control. Automapping is suprising people with a
lack of control and deliberately making incorrect assumptions about their
intentions. People would never add content to something clearly labeled
"footer" and expect that to end up in a sidebar.
Is there really any other way to look at it?
The extra layer of interface function on theme switch should be a
notification that you theme has change and you have (n) empty sidebars and
(y) sidebars that match by name. Then an ability to copy a config from
another theme to your new sidebar. Thought non of that would be critical
with persistence.
I would like to see that rolled out on wordpress.com and see how quickly
it gets rolled back. :)
--
Ticket URL: <http://core.trac.wordpress.org/ticket/17979#comment:75>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list