build(deps): bump the @wordpress group to one Gutenberg release

[dcalhoun]

What?

Update the @wordpress dependencies group to the latest releases.

Why?

These dependencies have been stale for several months, missing out on the latest features and bug fixes.

How?

• Bump the @wordpress dependency versions
• Regenerate patch-package files
• Drop the @wordpress/rich-text patch fixed in WordPress/gutenberg#82598
• Fix background color E2E test query to match UI change
• Add an apiFetch middleware restoring the media Allow header browsers hide cross-origin, which canUser reads as denied since WordPress/gutenberg#76307

Testing Instructions

Given the numerous dependency updates, it's worth regression testing the editor in a broad manner.

Accessibility Testing Instructions

General regression testing editor navigating with screen readers.

Screenshots or screencast

N/A, no user-facing changes.

---

AI-generated details

Supersedes #661. That branch is Dependabot's; this one carries enough of our own work that it should be reviewed as ours.

Why the group had to move together

Dependabot bumped most of the group to the 55.0-era release but left element (6.46.0), compose (7.46.0), blocks (15.27.0) and core-data (7.54.0) on their previous majors. Every bumped package asks for element@^8.7.0, compose@^8.8.0, blocks@^16.0.0 and core-data@^8.0.0, so npm nested a second copy of each under 90 dependents — 36 copies of element alone. That is the split make check-wp-packages exists to catch.

core-data@7.54.0 was also what pinned icons at ^15.5.0, so the KNOWN_DUPLICATES allowance retired itself on its own terms: its comment already said it resolves once the packages move together.

The missing Upload button

@wordpress/core-data 7.42.0 (Gutenberg #76307) made getUserPermissionsFromAllowHeader return false for every action when the Allow header is missing. Before, it returned {}, so canUser stayed undefined.

@wordpress/editor reads hasUploadPermissions: canUser( 'create', { kind: 'postType', name: 'attachment' } ) ?? true. false does not fall through ??, so settings.mediaUpload becomes undefined and the Upload and Media Library buttons disappear from every MediaPlaceholder.

The header is missing because the editor is cross-origin to the REST API on some surfaces. A browser hides response headers the site does not name in Access-Control-Expose-Headers, and WordPress names only X-WP-Total, X-WP-TotalPages and Link.

This has blocked the whole @wordpress stream since April: #459, #506 and #538 (core-data), #537 (editor), #535 (compose), #508 and #536 (html-entities) and #539 (token-list) were all closed unmerged. The 52-package, 8-major size of this bump is that backlog.

Surface	Editor origin	Cross-origin?	Upload without a fix
iOS, bundled	file:// with allowUniversalAccessFromFileURLs	🟢 CORS bypassed	🟢 OK
iOS, Vite dev server	http://localhost:5173	🔴 Yes	🔴 Broken
Android, self-hosted with application password	https://<site-host>/assets/	🟢 No	🟢 OK
Android, namespaced sites	https://<site-host>/assets/	🔴 Yes	🔴 Broken
Android, Vite dev server	http://localhost:5173	🔴 Yes	🔴 Broken
Web E2E / make dev-server	localhost:5173	🔴 Yes	🔴 Broken

The fix

mediaPermissionsMiddleware in src/utils/api-fetch.js fills in Allow: GET, POST on OPTIONS /wp/v2/media, only when the header is missing. WordPress always allows GET on that collection, so a missing header there means the browser hid it, and same-origin responses pass through untouched. Every other permission check keeps core-data's own semantics.

This replaces a core-data patch that made the canUser resolver return early whenever Allow was unreadable. Review showed why the narrower fix is better:

• The patch did not make "missing means unknown" hold: getEntityRecord still writes false, and same-origin a missing header genuinely means "nothing permitted" (rest_send_allow_header() omits it only then).
• Only hasUploadPermissions needs undefined. The two strict checks in the bundled packages are better served by false: the global styles hook waits for typeof === 'boolean', and Post Content renders nothing while === undefined.
• Upstream is converging on canUser always settling to a boolean (#76307, #82638), and #82638 stops the patch applying. The middleware relies only on canUser sending OPTIONS and reading Allow, which has held since 2018.

Behaviour compared with trunk

• Upload: unchanged optimistic default. On cross-origin surfaces, a user without upload_files sees an Upload button that fails on use.
• Global Styles data, cross-origin: now loads, matching same-origin surfaces. It reaches the Gallery gap calculation, one-axis layout gap fallbacks, per-block style variation CSS and inspector inherited values. The canvas stylesheet still comes from the host's editorSettings.
• Post Content block: renders read-only content instead of nothing where entity permissions are unreadable.

Options considered

	Namespaced Android	Local dev + E2E	Source of truth	Depends on
apiFetch middleware (chosen)	🟢	🟢	None, assumes upload	Public middleware and REST Allow contract
Patch core-data (replaced)	🟢	🟢	None, assumes upload	Resolver internals; reverses #76307 everywhere
Seed the store (incl. #462)	🟢	🟡 #462 needs a host	Global upload_files	Store keys and resolution args (#82638 changed them)
Preload OPTIONS /wp/v2/media with Allow	🟢	🔴	Real, per request	Public preloading contract; host fetch
Expose Allow server-side	🟢	🔴	Real, per request	Server change outside this repo
Relay OPTIONS through the native proxy	🟢	🔴	Real, per request	New runtime machinery on both platforms
Vite dev proxy	🔴	🟢	Real, per request	Masks the production bug locally
Hold the bump	n/a	n/a	n/a	Not viable: core-data@^8 is required by 6+ packages

Follow-ups

• Preload OPTIONS /wp/v2/media natively and keep Allow in preloaded headers, as core's editor does (wp-admin/edit-form-blocks.php). Both platforms currently keep only Accept and Link. This gives real per-user upload permission on app surfaces through a public contract, and supersedes feat!: seed user capabilities from host to avoid cross-origin canUser regression #462's store seeding. First confirm what the namespaced API returns for an authenticated native OPTIONS /media.
• If feat!: seed user capabilities from host to avoid cross-origin canUser regression #462 continues, its finishResolutions( 'canUser', … ) args no longer match core-data after #82638.
• Ask for Allow in Access-Control-Expose-Headers on the namespaced API, with the same check first.

Other changes in this branch

• Four patches regenerated. Inserter became a forwardRef function component upstream, so the open/popoverProps passthrough reads from the destructured parameter list rather than this.props.
• The @wordpress/rich-text patch is deleted: preventFocusCapture now subscribes pointercancel to its pointerup handler upstream.
• color-gradient.spec.js selector updated. The colour controls moved into a tools panel headed "Background" where the control is labelled "Color", the same label the text colour control carries, so the old substring match reached the panel's options menu instead.

Verification

make npm-dependencies REFRESH_DEPS=1 (7 patches apply), make lint-js-fix, make test-js, make check-wp-packages, make test-e2e (49 passed; an earlier run had four upload specs time out against Playground and pass on rerun). With the middleware unregistered, the image upload E2E fails with no Upload button.

🤖 Generated with Claude Code

[wpmobilebot]

XCFramework Build

This PR's XCFramework is available for testing. Add the following to your Package.swift:

.package(url: "https://github.com/wordpress-mobile/GutenbergKit", branch: "pr-build/691")

_{Built from 9df95a9}

[dcalhoun]

Noting that the patch files can be difficult to understand when viewing the diff. It can be worthwhile to view and compare the actual file before and after in separate tabs.

[adalpari]

Generally looks good to me. Claude raised these "medium" points you might want to have a look:

#	Severity	File	Finding
1	Medium	patches/@wordpress+core-data+8.0.0.patch:17	The patch guards only the canUser resolver. getEntityRecord (resolvers.mjs:79) reads the same Allow header and unconditionally dispatches receiveUserPermissions with all-false plus finishResolutions('canUser', …), so entity-scoped canUser still reports denied cross-origin and the patched resolver can't correct it. getUserPermissionCacheKey's .filter(Boolean) makes getEntityRecord('root','site')'s empty key collapse onto the exact keys canUser('*', {kind:'root',name:'site'}) reads. No visible breakage today (consumers use truthiness; the only ?? true consumer, hasUploadPermissions, has no id in its key), but the "absence means unknown" invariant the patch claims does not hold.
2	Medium	patches/@wordpress+core-data+8.0.0.patch:17	!allowedMethods conflates "header hidden by CORS" with "WordPress sent no Allow because the user is permitted nothing" — rest_send_allow_header() only emits the header when $allowed_methods is non-empty. This flips genuine denials to unknown on the same-origin surfaces the PR marks as keeping real permissions; the README wording ("a response whose header it cannot read") understates it.

[dcalhoun]

Generally looks good to me. Claude raised these "medium" points you might want to have a look:

Thanks for sharing these, @adalpari. I researched and both were right. It seems they would not have significant user impact now, but it's worth addressing.

I addressed both by replacing the patch with a middleware (93f81ae, 9df95a9). An added benefit: this helps us avoid adding yet another patch, which improves maintainability.

---

AI-generated details

1. getEntityRecord still writes false. Correct. The patch only covered the canUser resolver, so "missing means unknown" didn't hold.
2. A missing Allow also means "nothing permitted". Also correct. rest_send_allow_header() omits it when every permission check fails, which is the case #76307 set out to fix.

Tracing the consumers showed only hasUploadPermissions (?? true) needs undefined. The two strict checks in the packages we bundle, the global styles hook (typeof === 'boolean') and Post Content (=== undefined), both work better with false. Upstream is also moving towards canUser always settling to a boolean (WordPress/gutenberg#82638), and that change stops the patch applying anyway.

So I replaced the patch with an apiFetch middleware that fills in Allow: GET, POST on OPTIONS /wp/v2/media, only when the header is missing (93f81ae, 9df95a9). WordPress always allows GET on that collection, so a missing header there means the browser hid it. Every other permission check keeps core-data's own semantics, so neither finding applies any more. The description has the details and follow-ups.