Script Loader: Resolve the global script modules instance in hook callbacks

[sirreal]

WP_Script_Modules::add_hooks() registers array( $this, 'method' ), so the print callbacks are bound to the instance that was the global on after_setup_theme. Replacing $wp_script_modules later changes what enqueues but not what prints. Scripts and styles use procedural callbacks that read the global at run time.

This adds procedural print functions to script-modules.php and registers those instead. Hook names, priorities, and the instance methods are unchanged.

Test: register the hooks, replace the global, enqueue a module, fire admin_print_footer_scripts. Fails on trunk with empty output.

Compatibility: remove_action() with the instance callback no longer matches. AMP does this in includes/class-amp-theme-support.php.

Trac ticket: https://core.trac.wordpress.org/ticket/66100

Follow-up to r57503.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Fable 5.1, Claude Opus
Used for: code, test, description.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

🤖 Generated with Claude Code

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props jonsurrell, westonruter.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[westonruter]

I have concerns about this:

Compatibility: remove_action() with the instance callback no longer matches. AMP does this in includes/class-amp-theme-support.php.

In addition to the AMP plugin removing these, this is also done by 3 other plugins, with atum-stock-manager-for-woocommerce (10K+ active installs) seeming being the most concerning: https://veloria.dev/search/5536fd24-0f42-484b-8b24-813e03b952be

In searching GitHub, I also see this would seem to break some Jetpack code: https://github.com/Automattic/jetpack/blob/fc6b865fe09ea7b407925c7e66757f7dd7c4dcf7/projects/packages/jetpack-mu-wpcom/src/features/wpcom-blocks/code/class-code-block.php#L587-L634

This also would break some old Gutenberg compat code which is no longer shipping: https://github.com/WordPress/gutenberg/blob/497e846fe0f157daf97912d95c860558de495574/lib/compat/wordpress-6.7/script-modules.php#L92-L104

It would also break this plugin from PEW Research: https://github.com/pewresearch/prc-print-engine/blob/8f927a2af9b991987c5990ee5cabaaa1062e3dac/includes/class-print-engine.php#L589-L612

I fear the back-compat breakage could be too great.

---

While not related to the compat question, these lines of code in Gutenberg would eventually need to be updated as well:

// Print import map first so it's available for inline scripts
wp_script_modules()->print_import_map();
print_footer_scripts();
wp_script_modules()->print_enqueued_script_modules();
wp_script_modules()->print_script_module_preloads();
wp_script_modules()->print_script_module_data();

These will continue to work as-is in the mean time.

[sirreal]

This was motivated by #13507 originally. That work no longer depends on this change so I don't have a pressing need to land this.

Edited mal-formed comment

However, this is a correctness issue. The change in r57503 does not have the desired impact. This function now returns the global $wp_script_modules:

wordpress-develop/src/wp-includes/script-modules.php

Lines 23 to 31 in 88f2c9e

	function wp_script_modules(): WP_Script_Modules {
	global $wp_script_modules;
	if ( ! ( $wp_script_modules instanceof WP_Script_Modules ) ) {
	$wp_script_modules = new WP_Script_Modules();
	}
	return $wp_script_modules;
	}

But changing the global has no impact because the hooks are instance methods and fun for whatever instance was called when the filter was registered:

wordpress-develop/src/wp-settings.php

Line 460 in 88f2c9e

add_action( 'after_setup_theme', array( wp_script_modules(), 'add_hooks' ) );

wordpress-develop/src/wp-includes/class-wp-script-modules.php

Lines 436 to 466 in 88f2c9e

	add_action( $position, array( $this, 'print_import_map' ) );
	if ( $is_block_theme ) {
	/*
	* Modules can only be printed in the head for block themes because only with
	* block themes will import map be fully populated by modules discovered by
	* rendering the block template. In classic themes, modules are enqueued during
	* template rendering, thus the import map must be printed in the footer,
	* followed by all enqueued modules.
	*/
	add_action( 'wp_head', array( $this, 'print_head_enqueued_script_modules' ) );
	}
	add_action( 'wp_footer', array( $this, 'print_enqueued_script_modules' ) );
	add_action( $position, array( $this, 'print_script_module_preloads' ) );
	add_action( 'admin_print_footer_scripts', array( $this, 'print_import_map' ), 9 );
	add_action( 'admin_print_footer_scripts', array( $this, 'print_enqueued_script_modules' ) );
	add_action( 'admin_print_footer_scripts', array( $this, 'print_script_module_preloads' ) );
	/*
	* Print translations after classic scripts like wp-i18n are loaded (at
	* priority 10 via _wp_footer_scripts), but before the script modules
	* execute. Script modules with type="module" are deferred by default,
	* so inline translation scripts at priority 11 will execute before them.
	*/
	add_action( 'wp_footer', array( $this, 'print_script_module_translations' ), 21 );
	add_action( 'admin_print_footer_scripts', array( $this, 'print_script_module_translations' ), 11 );
	add_action( 'wp_footer', array( $this, 'print_script_module_data' ) );
	add_action( 'admin_print_footer_scripts', array( $this, 'print_script_module_data' ) );
	add_action( 'wp_footer', array( $this, 'print_a11y_script_module_html' ), 20 );
	add_action( 'admin_print_footer_scripts', array( $this, 'print_a11y_script_module_html' ), 20 );

The demo looks something like this:

function f() {
  global $wp_script_modules;
  
  // Update global, as a plugin doing this pattern would.
  $wp_script_modules = new WP_Script_Modules();
  $wp_script_modules->enqueue(
    'example',
    plugins_url( 'example.mjs', __FILE__ ),
    array(),
    '1.0'
  );
  
  var_dump( wp_script_modules() === $wp_script_modules ); // bool(true)
  var_dump( $wp_script_modules->get_queue()[0] );         // string(7) "example"
  
  echo "\nFirst footer, no modules are printed:\n";
  do_action( 'wp_footer' );
  
  echo "\nFooter with new global's hooks registered:\n";
  $wp_script_modules->add_hooks();
  do_action( 'wp_footer' ); // <script id="example-js-module" …
}

I do share the back-compat concerns, but I'm also worried that this is a bug where the global can be modified but that doesn't actually do anything.

[westonruter]

The change in r57503 does not have the desired impact because if the

Because of the what?

[sirreal]

Sorry, I've corrected the updated comment. In short, the global value can be replaced but it doesn't change relevant behavior because script module hooks are registered with whatever instance was used at the after_setup_theme action that registers the hooks.

See my updated comment for full details.

[sirreal]

There are a number of alternatives I've been considering, none of which I like. For example, the hook methods could perform the expected action if it's the global instance, or invoke the global instance otherwise. This seems like it would address back-compat and the problem of not running the actions on the new global, but it also seems messy and surprising.