Title Block Becomes Uneditable When Inside a Reusable Block in the Page Editor (6.8 Beta 3)

[mtdkei]

Hello,

While testing WordPress 6.8 Beta 3 / RC1, I noticed that the Page editor UI has changed and now behaves similarly to the Full Site Editor (FSE). The entire template — including the header, footer, and the Title block — is displayed within the editor.

In this new flow, when the Title block (post-title) is placed inside a Template Part or a Reusable Block for design consistency, the user can no longer edit the page title directly from the Title block area in the editor.

Steps to reproduce

1. Create a Template Part or Reusable Block containing a Title block (post-title).
2. Insert that Template Part or Reusable Block into the header area of the Page template.
3. Go to Dashboard → Pages → Add New or Edit an existing Page.
4. The Title block appears visually, but clicking on it opens the Reusable Block edit mode instead of allowing the page title to be edited.

Expected behavior

Users naturally expect to edit the page title directly from the Title block (post-title) displayed in the editor.

Additional Information

• This issue did not occur in Beta 2 and started happening from Beta 3.
• Editing via Appearance → Editor → Pages works as expected — the Title block is editable there.
• The issue is also reproducible with the official Twenty Twenty-Five theme.
• I believe it’s not uncommon for themes to wrap the Title block in a Template Part or Reusable Block to maintain consistent design across pages.

Environment

• WordPress Beta Tester plugin installed
• Bleeding edge channel / Beta & RC Only selected
• Current version: 6.8-beta3

Since this change might impact many themes following similar design patterns, I wanted to ask if this is the intended behavior or a regression introduced in Beta 3.

If this is not the right place to report, I’d greatly appreciate it if you could point me in the right direction.

Thank you very much for your attention!

[Mamaduka]

Thanks for sharing the use case, @mtdkei!

Beta 2 had a bug with the new default rendering mode for pages, which has been fixed in Beta 3. This is the reason you're seeing the change. See https://core.trac.wordpress.org/ticket/61811#comment:25.

Regarding editing a post title or any other content inside template parts when showing a template for a page. The same behavior can be reproduced even in WP 6.7 if you enable "Show Template".

I just wanted to share some context. I'll try to share the proposed solution later. Please let me know if you have any additional questions.

[mtdkei]

@Mamaduka Thank you so much for the detailed explanation and for picking this up!

I'm glad to hear the behavior change was intentional after Beta 2.
Looking forward to the proposed solution — I believe it will help many theme developers.

Please let me know if there's anything else I can provide.
Thanks again!

[mtdkei]

Sorry, I accidentally posted the same comment twice.
Thank you!

[!IMPORTANT]
I want to highlight that limiting the ability to edit template parts in template-locked rendering mode is an intentional choice and isn't a bug.

Unfortunately, this can make the new default rendering mode confusing in some instances and prevent users from editing a post/page title.

PR reverts the new default rendering mode for Pages (WP-61811).

I'm not restoring the special case for the Site Editor, where the rendering mode was different from that of the Post Editor. Why?

• Consistency - The new default's goal was to make the page editing experience consistent between the post and site editors. There should be only one default rendering mode per post type across the editors.
• User preferences - The new persistent user preference allows users to set rendering mode based on their needs.
• More logic, more problems - I don't want to complicate the logic for deriving the default rendering mode.

[Mamaduka]

Created a patch to revert the new default rendering mode.

[Mamaduka]

I also want to cross-link this comment from @jeffr0 - ​https://github.com/WordPress/gutenberg/issues/63785#issuecomment-2738241423.

[joemcgill]

x-posting from my PR approval for visibility:

As much as I think folks will like this feature, opting in by default does create enough friction in real use cases that it probably does make sense to remove.

All the infrastructure is still in place for people to opt in to this default by modifying post type support for any post types that where they want this to be the default experience and when users change their template view while editing a post, that preference will be used the next time that user edits a post of the same post type, so this has been a worthwhile experiment, leading to some real improvements in the UX.

Thanks @Mamaduka!

[Mamaduka]

In 60076:

Editor: Revert the new default rendering mode for Pages.

This fully reverts changes from #61811 while leaving infrastructure in place for consumers to enable different default rendering modes for their post types.

Props mamaduka, joemcgill, mtdkei.
Fixes #63139.