Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
When using inline blocks in Layout Builder for GraphQL to create draft versions of content the draft version of a block returns null. This causes a query error.
When you load a node using the latest revision parameter you get the correct node revision, you even get the correct block configuration revision, however when you try to load the block content it fails.
After deep diving and trying to track this down it looks like it comes from the BlockContentEntityLoad.php class.
$access = $entity->access('view', NULL, TRUE);
That access check returns forbidden because the parent entity isn't in the access context.
The current entity (node) is part of the layout_builder_contexts but that isn't added to the block entity prior to the access check.
Steps to reproduce
Use GraphQL compose with Layout Builder to create content on nodes.
Use node revisions workflow.
Add a node with a block on it and publish.
Update the node and update the block in the node and set to Draft.
Query that route using the "latest" revision parameter.
Proposed resolution
Get the current node/entity from context.
Add that to the block entity as an access dependency.
Remaining tasks
Create MR with fix.
User interface changes
none
API changes
draft blocks return draft content
Data model changes
none
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | screencapture_20251106-144757.png | 125.72 KB | jlockhart |
| screencapture_20251106-143718.png | 96.58 KB | jlockhart |
Issue fork graphql_compose-3556558
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
jlockhartAfter getting the context and adding the access dependency this is what the feed looks like.
Comment #6
almunningsOk, so no troubles with the approach.
The class moved in 11.2 which gives me a nice ugly block of code in the 3.x release
Question now is around access.
Replacing the block's access with the parent entities access for any block_content could be an issue? Perhaps if blocks are conditionally accessible. Do we need to check for edit access to the parent, instead of view access?
Comment #7
jlockhartThanks for updating this.
I'm definitely not an expert on this but...
As I understand it that access check is specifically for things like layout builder inline blocks where their visibility is depended on the users access to the parent entity/node. The check(s) above that should limit this to layout builder inline blocks only, rather than reusable/standard blocks.
Certainly worth testing that though.
Comment #8
almunningsYeah that looks legit.
The same pattern can be seen in
web/core/modules/layout_builder/src/EventSubscriber/BlockComponentRenderArray.phponBuildRenderIt's got the same block of functionality for setAccessDependency on the parent.
I'm happy with this, will merge to v3
Comment #11
almunningsRebased the 2.4.x to CI updates, and added the 11.2 deprecation check.
Comment #12
almunningsThrowing back to you for review on 2.4.x
If it works, its merged
Comment #13
almunnings