WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 12 months ago

#22880 new enhancement

Customize Themes without activation

Reported by: kkkrys Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Customize Keywords: needs-patch
Focuses: ui Cc:

Description

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.

Change History (13)

#1 @SergeyBiryukov
5 years ago

  • Component changed from Themes to Appearance

#2 @celloexpressions
4 years ago

  • Keywords needs-patch ui-focus added

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.

#3 follow-up: @helen
4 years ago

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?

#4 in reply to: ↑ 3 @celloexpressions
4 years ago

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.

#5 follow-up: @celloexpressions
3 years ago

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.

#6 in reply to: ↑ 5 @westonruter
3 years ago

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.

#7 @westonruter
3 years ago

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

#8 @karmatosed
18 months ago

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.

#9 @eric1985
17 months ago

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.

#10 @westonruter
17 months ago

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.

#11 @bluenestbryan
14 months ago

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.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


12 months ago

#13 @westonruter
12 months ago

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.

Note: See TracTickets for help on using tickets.