[wp-trac] [WordPress Trac] #19300: Redirect to the Widgets screen after switching to a new theme

WordPress Trac wp-trac at lists.automattic.com
Mon Nov 21 00:30:28 UTC 2011


#19300: Redirect to the Widgets screen after switching to a new theme
-------------------------+-----------------------------
 Reporter:  azaozz       |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  Widgets      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+-----------------------------

Comment (by PaulGregory):

 Replying to [ticket:19300 azaozz]:
 > Currently after activating new theme we return the user to
 Appearance->Themes. '''There's nothing the user can do on that screen'''
 any more and we show a notice to check the widgets screen.

 Er, there *is* something the user can do on that screen. The user can
 delete the previous theme.
 The user can also click a link to visit one of the OPTIONS: screens such
 as Menu and Header - but such screens for the active theme can also be
 reached via the menu from the widgets screen, so it's not a great argument
 against as things stand.

 Replying to [ticket:19300 azaozz]:
 > It would be better to redirect them to Appearance->Widgets instead

 If we go down this path, it should redirect to the first applicable screen
 in the OPTIONS: list (ie Widgets | Menus | Theme Options | Background |
 Header). It may also make sense to show a tooltip pointing to the menu
 which says what other options can be configured.

 However, I think it would be far better if necessary configuration code
 was run during the activation (specifically, during any creation of a
 configuration) rather than moments afterwards. It's possible that one day
 auto-matching of Menus will be desirable too, and we can't redirect to two
 screens, so it's best to sort things out on the -> Themes screen. As an
 aside, the top section of Appearance->Themes should contain notices about
 *all* things that require configuring, not just Widgets.

 I disagree with any activity that takes place on the presumption that the
 current active theme is a new theme and the previous one was an old theme.
 I think this is a mistake as there are use cases for showing different
 themes to different viewers.

 I have three tangental ideas about themes which would be made harder by
 redirecting to Widgets rather than having code that can be run at the
 right moment from any screen. (If anyone likes them and would like to
 raise a ticket for them, or find an existing ticket, great. I haven't
 enough time.)

 ''Tangental Idea No 1:'' "Preview" should show what the site will look
 like. Therefore it should do everything that Activation would do, and run
 the same sidebar matching code.

 Problem: Needs matching code to be run without redirecting to Widgets.

 ''Tangental Idea No 2:'' Long-term, I believe it is desirable for theme
 configuration to take place BEFORE activation. Next to Activate and
 Preview there would be Options. Clicking this would load a screen with a
 top part much like the active theme, with links to Widgets | Menus | Theme
 Options | Background | Header. When Options is clicked, if there were no
 options saved for this theme, then the during-configuration-creation
 options would be run. It would still be possible to configure options
 after activation, but this approach would aid a new workflow - allowing
 admins to get their widgets sorted out by making changes and looking at
 Preview rather than by making changes on a "live" site.

 Problem: I've invented links that aren't on the menu, so the user needs to
 see that they are all available, not redirect to Widgets.

 ''Tangental Idea No 3:'' The Options screen should (long term) include
 facilities for the loading and saving of theme configurations including
 widget settings.

 Problem: This should match Appearance->Themes so we need to show options,
 not redirect to Widgets.

 In short, I think redirecting to Widgets may save one click for 99% of
 users today and make some coding easier but it's a shortcut that will make
 some possibilities more awkward to implement. Obviously my tangental ideas
 may never come to fruition, but something like them may do.

 I recommend a rethink.

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


More information about the wp-trac mailing list