[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