WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 19 months ago

Last modified 19 months ago

#34843 closed enhancement (fixed)

Customizer: allow themes in the Customizer to be disabled by plugins

Reported by: mattwiebe Owned by: celloexpressions
Milestone: 4.9 Priority: high
Severity: normal Version: 4.4
Component: Customize Keywords:
Focuses: Cc:

Description

#33552 introduced filters to disable widgets and menus in the Customizer. We should have the same thing for themes. There are ways to do this already, but they are a bit frustrating since it would be better not to have the relatively expensive wp_prepare_themes_for_js() function run at all.

Happy to provide a patch if this gets accepted.

Change History (21)

#1 @westonruter
3 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release
  • Owner set to mattwiebe
  • Status changed from new to assigned
  • Version set to trunk

@mattwiebe Makes sense to me. It's not quite as straightforward since there isn't a dedicated class for managing themes in the Customizer. But what when the filter for customize_loaded_components runs, the return value containing the array of component slugs could be stored in a protected class variable on WP_Customize_Manager. Then when the sections, controls, and settings for themes are to be registered, it can check to see if the array filtered by customize_loaded_components contains “themes” or not. If not, then they wouldn't get registered. That's the implementation method that comes to mind.

#2 @westonruter
3 years ago

  • Keywords good-first-bug added
  • Owner mattwiebe deleted

Actually, this would be a good first bug so I'll unassign so that someone at contributor day can pick it up. Otherwise, it's all yours @mattwiebe :-)

#3 @nacin
3 years ago

Unfortunately this filter should have passed null and allowed an empty array to be returned back all the way through.

There are 38 filters in core that pass an array() as the first argument, but this is the only one that is explicitly labeled a pre hook. 23 other filters pass null or false. So this is definitely an unfortunate exception.

Sounds like the best workaround here, @mattwiebe, would be to return back exactly one theme — the current one, which is almost surely already in local cache — then otherwise unhook the control.

#4 @mattwiebe
3 years ago

Not sure what you're meaning there @nacin - the customize_loaded_components filter? It doesn't have a pre_-fix - are we somehow bringing pre_prepare_themes_for_js to the table here? I am making use of that right now to help make the initial, unavoidable themes registration less costly so that I can go in afterwards and unhook things, and it works, but thought it would be good to have something less puzzling for folks less familiar with the internals.

#5 @celloexpressions
3 years ago

  • Keywords needs-patch good-first-bug removed
  • Milestone changed from Future Release to 4.7
  • Owner set to celloexpressions

This will be fixed in #37661, since all theme information is loaded via Ajax. Removing the panel via remove_panel( 'themes' ) will allow the feature to be disabled without causing any significant performance impacts.

This ticket was mentioned in Slack in #core by helen. View the logs.


3 years ago

#7 @westonruter
3 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 38813:

Customize: Introduce a new experience for discovering, installing, and previewing themes within the customizer.

Unify the theme-browsing and theme-customization experiences by introducing a comprehensive theme browser and installer directly accessible in the customizer. Replaces the customizer theme switcher with a full-screen panel for discovering/browsing and installing themes available on WordPress.org. Themes can now be installed and previewed directly in the customizer without entering the wp-admin context.

For details, see https://make.wordpress.org/core/2016/10/03/feature-proposal-a-new-experience-for-discovering-installing-and-previewing-themes-in-the-customizer/

Fixes #37661, #34843.
Props celloexpressions, folletto, westonruter, karmatosed, afercia.

#8 @celloexpressions
2 years ago

  • Milestone changed from 4.7 to 4.8
  • Resolution fixed deleted
  • Status changed from closed to reopened


This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


2 years ago

This ticket was mentioned in Slack in #core by celloexpressions. View the logs.


2 years ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


2 years ago

#12 @jbpaul17
2 years ago

  • Milestone changed from 4.8 to 4.8.1

Punting to 4.8.1 per today's bug scrub.

#13 @westonruter
23 months ago

  • Milestone changed from 4.8.1 to 4.9

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


19 months ago

#15 @celloexpressions
19 months ago

Noting that this remains fixed by #37661, whenever that is back in trunk. The work there fully modularizes the themes portion of the customizer to use the customize API and only load theme data when required, providing the potentially-substantial performance benefit for all sites (every time the customizer is loaded) that prompted this ticket. That also allows themes to be removed from the customizer via remove_panel(), which is far more appropriate with the API than the menus/widgets filter as alluded to in 3.

#16 @westonruter
19 months ago

  • Priority changed from normal to high

Bumping priority to high for visibility and alignment with 4.9 goals, and given proximity to beta 1 deadline.

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


19 months ago

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


19 months ago

#19 @westonruter
19 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 41648:

Customize: Introduce a new experience for discovering, installing, and previewing themes within the customizer.

Unify the theme-browsing and theme-customization experiences by introducing a comprehensive theme browser and installer directly accessible in the customizer. Replaces the customizer theme switcher with a full-screen panel for discovering/browsing and installing themes available on WordPress.org. Themes can now be installed and previewed directly in the customizer without entering the wp-admin context. Also includes an extensible framework for browsing and installing themes from other sources.

Also includes CSS auto-prefixing added via grunt precommit:css.

For details, see: https://make.wordpress.org/core/2016/10/03/feature-proposal-a-new-experience-for-discovering-installing-and-previewing-themes-in-the-customizer/

Previously [38813] but reverted in [39140].
Fixes #37661, #34843, #38666.
Props celloexpressions, folletto, westonruter, karmatosed, melchoyce, afercia.

#20 @westonruter
19 months ago

As of [41648], themes can now be disabled in the Customizer via:

<?php
add_action( 'customize_register', function( $wp_customize ) {
        $wp_customize->remove_panel( 'themes' );
}, 11 );

#21 @westonruter
19 months ago

In 41649:

Customize: Improve interactions between the Themes panel and Publish Settings section.

  • Deactivate the Themes panel immediately after changing selected status to non-publish.
  • Animate publish settings button into view with publish button when collapsing Themes panel.
  • Deactivate publish settings section and hide publish settings button entirely when customizer state is clean.
  • Harden access of Themes panel in case it was removed by plugin.
  • Fix throttling of renderScreenshots calls in ThemesSection.

Amends [41648], [41626].
See #37661, #39896, #34843.

Note: See TracTickets for help on using tickets.