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
• Introduce a new patch restoring truthy media upload fallback value removed in 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.

---

Agent summary

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) added a null guard to getUserPermissionsFromAllowHeader. Before it, a missing Allow header threw, the canUser resolver hit failResolution, and canUser stayed undefined. After it, the same case resolves to false.

That matters because @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 — only "Insert from URL" survives.

The header is unreadable because the editor is cross-origin to the REST API. 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. Verified on both wp-env and the namespaced API, which sends allow: GET and withholds it from JS.

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.

Which surfaces are affected

Surface	Editor origin	Cross-origin?	Media upload
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

So one production segment plus every local-dev flow. iOS only gets the CORS bypass on the bundled file:// load; pointed at Vite it takes the webView.load( URLRequest( url: ) ) branch, where the bypass does not apply.

Three mechanics that constrain any fix

• Returning early from a resolver is safe. @wordpress/data wraps resolvers in startResolution → finishResolution (redux-store/index.mjs:436-444), so an early return still finishes the resolution and canUser stays undefined with no retry loop. Throwing instead hits failResolution, which is what 7.41.0 did — restoring that breaks the post title rather than fixing upload.
• Seeding state alone does not work. Populating state via receiveUserPermissions does not stop the resolver from running and overwriting with false; it also needs finishResolutions with upstream's exact args shape.
• Only the no-information case is broken. iOS bundled and Android self-hosted read Allow correctly and get real permissions. A fix must preserve that.

Options considered

	Fixes namespaced Android	Fixes local dev + E2E	Correctness	Cost	Fails loudly if upstream moves
1. Patch core-data (chosen)	🟢 Yes	🟢 Yes	🔴 Assumes true1	~10 lines	🟢 Yes, at npm ci
2a. Seed true from GutenbergKit	🟢 Yes	🟢 Yes	🔴 Assumes true1	Small	🔴 No, silent
2b. Seed from users/me capabilities	🟢 Yes	🟢 Yes	🟡 Real, global capability2	Medium	🔴 No, silent
#462. Seed from host-supplied capabilities	🟢 Yes	🟢 Yes	🟡 Real, global capability2	Large, breaking	🔴 No, silent
3. Expose Allow server-side	🟢 Yes	🔴 No	🟢 Real, exact resource3	1 line, not this repo	n/a
4. Relay request through native proxy	🟢 Yes	🔴 No	🟢 Real, exact resource3	Large	n/a
5. Vite dev proxy	🔴 No	🟢 Yes	🟢 Real, exact resource3	Small	n/a
6. Upstream Gutenberg PR	🟡 Yes, eventually	🟡 Yes, eventually	🔴 Assumes true1	Small + release cycle	n/a
7. Hold the bump	n/a	n/a	n/a	Indefinite freeze	n/a

1. Patch @wordpress/core-data — chosen. Return early when Allow is unreadable, so absent means unknown rather than denied and ?? true applies again. Surgical: it only changes behaviour where there is no information, so real permissions still win same-origin. Fixes every affected surface with no application code. The cost is an eighth patch, and an optimistic default — a Contributor on a namespaced site gets an Upload button that fails on use, which is the pre-7.42 status quo rather than a new regression. It is removed when 6 or #462 lands, not maintained indefinitely.

2/#462. Seed permissions into the store. #462 is the strongest form: the host fetches capabilities via GET /wp/v2/users/me?context=edit&_fields=capabilities outside the browser and passes them over the existing window.GBKit bridge, with the parameter required so no host silently regresses. Correct where option 1 is merely optimistic. Deferred rather than dropped: it is a breaking change across both native SDKs, demo apps and docs (+605/−104 over 26 files), currently a five-month-stale conflicting draft built against editor 14.44, and folding an API break into a 52-package bump would make this un-reviewable. It also depends on two undocumented internals — the create/postType/attachment cache key and canUser's args shape — and its tests fully mock @wordpress/data and @wordpress/core-data while asserting those as literals, so upstream drift would leave them green. Worth adding a test against a real registry when it is rebased.

3. Expose Allow server-side. Strictly better than 1 or 2 for correctness, since it restores real permissions instead of a default, and realistic on the namespaced API where those headers are already customised. Does nothing for local dev, E2E or self-hosted cross-origin, and WP core would take years to propagate. A follow-up, not a stopgap.

4. Relay request through native proxy. The host performs the OPTIONS request outside the browser, where CORS does not apply, and hands back the real Allow header. Unlike #462 it answers per resource on demand rather than pushing a fixed capability list up front, so it covers every canUser call and stays accurate for object-scoped checks. The cost is new runtime machinery — an async request path and auth relay, generalising the loopback server that today only forwards media uploads — plus host adoption on both platforms, and it does nothing for the web dev server. Dropped as far too large for a dependency bump.

5. Vite dev proxy. Dropped as actively harmful: it would make local dev same-origin and mask the one real production regression, so nobody could reproduce the namespaced-Android bug locally. It fixes nothing in production.

7. Hold the bump. Not available. block-library@11, editor@15, edit-post, patterns, widgets and media-utils all require core-data@^8, and pinning 7.x reintroduces the duplicate installs check-wp-packages forbids. Holding means holding all 52 packages indefinitely, and the pre-7.42 behaviour was a crash rather than a working state.

Follow-ups

• Upstream the canUser change to Gutenberg (option 6), then delete the patch.
• Rebase feat!: seed user capabilities from host to avoid cross-origin canUser regression #462 (option 2b) as the durable fix, with a test against a real core-data registry.
• Ask for Allow in Access-Control-Expose-Headers on the namespaced API (option 3).
• feat!: seed user capabilities from host to avoid cross-origin canUser regression #462 also extends the wp-env CORS mu-plugin to expose Allow locally. The OPTIONS routing there is worth keeping — real WordPress answers OPTIONS through WP_REST_Server while the Playground runtime short-circuits it to a 204 — but exposing Allow makes local diverge from production and would mask this class of bug.

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 (8 patches apply), make build, make dev-server, make lint-js, make test-js, make check-wp-packages, make test-e2e.

🤖 Generated with Claude Code

Footnotes

1. Source of truth: none. The editor assumes permission when it cannot determine one, matching the behaviour that shipped before core-data@7.42.0. ↩ ↩² ↩³

2. Source of truth: capabilities.upload_files from GET /wp/v2/users/me?context=edit — a site-wide user capability. ↩ ↩²

3. Source of truth: the REST Allow header, which WordPress computes per request from that endpoint's permission_callback, so it can reflect per-object rules. ↩ ↩² ↩³

[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 c2c0a8a}

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