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'.