[wp-trac] [WordPress Trac] #17979: Avoid losing widgets when switching themes

[WordPress Trac]

#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):

 I didn't check the code, but there seems to be a focus on mapping sidebars
 when the names are different, based upon the number of sidebars.

 I think that is a mistake. Imagine there is a scenario where I want to use
 theme versions as a test mechanism. So I make a new version of theme x
 that I want to launch on date y. It has a new layout that includes
 "my_extra_sidebar" and removes another sidebar. So I have 2 sidebars. The
 new sidebar is a left sidebar and the old a right. Which should have
 distinct (preprepared) content.

 If the seems switch simply iterates through the existing bars and shoves
 them in places, that is one more manual step to insure that the new theme
 is functioning properly. And the inverse is true, if I automaticly switch
 back I have to check the site to see if its functioning.

 I would rather end up with nothing in that space than the wrong thing.

 This is a major issue with the existance of widgets at all. They live both
 in database and in the theme design. So you can't use the themes version
 control on them and there is no version control for them in the database.
 So is thier convience even worth it when they seem to encourage bad
 practices.

 What is the workflow that incorporates the use of widgets that is not
 considered the data version of cowboy coding. Mucking up the presentation
 of your data with no rollback on your production server. Who should have
 that level of access? If it's at the admin level I would rather build the
 sidebar with shortcodes in a version controled template revision. Because
 according to some commiters (if not all) not using version control is
 wrong.

 Not hacking on the effort, this is a good first step. I would just agree
 that the ultimate focus needs to be on registering sidebars like menus. So
 "footer" maps to "footer" on a theme change and no widget configurations
 are deleted ever. Auto mapping widget bars will just create a whole
 different set of problems where footer widgets get stuffed into sidbars
 and other equally disfiguring things.

 I'm not even concerned if I know in the backend what is inactive and
 active. That seems like extra code that is needed less than the ability to
 build n configurations for widgets. If you are configuring widgets you
 should be able to check the site to know where your changes are occuring.
 And know which widget areas your theme supports. If you don't know this or
 aren't expected to figure it out then what are you doing with the
 responsibilty for changing themes?

 I'm new to commenting on here, so please let me know if these kinds of
 verbose comments are unwarrented and/or unwanted.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/17979#comment:65>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software