Try an explicit contentRole for containers where blocks can be added in contentOnly mode#75812
Open
tellthemachines wants to merge 1 commit intotrunkfrom
Open
Try an explicit contentRole for containers where blocks can be added in contentOnly mode#75812tellthemachines wants to merge 1 commit intotrunkfrom
tellthemachines wants to merge 1 commit intotrunkfrom
Conversation
tellthemachines
added
[Type] Enhancement
github-actions
bot
added
[Package] Blocks
|
Size Change: +21 B (0%) Total Size: 6.84 MB
ℹ️ View Unchanged
|
tellthemachines
force-pushed
the
try/separate-content-from-containers
branch
from
bc64b63 to
f6902b2
Compare
tellthemachines
requested review from
ajitbohra,
ellatrix,
fabiankaegy and
juanmaguitar
as code owners
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
ramonjd
reviewed
Feb 25, 2026
Member
ramonjd
left a comment
ramonjd
left a comment
There was a problem hiding this comment.
by only allowing insertion into blocks that have contentRole: true, and not into blocks that only have content attributes.
I think this is a good change, thanks a lot for getting it up for testing.
I wasn't sure, was this PR designed to complement or be an alternative to #75655?
Anyway, at least for the cover block I tested, it removes the inserter and makes the "container" more consistent with the content only experience. E.g., I can only edit internal content blocks and not add any random block.
| Before | After |
|---|---|
 |
 |
Here's media and text, because it was mentioned in the other PR
| Before | After |
|---|---|
 |
 |
Currently it's always possible to insert new paragraphs where a paragraph already exists, which will cover at least some use cases.
Just checking, in trunk I can add any block to the details block, but this PR restricts it to the internal content block (paragraph), which I think is okay. Editing the pattern, I can add images and so on.
| Before | After |
|---|---|
 |
 |
| const isRootBlockMain = getSectionRootClientId( state ) === rootClientId; | ||
|
|
||
| // In contentOnly mode, containers shouldn't be inserted into unless: | ||
| // 1. they are a section root; |
Member
There was a problem hiding this comment.
Is this still the case? e.g., The container is the section root, or...
| }, | ||
| "listView": true | ||
| "listView": true, | ||
| "contentRole": true |
Member
There was a problem hiding this comment.
Trying to use my meat brain to test today 😄
So I understand, adding the contentRole` prop preserves current behavior for these blocks?
I mean, is it saying "this block’s inner area is a content container", and therefore lets users insert allowed blocks (Image) into that area in contentOnly mode?
Contributor
Author
This PR would be a precondition for #75655, so that we can somewhat restrict the changes there. But it's still useful to solve a few problems even if we decide not to ship #75655.
Yes. For Details or any other container block, if we want it to be possible to insert other blocks in it, we can either add |
tellthemachines
force-pushed
the
try/separate-content-from-containers
branch
from
f6902b2 to
b21bac1
Compare
Contributor
|
I like the concept, but I'm not sure about using I'd personally prefer something more explicit like |
Contributor
|
Also might have to consider if this is a breaking change, |
Contributor
Author
This PR doesn't change anything about how |
Contributor
Yeah, that's the part I'm concerned about. Block authors now have to add contentRole to match the behavior in 6.9. |
Contributor
Author
This didn't ship in 6.9 though, or do you mean for templateLock? Fwiw last time I tested popular block plugins nobody was using |
Contributor
|
Ignore In 6.9, if If there's a way to not change the behavior from 6.9 I think it would be better. Maybe nobody is using it, but at the same time I don't think it's hard to keep it working as it was. People won't ever use the APIs if they change unexpectedly from release to release. Separately, I'm not sure about changing |
Contributor
|
here's a different wpdirectory search: |
Contributor
Author
|
Wpdirectory isn't delivering reliable results. Searching for
Given that we didn't ship write mode or contentOnly patterns in 6.9, where could this realistically have been used? It wasn't documented anywhere, so the chances of extenders even being aware of it are low.
I don't think the current behaviour is ideal. I know, I'm responsible for it! but at the time we were still building write mode and the feature requirements were very unclear. And it didn't work well enough, because we later had to introduce And given we now have I think we should take the opportunity to change this while we can, because if contentOnly patterns ship in 7.0 it will be too late after that. Otherwise, what alternative solutions do we have? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
Trying to solve the problem of blocks which we might want to edit attributes of, but not allow any new blocks to be added inside them, e.g. Query as per this comment or Cover as shown in this video.
For some blocks that are containers and also have content attributes (Query doesn't yet have those attributes, but might at some point), we might not want to be able to insert new blocks in them when in contentOnly mode.
This PR prevents that by only allowing insertion into blocks that have
contentRole: true, and not into blocks that only have content attributes.In order not to break things for some blocks that relied on their content attributes to be insertable, it adds the
contentRole: trueto those blocks.I deliberately refrained from adding
contentRole: trueto blocks such as Quote and Details because I'm not sure if we want the ability to insert any type of content to them. Currently it's always possible to insert new paragraphs where a paragraph already exists, which will cover at least some use cases.There's also the possibility of combining this with allowing insertion of any content blocks where at least one content block already exists, as proposed by #75655. (If we do want to go with that, we might need further guardrails around which content blocks should be insertable, as mentioned here)
Testing Instructions
This TT5 block is a good one to test because it contains an empty Cover block:
The inserter shouldn't be visible with this PR.