Groups with contentOnly locking should not be transformable into other variations

[richtabor]

I propose that when contentOnly locking is in place on a group block, the pattern should not have have transform controls.

contentOnly is a form of flattening/locking the innerBlocks, which when transformed does not typically result in a positive experience (as you can't manipulate the blocks further anyhow to try and fix it).

Current

CleanShot.2024-08-20.at.20.04.07.mp4

[richtabor]

There may be validity in not having transforms at all for contentOnly locked group blocks?

[jasmussen]

There may be validity in not having transforms at all for contentOnly locked group blocks?

I'd agree. If need be we can build an edit affordance, like there is for synced overridable patterns. Or you would just need to detach. By switching from row to stack, for example, it substantially alters the appearance of most patterns that were meant to be the former.

[ramonjd]

I started looking briefly.

We could completely short-circuit the block switcher in the toolbar, but I think the rest would have to be done at the block level, at least for Group blocks.

[ramonjd]

Testing stuff over here:

• Locked Templates: blocks with contentOnly locking should not be transformable #64917

What do folks think should happen when multiple blocks are selected?

My guess is that if a single block among multiple select is locked, then we shouldn't show the transformation options.

The other option is to show them and (try to) only apply the transformation to the non-locked blocks.

[jasmussen]

What do folks think should happen when multiple blocks are selected?

Would it be reasonable/possible to omit the individual-level transform, and keep only the container-level transforms, i.e. "I want to group a paragraph with a content-only locked pattern"? If that's at all hard, I'd also tend to support your instinct:

My guess is that if a single block among multiple select is locked, then we shouldn't show the transformation option

[ramonjd]

Would it be reasonable/possible to omit the individual-level transform, and keep only the container-level transforms

Hmm, I'm not sure they're filterable off the top of my hat, but I can have a quick look next week 🤔

[jasmussen]

I would say: go with the simplest option.

[richtabor]

Reopening as destructive transforms are still available from the Inspector:

[ramonjd]

Reopening as destructive transforms are still available from the Inspector:

Thanks for the report.

Could you add some testing steps on how to reproduce what you're seeing?

Template lock values of "contentOnly" behave as expected for me in post and site editors so far given the following example:

<!-- wp:group {"templateLock":"contentOnly", "style":{"color":{"background":"#f8f6db"}},"layout":{"type":"constrained"}} -->
<div class="wp-block-group has-background" style="background-color:#f8f6db"><!-- wp:paragraph -->
<p>A Group block with template lock === "contentOnly"</p>
<!-- /wp:paragraph -->

<!-- wp:group {"style":{"color":{"background":"#e1dbfd"}},"layout":{"type":"constrained"}} -->
<div class="wp-block-group has-background" style="background-color:#e1dbfd"><!-- wp:paragraph -->
<p>A nested Group block with template lock === "contentOnly"</p>
<!-- /wp:paragraph --></div>
<!-- /wp:group --></div>
<!-- /wp:group -->

[getdave]

I wonder if some PRs might need rebasing and that's why this is still coming up in demos...etc?

[richtabor]

I wonder if some PRs might need rebasing and that's why this is still coming up in demos...etc?

Yup! Pretty sure that's what's going on. Closing this. Thanks!