Customize Themes without activation

[kkkrys]

Add a posibility to customize deactivated themes with the Theme-Customizer without activating them by default.
Useful for Blogs running multiple Themes between which the frontend user can switch.

[celloexpressions]

This sounds like a good idea; essentially we just need to add a "Save but don't activate" button. Your use case is probably uncommon, but this would be a nice way to allow users to work on customizing different themes before activating without doing it all at once. As additional features such as widgets are added to the customizer, allowing users to save work-in-progress customizations without activating the theme is a pretty important feature.

[helen]

I think it's probably more than a differently labeled button (and the storage mechanism to go with). What's the experience when a user customizes an inactive theme, saves those customizations but doesn't activate the theme, and then goes back to customize it later? Do we then need a reset button? Is it less useful because there's no selective or step-by-step undo?

[celloexpressions]

Replying to helen:

What's the experience when a user customizes an inactive theme, saves those customizations but doesn't activate the theme, and then goes back to customize it later? Do we then need a reset button? Is it less useful because there's no selective or step-by-step undo?

We don't have the ability to reset or selectively undo changes for active themes either, so I don't think we need to worry about that here. That really sounds like something that customizer revisions would handle (like .com's snapshots I believe), which would be super cool but are a separate (and much bigger) issue. For now, having the ability to save changes without activating is more important than adding the ability to reset all options or undo revisions, since you could almost call the current behavior a bug.

In terms of the storage mechanism; I'm guessing it's pretty much already in place, we just need to skip the theme switching part (or if that happens first, switch back). This could also allow users who can't switch_themes but can edit_theme_options to make customizations to inactive themes. I think we'd probably retain the existing button as the primary, and add a new secondary one for this.

[celloexpressions]

I believe (@westonruter, correct me if I'm wrong) that Customizer transactions (#30937), combined with theme-switching, would enable theme customizations to be saved without activating that theme, without any UI. If that happened, we could consider reset UI.

[westonruter]

Replying to celloexpressions:

I believe (@westonruter, correct me if I'm wrong) that Customizer transactions (#30937), combined with theme-switching, would enable theme customizations to be saved without activating that theme, without any UI. If that happened, we could consider reset UI.

Correct. When loading the Customizer you could also select from transaction drafts to restore the settings from a previous un-saved Customizer state.

By the way, I think that the way that theme switch is handled in the Customizer should be changed. Right now the theme gets passed in as a query parameter in an out-of-band way in relation to the other options being Customized (e.g. blogname). There should be a theme setting that is registered which, when saved, causes the switch_theme logic to happen. This is something I'm considering as an improvement along with transactions, since it would then allow you to create a transaction in which the theme is switched, and schedule the transaction for some future date, allowing the theme switch to be scheduled when the transaction is “committed”. The theme setting should be registered with the switch_themes capability.

[westonruter]

For the ticket regarding a reset button, see #21666.

[karmatosed]

I think we have to be very careful about the flow for users here. I can see this could easily confuse and make someone think they have activated a theme when haven't. I am unsure this is needed outside of the use case and/or that it's not a very small portion of people this would be useful for. To that point, it would be great to find out if that is the case.

I like the idea of a reset button, that's a separate idea from this ticket but would be part of this flow. Regarding this ticket, I would probably suggest we don't add this as it feels like we're adding complication for something only a minority need. At best, maybe activate it only in multi-site.

[eric1985]

I just came across this ticket because I was hoping the feature existed. Bumping this up to hopefully land on someone's radar for an upcoming release.

I'm a theme developer using a framework that has widgetized homepage and other sections. Being able to get a site laid out and saved without switching would be a huge benefit and time saver regularly for me.

[westonruter]

Technically speaking, this would probably require a new query param like skip_activation=1 to bypass the default behavior of activating the theme. This may be doable today via feature plugin, but it would require some R&D.

[bluenestbryan]

I am also interested in this feature. I am a PHP developer with some WP experience in writing plugins and themes. If it gets consensus and implementing this isn't too complex, I am open to working on this if possible. It sounds like we would need to 1) add an html button/control for it, 2) create a query param to pass the value and 3) Check the value and act accordingly. Numbers 1 and 3 seem pretty straight forward - the relevant section of the save_changeset_post() method in wp-includes/class-wp-customize-manager.php is below. It looks like that is where the check would have to take place.

                $data = apply_filters( 'customize_changeset_save_data', $data, $filter_context );
                // Switch theme if publishing changes now.
                if ( 'publish' === $args['status'] && ! $this->is_theme_active() ) {
                        // Temporarily stop previewing the theme to allow switch_themes() to operate properly.
                        $this->stop_previewing_theme();
                        switch_theme( $this->get_stylesheet() );
                        update_option( 'theme_switched_via_customizer', true );
                        $this->start_previewing_theme();
                }

---

Regarding the opinion on the best way to implement this in the UI:
I think the existing "Save and Activate" is doing two things which should have been separate to start with, but obviously users now have an expectation. I am wondering if perhaps an "Activate theme" checkbox or dropdown next to the button would be clear enough - the button would have to be renamed "Save" for clarity.

Looking forward to discussing more.

[westonruter]

This is actually possible now with changesets. You can preview a theme switch, and make changes, and then instead of clicking “Save & Activate” you instead can copy the URL to come back to later. Not a great UI and the changeset currently will be garbage-collected after 7 days. Also, the previewed theme itself would not be stored in the changeset, so you'd need to make sure you keep the theme query param intact with the changeset_uuid to return the theme and the changes. This would be addressed in #39031.

It's quite a bit overlapping with #31089 as you're essentially wanting to create a draft of changes for another theme.

[celloexpressions]

I have run into several use cases for this now. In particular, it would be nice to use the changeset-preview link to share a preview of a theme switch for review.

At its simplest, even without revisions UI, this ticket could enable the "save draft", "schedule", and preview link options during a theme switch. Currently the only way to save any customizer changes during a theme switch is to publish them to the live site.

As noted above, customizer revisions might need to be implemented first. Once that's done (now consolidated to #21666), then there's a UI for revisions that clarifies expectations about different sets of drafted changes. Then work can proceed on this ticket to allow mechanisms to save draft changes for a theme switch. Discussions about enabling branched revisions (ie, multiple sets of drafted changes potentially with different themes) could follow as a final (most complex) step.