Repository navigation
Interactivity API: Load the script module registry from its current path - #86454
westonruter wants to merge 1 commit into
Conversation
`gutenberg_define_interactivity_modules_support()` marks the block library's script modules as able to load on client-side navigation. It read the registry from `build/modules/index.php`, but acf01a2 (#74490) renamed that file to `build/modules/registry.php` and did not update this caller. Since then, the `file_exists()` check has always failed, and the function has returned without marking anything. This went unnoticed because Core marks the block library modules it registers in `wp_default_script_modules()`, and that mark is kept when Gutenberg registers the modules again. A block library module that only Gutenberg has, though, would not be marked, so it would not be loaded on client-side navigation. Also remove the `remove_action()` call for `wp_define_interactivity_modules_support()`, which Core has never defined. Co-Authored-By: Claude Opus 5.5 (medium effort) <noreply@anthropic.com> Claude-Code-Session-Id: 32212707-a7f1-4bca-bef2-7f3b4982950b
🤖 PR meta 🤖🎉 PropsIf you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. Props Bot commandsYou can trigger Props Bot actions by commenting on this PR:
Updated as activity occurs, without notifying anyone named here. Add the ⚡ PerformanceShow the resultsClient side metrics exclude the server response time. front-end-block-theme
front-end-classic-theme
media-processing
media-upload
post-editor
site-editor
🏁 Flaky testsSome tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information. Page List converts to Navigation Links with entity bindings in
|
What?
Follow up to #74490. Found in #86104.
Fixes the path that
gutenberg_define_interactivity_modules_support()loads the script module registry from, so that it marks the block library's script modules as able to load on client-side navigation again.Why?
The function reads the registry from
build/modules/index.php, but #74490 renamed that file tobuild/modules/registry.phpand did not update this caller. Since then, itsfile_exists()check has always failed, and it has returned without marking anything.This has gone unnoticed because Core marks the block library modules it registers in
wp_default_script_modules(), and that mark is kept when Gutenberg registers the modules again. All 10 of Gutenberg's current block library modules are also in Core, so none are affected today. A block library module that only Gutenberg has, though, would not be marked, so it would not be loaded on client-side navigation.How?
build/modules/registry.php, where wp-build writes it, as the generatedbuild/modules.phpalready does.remove_action( 'wp_default_scripts', 'wp_define_interactivity_modules_support' )call. Core has never defined that function, so the call has never done anything.Testing Instructions
npm run build, and confirm thatbuild/modules/registry.phpexists andbuild/modules/index.phpdoes not.check-registry-path.phpin a directory that WP-CLI can read, and run it withwp eval-file check-registry-path.php(ornpm run wp-env run cli wp eval-file …). It clears the marks that Core added, then runs only Gutenberg's function:Marked: 0. With this PR, it printsMarked: 10, one for each@wordpress/block-library/*/viewmodule.Testing Instructions for Keyboard
Not applicable. There are no UI changes.
Screenshots or screencast
Not applicable.
Use of AI Tools
This PR was written with Claude Code using Claude Opus 5.5 (medium effort), which found the stale path while typing the registry in #86104, traced it to #74490, verified the fix against a local site with WP-CLI, and drafted the change and this description. It was reviewed by a maintainer.