Add a switch themes link to the Theme Customizer

[celloexpressions]

While typically (and historically) the theme customizer has been accessed primarily from themes.php, it is now quite easy to visit the customizer outside of the context of the list of available themes.

The idea of the customizer is to provide an easy way to make visual tweaks to your site with a live preview, but the changes are primarily made at a theme-specific level. Adding a link/button to switch themes would help users make the connection that beyond the minor tweaks that can be made in the customier, the theme can be changed entirely (similar to the language used in the Dashboard Welcome panel).

I'm thinking that an appropriate place for this would be as either a link or a secondary-button-formatted link at the bottom of the theme description section, but there could certainly be other, better solutions. Even though the "close" button often goes to themes.php, depending on where the customizer was accessed from, the addition of a more-specifically-worded "switch" or "browse" themes button would help make the relation between themes and the customizer/theme options more apparent, particularly for new users.

[celloexpressions]

Add a "Switch Themes" button to the current theme description section.

[helen]

Two things:

1. If this were to be a thing, it should be a link, not a button. It links somewhere else.
2. This seems like a weird flow - you just get dumped onto another screen where, yes, you can switch themes, but also many other things. As a user, I would expect to be able to pick another theme right in the customizer if I saw that.

I'd rather see something that brings the ability to browse and preview/live preview themes right in the customizer itself, and even then I'm not necessarily sure that's where we should go, more just that I'm curious. Tumblr does something like that, for what it's worth.

[celloexpressions]

Replying to helen:

1. If this were to be a thing, it should be a link, not a button. It links somewhere else.

Good point, that would be better (only went with a button because it was more prominent).

2. This seems like a weird flow - you just get dumped onto another screen where, yes, you can switch themes, but also many other things. As a user, I would expect to be able to pick another theme right in the customizer if I saw that.

I thought about this too at first. This ticket basically comes from the concern that the "You are prewieving X Theme" section isn't actionable -- it just kind of sits there and doesn't say anything about how to preview a different theme.

While an in-customizer theme-switching UI would be awesome, it presents a lot of challenges. At a minimum, it'd probably need to reload the entire customizer, since different themes can add different sections and controls. We also have a great theme browsing/switching/previewing interface on themes.php, and I would consider its primary purpose to be browsing themes, everything else there is basically linking to other pages.

Since bringing theme-switching into the Customizer is a big project that may or may not be worth pursuing, I think it would be good to at least link to themes.php for now, then revisit it later. However, if the general consensus is that taking a different approach would be more appropriate, that works too.

[celloexpressions]

I've been thinking about this more, and think that adding theme-switching to the customizer would be a good long-term goal, as more of wp-admin moves there and to the frontend. Perhaps the THX feature-plugin team could look at this after completing the theme-installer revamp.

In the meantime, I still think that at least a reference to the external place where you can switch themes is an improvement over the current behavior. Doing that via a link seems most appropriate, then we could change it to a button once the shiny new theme-switcher was completed.

[celloexpressions]

This is invalidated by #28550.

The issue here was that the theme description and screenshot didn't fit without having a clear purpose - such as in the context of a theme preview (where the close button returns you to the themes context). Until we can implement theme-switching in the Customizer, which requires a fair amount of Customizer JS API work, we don't need to link to other themes, since there is no longer a reference to the currently active theme in the Customizer.

[folletto]

I'm reopening this ticket as mentioned on #28979. Here's the relevant piece of discussion:

Folletto: The proposal you make is very similar to a design concept I was working on too, even if the "slide back" actually triggered a full screen view (from the left slides in a full page that covers everything, which is in practice the 3.9 theme browser), the reason is that it would be too constrained to fit inside a small column (even if, that would be exactly how it would behave on mobile).
But apart from that, I agree 100% that it should be the hierarchy to imply there.

We could still add an intermediate step: it could be simply a link back (click, open Themes panel in the admin area), and we can work on the better interaction (sliding panels, API, etc) at a later stage. ;)

So... worth a new ticket? ;)

Celloexpressions: Great idea! We could even slide in themes.php in a full-screen iframe from the left of the screen, and then trigger a new full pageload to get out of the iframe as soon as the user navigates somewhere (such as, most commonly, to customize a new theme). If you want to make a new ticket, or even re-open #26890 with a comment, I can throw together a rough patch as I have an idea for how we could accomplish that from a technical perspective. Now that we have an AYS for unsaved changes, linking away from the Customizer isn't a huge deal. If the Customizer was opened from themes.php, we would already have that page's DOM loaded thanks to customize-loader, so it would just be a matter of changing the animation that closes the Customizer iframe. Not the ideal experience that doing it all in the customizer would be, but a good approach while we build up the API, and at least we can start to make the themes vs. theme/site options relationship clearer. If we get a few people working on it, could probably get that into 4.1.

The advantages are plenty:

1. It would create a two way navigation showcase <-> customizer, allowing a better customization experience
2. It would reinforce a clear navigation hierarchy, where Themes are at the top, then customizer menu, then individual customizer options, and then (well, on the side) the site preview itself the final result.
3. It would consolidate further the customization experience in one "place".

This can be done in a two step development (or more, if worth it):

1. Convert the current "You are customizing" top accordion to a simple link back to the Themes browser page.
2. Substitute the simple link back to a more structured navigation, with a full-screen sliding-in panel that contains the full showcase, with a smooth transition and ideally well integrated in the customizer navigation structure itself.

I hope this helps. :)

[celloexpressions]

First-pass at a themes panel that links to themes.php (not fully functional). Implemented as a custom panel for forward compat.

[johnbillion]

Not having the ability to switch themes from within the customizer is particularly apparent when you're testing the differences between themes and customizing them at the same time. Having to move in and out of the customizer to switch themes becomes quite jarring.

[celloexpressions]

Fully-functional switch themes link in the Customizer, as a back-panel heading.

[celloexpressions]

Updated patch is fully-functional if we want to go the route of linking to themes.php until we're able to implement theme-switching into the Customizer.

While this isn't necessarily the best option, it is a functional approach that works until we have the resources to do it fully, and it addresses a huge UX problem with how themes & the Customizer interact. No, you can't switch themes in the Customizer, but we do provide a logical flow for going back and forth between the themes screen and the Customizer.

[westonruter]

Customize Transactions (#30937) would provide an easy way to implement theme switching from within the Customizer.

With transactions, any setting change gets stored in a persistent wp_transaction post. It allows you to load the Customizer with the transaction specified in the URL, allowing the full state of the settings in the Customizer to be restored. In the context of a theme-switch link, the way it would work given the current state of transactions:

1. Load the customizer /wp-admin/customize.php. Since no transaction is specified, a transaction UUID is generated and made available in a JS setting.
2. Make some changes to controls if desired. Any changes to settings here get synced to WP and persisted in wp_transaction post.
3. Open the Themes panel and select a different theme, e.g. twentyfifteen
4. The browser would then navigate to /wp-admin/customize.php?theme=twentyfifteen&customize_transaction_uuid=$uuid&url=$url, where $url is the current page being previewed in the Customizer Preview, and $uuid is the UUID that was generated when the page loads.
5. The Customizer loads and any settings in the transaction are restored to the controls, and the new theme is now appearing in the preview.

While reloading the Customizer in the context of the switched-to theme is the easiest way to refresh the UI, a better user experience would be to dynamically populate the Customizer pane with any new panels/sections/controls that the new theme defines. This ability would be dependent on #28580, the Customizer Preview would need to be able to postMessage the panels, sections, and controls that are registered.

[folletto]

Can we add screenshots any time we patch something with a UI impact? Thanks! :D

[celloexpressions]

Replying to folletto:

Can we add screenshots any time we patch something with a UI impact? Thanks! :D

Stay tuned for something much better in 24-48 hours :)

[celloexpressions]

A lot has changed since I first opened this ticket a year ago. Long story short, the Customizer API improvements introduced in WordPress 4.0, and especially 4.1, make it possible, even easy, to implement theme browsing in the Customizer.

I've created what started as a quick experiment and quickly became a viable solution for core: the ​Customizer Theme Switcher plugin.

A backwards-panel-like custom section and custom js-templated controls integrate with the existing themes API and CSS to bring the themes.php experience into the Customizer, entirely with the 4.1 Customizer API. Theme-switching is implemented simply by reloading the Customizer to preview a different theme, with the existing AYS confirmation preventing users from losing their changes. If the Customizer Transactions API makes it into 4.2, theme switching could be enhanced by the addition of the ability to persist customizations across Customizer reloads and theme switches, per @westonruter's explanation above. In the future, when the Customizer API has evolved sufficiently, we can remove the customizer-reload requirement, but there's no need to wait for that functionality to implement the very usable UI.

I'm closing this ticket in favor of proposing the ​Customizer Theme Switcher plugin for core merge in 4.2. There are some good UX thoughts here, and they are taken into consideration with ​my post from last summer in the plugin's implementation. Now that the basic functionality is in place in the plugin, I'd like help evaluating the user experience and making iterative improvements. I'll be around in #core-customize on Slack and would like to continue work & feedback on the plugin there for the next couple of days before the feature-plugin meeting this Tuesday.