Site Cloner: Load Customizer assets on block themes - #1758
Merged
pkevan merged 1 commit intoJul 8, 2026
Merged
Conversation
The cloner's scripts, styles, and settings were registered only on admin_enqueue_scripts, which customize.php never fires directly. On classic themes it fired indirectly, via the Customizer widgets component's do_action( 'admin_enqueue_scripts', 'widgets.php' ), but since WordPress 5.9 the widgets component is not loaded when a block theme is active, so the Clone Another WordCamp section rendered with no JavaScript: no site list, no search, and no way to clone anything. Registering the assets on customize_controls_enqueue_scripts -- the hook customize.php always fires, at priority 1 so it precedes WP_Customize_Manager::enqueue_control_scripts() -- restores the full cloning flow regardless of the active theme. The assets are only consumed inside the Customizer, so registering them on every admin page was unnecessary anyway. See WordPress#1315.
pkevan
approved these changes
Jul 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The "Clone Another WordCamp" screen renders as a dead shell whenever the active theme is a block theme: the section appears in the Customizer, but the site list never loads and search/filtering does nothing — no PHP or JS error anywhere. Since new WordCamp sites default to
twentytwentyfour, every new organizer hits this. These are breakages 1 and 3 in #1315.Root cause: the plugin registers its Customizer JS/CSS and the
_wcscSettingslocalization (REST URL + nonce) only onadmin_enqueue_scripts.customize.phpnever fires that hook itself — on classic themes it fires indirectly, because the Customizer'swidgetscomponent callsdo_action( 'admin_enqueue_scripts', 'widgets.php' ). Since WordPress 5.9, the widgets component is not loaded when a block theme is active, so that indirect path disappears,register_scripts()never runs, andSite_Control::enqueue()silently no-ops on unregistered handles.Fix: register the assets on
customize_controls_enqueue_scripts— the hookcustomize.phpalways fires — at priority 1 so registration precedesWP_Customize_Manager::enqueue_control_scripts(). The assets are only consumed inside the Customizer, so registering them on every admin page was unnecessary anyway.This restores cloning any classic-theme site regardless of the active theme. It deliberately does not address breakage 2 in #1315 (block-theme sites as clone sources) — that needs a larger rework, since a block-theme site's design lives in global styles/templates that the cloner's theme-switch + Additional-CSS payload doesn't capture.
See #1315.
Props dd32 (report & triage).
Screenshots
Before: the empty "Clone Another WordCamp" section shown in #1315. After the change, the site list, search, and filters render as they do on classic themes.
How to test the changes in this Pull Request:
?theme=<slug>, previews it, and Publish performs the clone.