Skip to content

Site Cloner: Load Customizer assets on block themes - #1758

Merged
pkevan merged 1 commit into
WordPress:productionfrom
wputasic:site-cloner/issue-1315-customizer-assets
Jul 8, 2026
Merged

Site Cloner: Load Customizer assets on block themes#1758
pkevan merged 1 commit into
WordPress:productionfrom
wputasic:site-cloner/issue-1315-customizer-assets

Conversation

@wputasic

@wputasic wputasic commented Jul 3, 2026

Copy link
Copy Markdown
Contributor

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 _wcscSettings localization (REST URL + nonce) only on admin_enqueue_scripts. customize.php never fires that hook itself — on classic themes it fires indirectly, because the Customizer's widgets component calls do_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, and Site_Control::enqueue() silently no-ops on unregistered handles.

Fix: register the assets on customize_controls_enqueue_scripts — the hook customize.php always fires — at priority 1 so registration precedes WP_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:

  1. On a WordCamp site, activate a block theme (e.g. Twenty Twenty-Five).
  2. Go to Appearance → Clone Another WordCamp. Before this change the section is empty — no site list, no search. With it, the list loads and search/filters work.
  3. Pick a site using a classic theme — the Customizer reloads with ?theme=<slug>, previews it, and Publish performs the clone.
  4. Switch back to a classic theme and repeat, to confirm no regression.

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
pkevan merged commit eaf62e7 into WordPress:production Jul 8, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants