Site Tagline: Make editable inside content-only locked parents

[richtabor]

What

Replaces supports.contentRole: true on the Site Tagline block with role: "content" on its level attribute.

Why

contentRole: true is meant for transparent container blocks (e.g., core/buttons, core/list) — blocks that hold content children but aren't themselves directly editable. The reducer recognizes that flag and assigns those blocks an editing mode of disabled inside content-only locked sections, surfacing their children instead:

// packages/block-editor/src/store/reducer.js
if (
    isContentBlock( blockName ) &&
    ! hasContentRoleSupport( blockName )
) {
    derivedBlockEditingModes.set( clientId, 'contentOnly' );
} else {
    derivedBlockEditingModes.set( clientId, 'disabled' );
}

Site Tagline is a leaf block (its text is the content, edited via the description entity record), not a container. Flagging it as a content-role container forced it into disabled mode in content-only sections, so the RichText couldn't be focused or typed into.

This PR aligns Site Tagline with how Site Title and Post Title declare themselves as content blocks: by giving an attribute role: "content". That makes isContentBlock return true via the attribute path (not the contentRole-container path), so the reducer assigns contentOnly editing mode and the tagline becomes editable inside content-only locked parents — matching Site Title's behavior.

Test plan

• Insert a Group block, set its template lock to Content (content-only).
• Add a Site Tagline block inside the Group. Confirm the tagline can be focused and edited.
• Add a Site Title block inside the Group. Confirm both behave identically (both editable, structural controls hidden).
• Confirm outside of content-only contexts, Site Tagline still exposes its heading-level dropdown and inspector controls.

🤖 Generated with Claude Code

[github-actions]

Flaky tests detected in 8ace5ce.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/25070421937
📝 Reported issues:

• [Flaky Test] post title and content are editable and blocks can be inserted #77720 in /test/e2e/specs/editor/various/post-content-focus-mode.spec.js
• [Flaky Test] should show the edited content after revert, clicking undo in the header toolbar, save and reload #67172 in /test/e2e/specs/site-editor/template-revert.spec.js

[github-actions]

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: richtabor <richtabor@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[Copilot]

Pull request overview

Adjusts how the core/site-tagline block is classified for content-only editing contexts by moving from supports.contentRole to an attribute-level role: "content" marker, and updates the core blocks reference accordingly.

Changes:

• Update core/site-tagline block metadata to add role: "content" to the level attribute and remove supports.contentRole.
• Update the Core Blocks Reference docs to remove contentRole from Site Tagline’s listed supports.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
packages/block-library/src/site-tagline/block.json	Replaces supports.contentRole with attributes.level.role: "content" for content classification.
docs/reference-guides/core-blocks.md	Updates the Site Tagline entry to no longer list contentRole support.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[t-hamano]

Thanks for the PR. However, can you clarify the testing procedure? As far as I tested, no issues occurred on the trunk branch.

• Insert the following HTML via the code editor:

  <!-- wp:group {"templateLock":"contentOnly","layout":{"type":"constrained"}} -->
  <div class="wp-block-group"><!-- wp:site-tagline /--></div>
  <!-- /wp:group -->

• Select the Site Tagline block and edit the text

Recording.2026-04-30.115449.mp4

[Mamaduka]

It looks like the flag was intentionally introduced in #71627 and then partially reverted. I agree with @t-hamano, test instructions need an update.

cc @talldan, @andrewserong

[talldan]

contentRole: true is meant for transparent container blocks

This part isn't true, possibly hallucinated. The naming is contentRole because it directly replicates role: content.

And in the same way role: content also works for container blocks.

What exactly is the issue here? I'm a bit confused by the PR.

[talldan]

I think if we want to add contentRole to level then it needs to be done the same way for every block. Site Title and Heading included. Not sure if there are others that also have level.

edit: personally, I would just close the PR as it already works as expected in trunk.

[Mamaduka]

I think if we want to add contentRole to level then it needs to be done the same way for every block. Site Title and Heading included. Not sure if there are others that also have level.

Right. Not every block will have an attribute that can be marked with a content role. The contentRole flag seems to be in the right direction for blocks that use only entity props for content.

[talldan]

The code snippet seems hallucinated or outdated too. This is the code presently:

gutenberg/packages/block-editor/src/store/reducer.js

Lines 2660 to 2664 in dbc1427

	if ( isContentBlock( blockName ) ) {
	derivedBlockEditingModes.set( clientId, 'contentOnly' );
	} else {
	derivedBlockEditingModes.set( clientId, 'disabled' );
	}

isContentBlock returns true for both contentRole support and role: content.

[richtabor]

edit: personally, I would just close the PR as it already works as expected in trunk.

Yea, maybe I had an outdated version? Confirmed it works in trunk. Thanks!