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

[mattwiebe]

#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.

[westonruter]

@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.

[westonruter]

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 :-)

[nacin]

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.

[mattwiebe]

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.

[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.

[westonruter]

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.

[jbpaul17]

Punting to 4.8.1 per today's bug scrub.

[celloexpressions]

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.

[westonruter]

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

[westonruter]

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.

[westonruter]

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 );

[westonruter]

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.