Editor: The styles for the media editor modal are not enqueued

[wildworks]

WordPress 7.1 offers a new modal-based media editor. However, I noticed that this modal is not applying the expected styles.

When the Gutenberg plugin is active, build/styles/registry.php is automatically generated, and since wp-media-utils is included in the dependencies for wp-editor, this does not cause any issues.

To avoid depending on the Gutenberg plugin, it is necessary to explicitly add the style handle in core.

[gulamdastgir04]

Test Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/12813

Environment

• WordPress: 7.1-beta4-20260803.112303
• Subdirectory: No
• PHP: 7.4.33
• Server: PHP.wasm
• Database: WP_MySQL_On_SQLite (Server: 8.0.38 / Client: 3.51.0)
• Browser: Chrome 150.0.0.0
• OS: Linux
• Theme: Twenty Twenty-Five 1.5
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.3.0

✅ Patch is solving the problem

[gulamdastgir04]

Before Patch:

[gulamdastgir04]

After Patch:

[softglaze]

Patch Testing Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/12813

Environment

• WordPress: 7.1-beta4-62899-src
• Subdirectory: No
• PHP: 8.3.32
• Server: nginx/1.31.3
• Database: mysqli (Server: 9.7.1 / Client: mysqlnd 8.3.32)
• Browser: Chrome 150.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.5
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.3.0
• Gutenberg: not installed

Trunk tested at be1c69c4c9, PR branch at 489b105139. The version string (7.1-beta4-62899-src) was identical on both trunk and the PR branch, ensuring a clean, same-version comparison.

Steps taken

1. Synced trunk to commit be1c69c4c9 and ran npm run build:dev.
2. Opened post-new.php and checked page source for media-utils. Found 2 matches (both JS), but no stylesheet link was present.
3. Verified the CSS file existed on disk. Found style.css in the media-utils directory (9283 bytes).
4. Fetched upstream pull/12813/head, checked out the PR branch at 489b105139, and rebuilt.
5. Rechecked the page source on post-new.php. Found 4 matches, with wp-media-utils-css successfully enqueued at line 35 (right before wp-editor-css). Verified the same handle appears on site-editor.php and the Network tab shows a 200 OK status serving 9.5 kB.
6. ✅ Patch is solving the problem: The wp-media-utils stylesheet is now registered and enqueued on both the post editor and the site editor, and returns 200.

Expected result

• The media editor modal styles (wp-media-utils) should be correctly registered and loaded inside the editor.

Additional Notes

• The JS handle (wp-media-utils-js) was already enqueued on trunk; only the style handle was missing.
• The CSS file itself was already built and present on disk before the PR, so this issue was purely a registration gap, not a build failure.
• The wp-media-utils-css handle also successfully reaches the Site Editor.

Screenshots with results

Before:

• 65794-before-post-new-source-no-media-utils-css.png​

After:

• 65794-after-post-new-source-media-utils-css.png​
• 65794-after-site-editor-source-media-utils-css.png​
• 65794-after-network-media-utils-css-200.png​
• 65794-after-stylesheet-loads-direct-200.png​

I tested this branch locally at commit 489b105139. The wp-media-utils-css stylesheet is now correctly registered and enqueued on both post-new.php and site-editor.php. The Network tab confirms the file returns a 200 OK status.

[mdridipu]

Before applying the patch (issue reproduced)

[mdridipu]

After applying the patch (issue resolved)

[mdridipu]

Test Report

I tested the proposed fix from PR #12813.

Test Environment
WordPress: 7.1-beta4
PHP: 8.3.
Environment: Local development and playground
Browser: Google Chrome
Theme: Twenty Twenty-Seven
Plugins: None
Testing Process
Set up a clean WordPress 7.1-beta4 installation.
Followed the reproduction steps described in this ticket and successfully reproduced the reported issue.
Applied the changes from PR #12813.
Repeated the same reproduction steps.
Confirmed that the issue was resolved after applying the patch.

I also performed some additional testing around the affected functionality and did not encounter any regressions.

Result

✅ I can confirm that the proposed patch resolves the reported issue and works as expected.

Screenshots attached:

Before applying the patch (issue reproduced)
After applying the patch (issue resolved)

[afercia]

Additionally, the focus style on all form elements in the modal dialog is inconsistent witht he one used in Core, including the classic media dialog.

box-shadow: 0 0 0 0.5px var(--wp-components-color-accent, var(--wp-admin-theme-color, #3858e9))

where the thickness should be 1.5px or 2px depending on the Device Pixel Ratio (DPR). There's a CSS variable for this. It comes from the wp-base-styles package:

@mixin admin-scheme($color-primary) {
	...
	--wp-admin-border-width-focus: 2px;
	@media ( -webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) {
		--wp-admin-border-width-focus: 1.5px;
	}

Usage with fallback:

var(--wp-admin-border-width-focus, 1.5px)

We fixed most of the other inconsistencies in core in #65645 but these in the nee media dialog need to be fixed yet. Probably in Gutenberg.

Note that most Gutenberg form controls focus style is applied to a sibling element of the form control, the so called 'input-control backdrop'.

Also a good one for us to keep in mind if/when we ever roll out the media cropper to other screens in future releases.

OMG thanks for catching this. Easy to forget that core doesn't have Gutenberg's build scripts! For me at any rate 😄

[wildworks]

In 63007:

Media: Register the wp-media-utils style handle.

The media editor modal rendered without its intended styles, because the stylesheet it relies on was never registered in core. Registering the handle makes the modal display as intended.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/12813

Props afercia, andrewserong, gulamdastgir04, mdridipu, ramonopoly, softglaze, wildworks.
Fixes #65794.

[joedolson]

I'm removing the accessibility focus from this ticket, as the focus style issue that @aferica raised was not addressed as part of this ticket.

That issue should be raised again, probably in the Gutenberg repository. @afercia have you already done this? I couldn't find one.