Repository navigation
Pattern block: Loading a pattern the user can't edit starts with a refused request #84668
Description
Description
core/block renders a synced pattern from its edit context record (via useEntityBlockEditor). The blocks controller only allows the edit context to users who can edit the pattern. Everyone else, like an author using an administrator's pattern, gets a 403, and since #84641 the block falls back to the view record.
That works, but it costs a refused request before every read-only pattern loads, and it keeps the same pattern in two separate caches.
Using the view record for everyone doesn't work either. core-data caches view records separately and doesn't update them when the edit record changes or saves. I tested it in #84661 (comment). After "Edit original", the post kept showing the old content until a reload, saved or not.
@Mamaduka suggested fixing this at the controller level, so core/block can load what it needs with one request for every user.
Step-by-step reproduction instructions
- As an administrator, create a synced pattern.
- As an author, open a post that uses it.
- In the network panel,
GET /wp/v2/blocks/<id>?context=editreturns a 403 beforecontext=viewloads the pattern.
Environment info
- WordPress 7.1.3
- Gutenberg trunk (with Patterns: Let users load synced patterns they can't edit, without "Edit original" #84641)
Activity
ishitaj34 commentedon Oct 14, 2026
@fabiankaegy I’ve implemented a controller-level fix for the 403 requests, allowing read access in the
editcontext while preserving update/delete permissions. On the client side, I’ve removed thereadOnlyRecord/isUnavailableToEditfallback and extra parsing socore/blockloads records in a single request. Added tests for permissions and 403 requests.I’ll open a PR if this approach looks good!
talldan commentedon Oct 15, 2026
It's hard to say if the PR looks good without a PR TBH, so I'd say go ahead and make one. However, I know @Mamaduka also mentioned they might look into this (#84661 (comment)).
I was thinking through a possible alternative though. Whether we could make the block use
viewby default, and only load the edited version if there are entity edits. I think checking for the presence of entity edits would be a synchronous check, and also the edited entity record should already be loaded in the cache if it was edited, so possibly this would lead to no loading spinners again, and it would only require local block changes.Mamaduka commentedon Oct 15, 2026
Looking at #84799, it seems like a good idea.