The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
BlockContent entities are now publishable (https://www.drupal.org/project/drupal/issues/2820848) but the permission used to allow viewing unpublished blocks is the administer block content or access block library permissions.
When used with Content Moderation, block_content entities can be created as inline (for use in Layout builder) or reusable (via the block content library) as unpublished (this will be expanded without CM in #2834546: UI for publishing/unpublishing block_content blocks). If a user creates a Draft block, any editors without the administer block content or access block library permissions will be unable to view the block that is placed via a block plugin or inline block in Layout builder.
e.g an editor that doesn't have those permissions but has create and edit custom blocks will be able to place reusable blocks in LB but won't be able to view them if they are draft.
Node has a similar permission to view (own) unpublished content
Steps to reproduce
Create unpublished block
Unable to view unless the user has administer block content or access block library permissions
The user must also not have the view any unpublished content permission from CM as that allows viewing any unpublished entity.
There is also a strange side effect that on the Layout page, the user will be able to see it because in BlockComponentRenderArray::onBuildRender block access isn't checked when in preview (i.e on the Layout page) but they won't see it when viewing the node.
Proposed resolution
Add a view unpublished block content permission
Remaining tasks
Release notes snippet
A new "view unpublished block content" permission allows editors to view unpublished blocks. The "administer block content" or "access block library" permissions may no longer be needed for certain editor roles.
| Comment | File | Size | Author |
|---|
Issue fork drupal-3020938
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:
- 3020938-add-view-unpublished
changes, plain diff MR !12513
Comments
Comment #2
jurgenr commentedI've added a patch which adds a 'View unpublished blocks' permission.
Comment #3
cilefen commentedComment #13
acbramley commentedComment #15
acbramley commentedWhile not super useful now, I think this will be quite desirable once #2834546: UI for publishing/unpublishing block_content blocks is in.
Comment #16
smustgrave commentedCan we get a CR for the new permission?
Comment #17
acbramley commentedDone https://www.drupal.org/node/3533073
I wasn't really sure if a small FR like this warranted a CR.
Comment #18
smustgrave commentedTested this one by added the permission to the editor role in the standard profile.
Created an unpublished blocked
Logged in as that user
Verified I could see the block even though did not have access block library
Seems like a nice addition, and know a few clients that have wanted this and ability to preview the block (separate ticket).
LGTM
Comment #19
catchTagging this one for product manager review.
Also where can you actually see the unpublished block? In the site layout itself or are there other places where it becomes accessible (that don't require the admin permissions anyway)?
Comment #20
acbramley commentedWhen it's placed via a block plugin
Comment #21
smustgrave commentedThis one has been sitting around for almost 4 months. Think it's still worth doing but I'm not a product manager. Maybe core committer could get them to look?
Comment #22
quietone commentedThis issue was tagged by a core committer for product manager review, so I don't really understand comment #21.
Setting back to NR for product manager review.
Comment #24
pameeela commentedNot sure this makes sense to commit before #2834546: UI for publishing/unpublishing block_content blocks?
Comment #25
acbramley commentedYou can have unpublished block content without that issue via content moderation, also that issue is a bit of a mess (see https://www.drupal.org/project/drupal/issues/2834546#comment-16087649)
Comment #26
smustgrave commentedFor what its worth still a +1 for this and hope we can unblock it before D12
Comment #27
pameeela commentedTested with content moderation based on @acbramley's comment, indeed it already is supported, so I agree this permission is useful.
Comment #28
smustgrave commentedI'm not a product manager but seems this has got a number of +1, maybe a core committer could have better luck getting sign off?
Comment #29
gábor hojtsyThe issue summary does not explain (a) how does this compare to other content entity permissions in core (b) how do we envision it being used. Is this a "basic content staging" kind of thing? What kind of user role / persona would get this permission and how would they use it?
Comment #30
smustgrave commentedThank you @gabor so much for taking a look. Moving to NW to give it a summary update!
Comment #31
acbramley commentedWe are just expanding what is possible with existing permissions, but I've added some rationale to the IS.
Comment #32
smustgrave commentedThanks for taking care of this acbramley been a hectic day
Comment #33
acbramley commentedTested this out more thoroughly and added some more caveats.
Comment #34
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #35
smustgrave commentedThere was a valid PHPCS added so that's been addressed.
Comment #36
larowlanxjm asked me to review this - it looks good to me - it has all the sign offs - product manager, product manager of Drupal CMS, both Subsystem maintainers
Comment #37
smustgrave commentedSo this one can finally be merged :)
Comment #38
xjmTechnically, this is still tagged with "Needs project manager review", and Gábor had raised reservations without officially signing off on the responses to them. I'll reach out to the project managers.
Comment #39
gábor hojtsyThanks for expanding the rationale in the issue summary. I think this makes sense now. Removing tag as a Drupal core product manager.
Comment #43
longwaveI think we can still sneak this into 11.4.
Committed and pushed 75becbf693d to main and d66ddf6ca3f to 11.x and 3c62e4ff5e5 to 11.4.x. Thanks!
Tagging for release notes, also updated and published the CR.
Comment #45
longwave