Summary
On WordPress 7.0, the new script-module admin screens (Appearance → Fonts / font-library.php and Settings → Connectors / options-connectors.php) render as a blank white page in Firefox when Flynt is active. There is no visible error — the screen is simply empty.
The console shows:
Import maps are not allowed after a module load or preload has started.
Uncaught (in promise) TypeError: The specifier "@wordpress/boot" was a bare specifier,
but was not remapped to anything.
Root cause
Flynt enqueues its own bundles as ES modules in the document <head>:
inc/assets.php enqueues Flynt/assets/main and Flynt/assets/admin without the $in_footer argument (so they print in <head>):
wp_enqueue_script('Flynt/assets/main', Asset::requireUrl('assets/main.js'), [], null);
wp_script_add_data('Flynt/assets/main', 'module', true);lib/Utils/ScriptAndStyleLoader.php then rewrites the tag to type="module".
Since WordPress 7.0, core prints an import map in the footer (WP_Script_Modules::print_import_map, hooked to admin_print_footer_scripts at priority 9) for admin screens built with script modules. Per the HTML spec, an import map must be declared before any module load or preload starts. Because Flynt's module is already in <head>, module loading has begun by the time core prints the map, so the browser discards it.
Firefox enforces this strictly: with the map discarded, core's import("@wordpress/boot") can no longer resolve the bare specifier, the React app never mounts, and the screen's own critical CSS (which hides the classic admin markup) leaves a blank page.
Chromium currently tolerates a map that appears after module loading has begun, which is why the same screens work in Chrome/Edge today. The markup is nevertheless invalid, and relying on that leniency is fragile.
Steps to reproduce
- WordPress 7.0.x with any block or classic theme running Flynt (reproduced against current
master).
- Open Appearance → Fonts (or Settings → Connectors) in Firefox.
- The screen renders blank. Open DevTools → Console to see the two messages above.
Expected vs actual
- Expected: the Font Library / Connectors screens render normally, as they do without Flynt.
- Actual: blank page in Firefox; no visible error to the admin user.
Proposed fix
Print the theme's module bundles in the footer, after core's import map, by passing $in_footer = true. Module scripts are deferred until after parsing regardless, so moving them to the footer does not change their execution semantics:
// inc/assets.php
wp_enqueue_script('Flynt/assets/main', Asset::requireUrl('assets/main.js'), [], null, true);
// ...
wp_enqueue_script('Flynt/assets/admin', Asset::requireUrl('assets/admin.js'), [], null, true);This also protects the front end: the same <head> module pattern will break there as soon as any block using the Interactivity API (which also emits an import map) is present on the page.
Notes
Summary
On WordPress 7.0, the new script-module admin screens (Appearance → Fonts /
font-library.phpand Settings → Connectors /options-connectors.php) render as a blank white page in Firefox when Flynt is active. There is no visible error — the screen is simply empty.The console shows:
Root cause
Flynt enqueues its own bundles as ES modules in the document
<head>:inc/assets.phpenqueuesFlynt/assets/mainandFlynt/assets/adminwithout the$in_footerargument (so they print in<head>):lib/Utils/ScriptAndStyleLoader.phpthen rewrites the tag totype="module".Since WordPress 7.0, core prints an import map in the footer (
WP_Script_Modules::print_import_map, hooked toadmin_print_footer_scriptsat priority 9) for admin screens built with script modules. Per the HTML spec, an import map must be declared before any module load or preload starts. Because Flynt's module is already in<head>, module loading has begun by the time core prints the map, so the browser discards it.Firefox enforces this strictly: with the map discarded, core's
import("@wordpress/boot")can no longer resolve the bare specifier, the React app never mounts, and the screen's own critical CSS (which hides the classic admin markup) leaves a blank page.Chromium currently tolerates a map that appears after module loading has begun, which is why the same screens work in Chrome/Edge today. The markup is nevertheless invalid, and relying on that leniency is fragile.
Steps to reproduce
master).Expected vs actual
Proposed fix
Print the theme's module bundles in the footer, after core's import map, by passing
$in_footer = true. Module scripts are deferred until after parsing regardless, so moving them to the footer does not change their execution semantics:This also protects the front end: the same
<head>module pattern will break there as soon as any block using the Interactivity API (which also emits an import map) is present on the page.Notes