Loading, Rendering, And Data
schema_version: 1 id: developer-script-modules-loading-rendering-and-data slug: /developer/script-modules/loading-rendering-and-data/ title: Loading, Rendering, And Data section: Developer topic: Script Modules audience: plugin, theme, and block developers status: source-backed-draft review_state: needs-human-review source_set: script-modules-pilot source_commit: 58f02a0278b49f35436ecd14a73a9701f1a115ef source_paths:
- src/wp-includes/class-wp-script-modules.php
generated_by: technical-docs-agent-compatible pilot slice
generation_note: Prepared from source-backed page specs; not a full WP Codebox runtime corpus run.
generated_at: 2026-06-16T16:38:25Z
nav:
label: Loading, Rendering, And Data
parent: /developer/script-modules/
order: 40
search:
weight: 0.8
keywords:
- wp-importmap
- script_module_data
- translations
- fetchpriority
WP_Script_Modules attaches rendering callbacks to WordPress hooks. The hook placement depends on the theme type because block themes know more about the rendered block template earlier than classic themes do.
Import Maps And Module Scripts
WordPress prints import maps with an inline script tag using type="importmap" and the ID wp-importmap. Enqueued modules are printed as script tags with type="module" and an ID based on the module identifier.
The import map includes registered dependencies that need identifier-to-URL mappings. Enqueued modules themselves are printed as module scripts instead of import-map entries.
Preloads
WordPress prints rel="modulepreload" links for static dependencies of enqueued modules. A module that is directly enqueued is not also preloaded.
Fetch priority is calculated from the enqueued dependents. If the resolved priority is not auto, WordPress prints a fetchpriority attribute. If the printed priority differs from the module’s own priority, WordPress also prints data-wp-fetchpriority.
Block Themes And Classic Themes
In block themes, WordPress can print import maps and eligible head modules in wp_head. Modules marked for footer output are still printed in the footer.
In classic themes, modules used by rendered blocks may not be known when wp_head runs. WordPress therefore prints the import map, preloads, and enqueued modules in the footer for the frontend classic-theme path.
Module Data
Use the script_module_data_{$module_id} filter to attach essential initialization data to a module. If the filter returns a non-empty array, WordPress serializes it into a JSON script tag whose ID is wp-script-module-data-{$module_id}.
add_filter( 'script_module_data_my-plugin/view', function ( array $data ): array {
$data['restUrl'] = esc_url_raw( rest_url() );
return $data;
} );Client code can read that JSON by ID and parse it before initializing the module.
Translations
Script Module translations are printed before modules execute. WordPress can auto-detect the default text domain and path from the module source URL. Use wp_set_script_module_translations() when the module uses a non-default text domain or a custom translations path.
wp_set_script_module_translations(
'my-plugin/view',
'my-plugin',
plugin_dir_path( __FILE__ ) . 'languages'
);