This is a proposal for how theme-switching and theme-installation could be incorporated into WordPress’ Customizer. This will eventually be attempted in some form as a feature-plugin to later be merged into WordPress core. The goal is to soften the distinction between themes and theme options and to make theme switching a fast, streamlined experience built-in with other Customization options in a unified interface.

Themes is a panel, but with backwards-sliding, coming in from the left instead of the right. This implies a new layer of hierarchy above the top-level controls. Switching contexts to the theme-browser is just like switching contexts to a panel, but to exit the themes context, you select a theme. The currently active/currently previewed theme is selected and has an arrow back to the right, to slide back to the top-level controls. All of this sliding can also be triggered by swiping on touch devices.

When a different theme is selected from the theme browser, it instantly slides back to the main panel of top-level controls, but now reflects the controls available in the new theme. This is accomplished by rendering the controls specific to the new theme via ajax and the new customizer sections/panels JS API, and then deleting the controls that were specific to the old theme. This should be doable in a back-compatible way by working some trickery with the existing customizer APIs, caching stuff, and/or leveraging WP-API.

The preview would instantly need to switch to a loading indicator until the front-end re-rendered with the new theme, but that shouldn’t take too long and is unavoidable regardless of the implementation here.

In the theme browser, the add-new-theme functionality would be present via a + new theme tile matching the one in the current interface, and bring up a modal containing the 3.9 pieces of THX. From there, the theme-installer previewer (also containing the theme details) would need to either remain in the (almost-full-screen) modal or open in a new tab that closed on install/close-button-click (or, do a full-screen iframe on top of the customizer and modal with the theme-install-preview, although that might get a bit crazy).

We would need a solution for unsaved changes in previewed themes that are not activated, as theme-specific controls are hidden/removed when previewing another theme.

Prerequisites:

• JS API for adding and deleting panels, sections, settings, and controls, to complement the existing controls API.
• Distinction/ability to save changes without publishing and/or the ability to save without activating a new theme. Although, not distinguishing between saving and saving and activating would probably make more sense here.