WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

#19300 closed enhancement (wontfix)

Redirect to the Widgets screen after switching to a new theme

Reported by: azaozz Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Widgets Keywords:
Focuses: Cc:

Description

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.

It would be better to redirect them to Appearance->Widgets instead (if the new theme supports widgets of course). That would serve two purposes: letting them fix/rearrange widgets that may not have been put in the right place and run our code in wp-admin/widgets.php that matches sidebars between the old and the new theme, looks for lost widget instances, etc.

Change History (5)

comment:1 in reply to: ↑ description PaulGregory2 years ago

Replying to 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 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.

comment:2 follow-up: jane2 years ago

There are many things we all want to do to improve the switching-themes experience. We can't do any more of them in 3.3. We will not redirect to the widgets screen, as that would be unexpected behavior.

comment:3 in reply to: ↑ 2 ; follow-ups: jane2 years ago

Replying to jane:

We will not redirect to the widgets screen, as that would be unexpected behavior.

The reasons for this were listed on the ticket the suggestion was originally made on, but don't remember which one it was. Instead of a redirect, my expectation (based on conversations with several core devs) is that at some point we will make a 'changing themes flow' that instead of being a go-to-all-these-screens kind of experience will be more of a guided wizard so that the act of activation actually has several steps, with updated widgets etc before going live.

I would like to close this as wontfix, but will wait for another core team opinion or two in case there are radically different ideas that haven't come to light yet.

comment:4 in reply to: ↑ 3 nacin2 years ago

Replying to jane:

I would like to close this as wontfix, but will wait for another core team opinion or two in case there are radically different ideas that haven't come to light yet.

Looks like my comment didn't go through earlier. At WCSF most of the core devs indicated a preference for an interstitial/migration tool when switching themes, which would cover widgets/sidebars, menus/locations, header, background, and the like. So this one is clearly wontfix to me.

comment:5 in reply to: ↑ 3 azaozz2 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Replying to jane:

Agreed, closing in favor of a 'changing themes flow'.

Note: See TracTickets for help on using tickets.