WordPress 7.0: iteration issue for Pattern Editing and contentOnly interactivity

[ramonjd]

An iteration issue for Pattern Editing and contentOnly interactivity in WordPress 7.0.

Reference issues:

• Pattern Editing and contentOnly interactivity #71517
• Block Attribute Groups #73845
• Design idea: Pattern editing and contentOnly interactivity #73466

Scope / PRs completed

This list may change as development continues. There are numerous "Done" tasks which are not noted here. See the project board for a full overview.

• Content only: implement pattern-level editing modes for contextual and "symbol" patterns #73677
• Isolated editor: "Back" navigation needs to return users to their original location in the document flow #73679
• Pattern editing: create a "tree" view for Buttons and List blocks #73866
• Pattern Editing: Template Part block doesn't display tabs in the block inspector #74726
• Patterns and content only: add E2E test coverage for basic functionality #73267
• Patterns as content only: update documentation #71572
• (punted) Pattern Editing and contentOnly: Fade out other blocks in List View when spotlight editing instead of hiding them completely #73954
• Patterns: add a way to opt-out of default content only mode #71573
• Accordion block in section blocks / content only mode: improve how it appears #75270
• Pattern Editing: Revise 'Edit section' button naming #75663

Tasks that need more definition before a dev can work on them:

• (partially addressed, rest punted) Patterns and content only: improve pattern editing discoverability #73271
• (punted) Pattern Editing and contentOnly: Add breadcrumbs to the editor top bar when navigating between entities #73953
• (ongoing) Audit blocks for contentOnly mode support #65778 (?)

Stretch goals

• contentOnly patterns: improved paragraph editing #71887 (partially addressed)

Tracking issue and Project board

To track progress on this feature you can also visit:

• Pattern Editing and contentOnly interactivity #71517
• https://github.com/orgs/WordPress/projects/265/views/1

[fabiankaegy]

Testing Feedback: Simplified Pattern Editing Experience

Hi all 👋
I spent some time testing the new simplified pattern editing experience (with only the "Make patterns content only by default upon insertion" experiment enabled, no other experiments). Testing was done on a standard installation with the Twenty Twenty-Five theme, starting with page-level patterns.

Overall Impression

I love the concept of simplified editing. I've long thought that our deeply nested block structures are too difficult to understand for simple use cases. So I genuinely want this kind of experience to succeed.

However, in its current form, I don't think this should ship in core as it stands today. Here's why:

Core Issue: Feeling Stuck

The moment I started editing content in a page-level pattern, I immediately felt stuck. If I want to insert anything new into a section, a list item, a button, a table, I simply can't. There's no obvious way to do it.

"Edit this section" is Too Hidden

Yes, eventually I discovered the "Edit this section" button in the sidebar. But:

1. It's too far away - buried in the sidebar, not where my focus is
2. It's a foreign concept - took me a while to even understand what it does
3. I don't always have the sidebar open - so I had no idea how to access that mode

The Write/Design Mode Switcher Was Better

I actually went back and tested the previous approach with the distinct Write/Design mode switcher in the toolbar. That experience was significantly better than the current implementation.

With the mode switcher:

• It was clear and discoverable in the top toolbar
• I could switch between writing and designing at will
• I had control over the entire page at once

Multi-Section Editing is Painful

If I want to make design changes across multiple sections, the current flow is:

1. Click into Section A
2. Click "Edit this section"
3. Make changes
4. Click out
5. Click into Section B
6. Click "Edit this section"
7. Repeat...

This is incredibly slow and frustrating when you need to make broader page-level changes. The section-by-section approach adds too much friction.

Two Specific Missing Features

1. Flexible Content Areas

We need the ability to mark certain containers as "flexible content areas" where users can insert arbitrary blocks (lists, tables, buttons, etc.) without switching to edit mode.

For example: A Media & Text block with a custom layout should allow me to add a button or a list inside the text area without needing to "Edit this section." That's content, not design.

2. Parent Block Selector for Buttons

With the contentRole support on container blocks, I can technically add a secondary button by pressing Enter on an existing button. But this is not discoverable at all.

The parent selector that would let me select the Buttons container block is no longer in the toolbar. Outside of using the List View, there's no way to reach the Buttons container and see its inserter.

The Real Problem: User Types

WordPress has different user types with different needs:

• Content editors who just want to write and update text
• Site builders who need to make design changes and customize layouts

This current implementation over-optimizes for the simplified content editing use case while forgetting about the more advanced use case. We need both.

My Recommendation

Bring back the Write/Design mode concept, but at the page level, not per-section. Let users:

• Start in a simplified "Write" mode by default (the current simplified view)
• Have a clear, discoverable toggle to switch to "Design" mode for the entire page
• Not be forced to go section-by-section for design changes

The Write/Design mode switcher worked beautifully. I'd love to see that approach refined rather than replaced with this more restrictive pattern.

---

I want to emphasize: I'm a big fan of simplified editing and the progress we've made with content-only editing. The underlying work here is incredibly cool. But the current UX for switching between modes, in my opinion, needs more iteration before it's ready for stabilization and therefore core.

[jasmussen]

Thanks for testing deeply. I tend to think all your points are valid, but I want to make a very short argument for why I think this should still ship.

I'm being intentionally reductive to not repeat your comment, but I'm reading in your feedback two main things:

1. Discoverability of the "Edit section" button.
2. The perceived need to engage with said button.

1 started intentionally small: the goal is for you to not need to engage with it that often. Ideally every pattern is flexible in a way where you don't find a need to do this.

2 follows from that: the concept of this feature is to re-cast patterns as just bigger blocks, ones you don't need to edit. You can, but it's not meant to be the primary interaction.

This is a bit of a circular dependency: what you identify is that patterns that ship in default themes were not designed for this use case, and are in some places perhaps too expressive beckoning an edit, or perhaps with a hard-coded inner color rather than inheritance. A theme like Assembler, on the other hand, is packed with utility patterns that make it feel much more organic. Assembler is not the reason this should ship, but the chicken and egg problem is: the sooner we employ the new behavior, the sooner we can start to optimize patterns for this flow. And all your valid feedback on discoverability we can respond to, ideally in the beta phase: adding an Edit button to the block toolbar for the pattern, making the button in the inspector primary, adding double-click to edit "the insides", adding a "delete" shortcut to any inner-block you select in a pattern to hide it a la Figma. I see such potential in this 🌌

[fabiankaegy]

Hi @jasmussen 👋 Thanks for all the thoughts here :)

I think I understand the goal and the framing here. But I think in order to actually achieve this, we have to find a solution for allowing the insertion of new content blocks into flexible areas within those larger patterns.

Without that, a pattern library (from my POV) can never be flexible enough to actually deliver on what you are suggesting here....

[jasmussen]

Can you elaborate on the inserting blocks aspect? Is it mostly pressing Enter to create additional paragraphs, or larger freeform text editing? I think this was solved for lists and Buttons blocks, and think a similar solution could be employed for paragraphs, potentially, just curious if you mean something else.

[fabiankaegy]

@jasmussen the improvements we've already made to allow inserting new list items / additional buttons when there already is one etc are huge and I'm so glad we have them now.

But what I mean here is the ability to add entirely new content blocks to a content section within a pattern.

Like the ability to add a button to a section that doesn't already contain one. Adding an additional small icon block above a heading, a separator, social links, table etc.

We will never be able to have patterns for all the variations of flexible content within a larger pattern. And I don't think it would create a every good experience to have that.

What I'm thinking here is the ability to make any inner blocks area inside a pattern, whether that is using groups, columns, accordions etc so that the content within that section again allows insertion of any content blocks regardless of if they were used before.

One concrete example of this:

Imagine a FAQ section that has accordions in it. The default pattern only has paragraphs in each accordion content. But I now want to insert images / tables into each accordion item.

Those things are super common. But now the new experience adds friction to that by having to click the edit section button for every single section I want to do this in.

Which I think is creating a more restrictive editing experience that creates points of frustration because editors are unsure how to do simple things like adding a basic button after some text.

[jasmussen]

I appreciate that elaboration, thank you. I echo it and want it improved, and yet I feel it's still worth shipping: a pattern is just a big block, only now I can edit the contents inside easily! And if I need something fancier than that, I can either detach, or edit the insides. I think the benefits of simplicity and flow vastly outwheigh the otherwise very real downsides you mention, if we just allow ourselves to think of detaching as a valid part of the flow.

But I don't have strong opinions. I'd very much like it default-active in the plugin to continue to gather feedback, at minimum, but if consensus found as a result of this is to punt, I will be here to support all next steps.

[fabiankaegy]

I'm also happy to support whatever consensus we land on :)

The last thing I wanted to add is that part of why I wrote all of this, is that as far as I understand it, with this change all existing patterns that have a top-level group etc. now change to function in this way rather than the hold way.

If this was an "opt-in" option on patterns that we can use in core block themes if we want to that's a different story (even though yeah I don't love the fragmentation and I'm all for decisions over options). The thing that concerns me is the fact that any site that updates now all of a sudden has patterns that work completely differently to how they behaved the day before, and that are less flexible (not in terms of design. that is the feature here...) but in terms of content editing. And to me, adding a button, table, image etc. are content level changes. Not design level changes.

[jasmussen]

The last thing I wanted to add is that part of why I wrote all of this, is that as far as I understand it, with this change all existing patterns that have a top-level group etc. now change to function in this way rather than the hold way.

Focusing in on this one, @fcoveram and I discussed some options here that may assuage those pieces. We could:

1. Make it so any pattern that has a single top level container (group, stack, columns), gets the new treatment. Anything else is automatically opted out, intentionally so.
2. Add an option in preferences for pattern insertion: "Insert patterns as a single block", on/off, to let you choose your own preference.

For 1, this would address the issue of existing patterns that are ungrouped and simply say: this is intentional. If you patternize ungrouped content, it remains ungrouped content. If you group it, you're building a new block.

For 2, it's leaning into the idea that there isn't necessarily a one size fits all flow when you reach the scale that WordPress has, and through options we can meet people where they are.

[talldan]

@fabiankaegy Thanks so much for testing.

With the contentRole support on container blocks, I can technically add a secondary button by pressing Enter on an existing button. But this is not discoverable at all.

The parent selector that would let me select the Buttons container block is no longer in the toolbar. Outside of using the List View, there's no way to reach the Buttons container and see its inserter.

I'm not sure if it was there when you tested, but a more recently added feature is the List View UI in the sidebar that allows for re-arranging the list-style blocks in a pattern, and it also allows for inserting more of those blocks:

That's one thing that might make it easier. Perhaps it's also worth experimenting with showing an appender in the canvas when one of the List Items is selected.

If I want to make design changes across multiple sections, the current flow is:

Double-clicking an unsynced pattern is also a way to edit it, but I realize that's not exactly discoverable, perhaps only by chance.

There's an issue here that tracks improving discoverability of editing - Patterns and content only: improve pattern editing discoverability.

It's short of ideas at the moment. Perhaps also adding 'Edit' to the toolbar would be the easiest solution, and it would match the similar 'Edit' button for template parts and synced patterns.