Audit blocks for writing and contentOnly modes

[talldan]

Description

contentOnly mode is becoming more prevalent in the editor after 'Select Mode: Use the content-only behavior in select mode' was merged.

Lots of block types still aren't working perfectly in contentOnly mode, so this list intends to capture those issues so that they can be worked on in parallel by multiple devs. Lots of the blocks also share similar issues, so hopefully there are higher-level solutions to the problems that can be found (lets discuss these in the comments).

Feel free to add more to this issue if you discover untracked issues.

Rough snippet that can be run in post editor's console to generate example blocks in contentOnly locked groups, YMMV 🤷

const blockExamples = wp.data.select( 'core/blocks' ).getBlockTypes()
  .filter( ( { example } ) => example )
  .map( ( { name, title, example: { attributes, innerBlocks } } ) => ( { name, title, attributes, innerBlocks } ) );
const createInnerExamples = ( innerBlocks ) => innerBlocks.map( ( { name, attributes, innerBlocks } ) => {
  return wp.blocks.createBlock( name, attributes, createInnerExamples( innerBlocks ?? [] ) );
});
const createExamples = ( examples ) => examples.map( ( { name, title, attributes, innerBlocks } ) => {
  const innerBlockInstances = createInnerExamples( innerBlocks ?? [] );

  return wp.blocks.createBlock( 'core/group', {
    templateLock: 'contentOnly',
    metadata: { name: title }
  }, [ wp.blocks.createBlock( name, attributes, innerBlockInstances ) ]);
});
const innerBlockInstances = createExamples( blockExamples );
const blocks = wp.data.select( 'core/block-editor' ).getBlocks();

wp.data.dispatch( 'core/block-editor' ).insertBlocks( innerBlockInstances, blocks.length );

Blocks

Buttons

• User cannot add/remove individual buttons (see Add new mode to contentOnly locking to allow insertion of new inner blocks #52018)

Cover

• Background image cannot be modified (should it be possible to modify this?)
• Initial block placeholder can't be interacted with in contentOnly mode (possibly the same issue as above).

Details

• Details block appears as a single 'Paragraph' in the Inspector Content panel

File

PR: #65787

• Block is completely non-interactive, including the placeholder

Gallery

• Placeholder is non-interactive in contentOnly mode.
• Users cannot add/remove items (should they be able to?) (see Add new mode to contentOnly locking to allow insertion of new inner blocks #52018)

List

PR: #65836

• Users cannot add/remove list items from the list block or nest list items (how should nested list items appear in the Inspector content panel?) (see Add new mode to contentOnly locking to allow insertion of new inner blocks #52018)
• List Items currently have a special case in the code to prevent them appearing in the Inspector Content panel (a more general solution to this should be found as other container blocks will have the same kind of problem for their inner blocks):

  gutenberg/packages/block-editor/src/components/block-inspector/index.js

  Line 242 in df27bd9

  getBlockName( current ) !== 'core/list-item' &&

Media / Text

• Additional paragraphs can't be added in the content area of the block (similar to Quote)
• In the Inspector panel, the paragraph that's inside the Media Text block appears after it (again, similar to Quote)

More

• User cannot edit 'Read more' text

Navigation

• Cannot be edited (see Navigation Block: develop a content-only representation #65699)

Post Title / Featured Image / Excerpt

• Blocks cannot be edited (they have no attributes suitable for the role: content declaration)

Query

• Query Loop Block: develop a content-only representation #66614

Quote

• The paragraph that's inside the Quote appears after the Quote block in the Inspector Content panel (to repro, add a quote block inside a group, apply contentOnly templateLock to the group, and select the group.)
• Users cannot add more paragraphs (should they be able to? If so should they also be able to add other types of blocks? How do these appear in the Inspector Content panel?) (see Add new mode to contentOnly locking to allow insertion of new inner blocks #52018)

Site Logo / Site Title / Site Tagline

PR: #67260

• Blocks cannot be edited (they have no attributes suitable for the role: content declaration)

Social Link(s)

• Social Link: Add contentOnly editing support #66622
• Allow editing individual link text. Should be button be refactored to use <RichText />?
• Should social link block styles be shown in Write mode for each link or only the social links block container?
• Additional blocks cannot be added to Social Links (see Add new mode to contentOnly locking to allow insertion of new inner blocks #52018)

Synced Patterns in Write Mode

PR: #67026

• Write Mode: Non-overridden synced pattern content is editable #66424

Table

• Block is completely non-editable in contentOnly mode, including the initial placeholder

Template Parts

• Template parts are unselectable in write mode, as they're not considered 'sections'. (see Template part selecting and editing unavailable in “Write” mode #66463)

[youknowriad]

For blocks like "list" and "quote", their "inner blocks area" should be marked as "content" somehow it seems. But how far do we take this: is "cover" block's inner blocks also "content"? I guess not but the line is very blurry, in some situations I would love to be able to add paragraphs within "already designed cover blocks" for instance.

[talldan]

For blocks like "list" and "quote", their "inner blocks area" should be marked as "content" somehow it seems. But how far do we take this: is "cover" block's inner blocks also "content"? I guess not but the line is very blurry, in some situations I would love to be able to add paragraphs within "already designed cover blocks" for instance.

Yep, it does feel a bit blurry. Also whether only paragraphs can be added to Quote/Cover or other types of content blocks too.

Heading and List might be other basic text blocks that are candidates. Then List is itself a container, so this is where the flat content structure in contentOnly mode starts to become more challenging to represent.

[richtabor]

For blocks like "list" and "quote", their "inner blocks area" should be marked as "content" somehow it seems. But how far do we take this: is "cover" block's inner blocks also "content"?

The most straightforward move is to solve for repeatable inner blocks, like Button within Buttons block, and List Item within the List block first. Where if you press enter, another of the same block is inserted.

[talldan]

File block was an easy one to fix so I've made a PR - #65787.

I've also been experimenting with the List block with mixed results. I'll try to get a PR up soon.

[richtabor]

For blocks like "list" and "quote", their "inner blocks area" should be marked as "content" somehow it seems.

Related #57911

[annezazu]

I just tested Write/Design mode with a few themes and want to underscore the following as we need these:

• Site Title/Site Logo: for themes that have a "link in bio" feel, this completely breaks the experience as you can't edit much of the main pieces you would want to.
• Navigation: for any theme, I'd want to be able to edit navigation.

Blocks I think should be on the list:

Social Icons: it's odd that you can't edit these, especially if you think about a link in bio site

social.icons.can.t.edit.mov

Query Loop block: strange experience where you can edit the "no results" text but nothing else. I think we should expand what's available in block settings in line with what's described here so there's a more visual and clearer action to take: #63497

query.loop.oddness.mov

[annezazu]

Just did user testing with a friend and want to underscore featured image block too. They couldn't select it and, as a result, didn't know what it was or where it would show up! Here's a quick video demoing how awkward this is, audio included:

featured.image.explanation.mov

Finally, they also ran into issues with the site tagline where it says "write your site tagline" prompt yet they can't select it. Pretty confusing!

[richtabor]

Blocks cannot be edited (they have no attributes suitable for the role: content declaration)

Is there not a way to imitate it? Thinking of site title and tagline here.

[talldan]

Is there not a way to imitate it? Thinking of site title and tagline here.

I think an option might be to switch those blocks over to use block bindings (then the blocks would have a content attribute used for the binding).

I'll do an investigation to see what that would require.

[fabiankaegy]

@talldan @richtabor I'm not sure I understand how role: content would help for the usecase @annezazu is describing here. We can't use role: content as a metric to determine whether a locked block that lives within a template should remain to be editable 🤔 Because role: content tells you nothing about where that attribute is getting stored 🤔 And since those blocks live inside a template they cannot have any actual attributes updated since it would affect every single post and not just the current one. So the block needs to tell the editor in some other way which fields it saves to a separate non attributes field so those can be enabled. Today that happens via a filterable array containing all the blocks that should remain editable when displayed in a locked template.

[talldan]

We can't use role: content as a metric to determine whether a locked block that lives within a template should remain to be editable 🤔 Because role: content tells you nothing about where that attribute is getting stored

I think it can be used as a metric most of the time for contentOnly locking, where the attribute definition does determine whether the block is editable.

Because role: content tells you nothing about where that attribute is getting stored 🤔 And since those blocks live inside a template they cannot have any actual attributes updated since it would affect every single post and not just the current one.

The attribute would have a binding to the site title, so when editing it, the site title would be updated the same way it is today. There shouldn't be any change in functionality. The reason it'd be beneficial is that the block would have a more complete definition and the content attribute could be marked with role: content.

There's a PR available at #67260 for testing. I might try a different approach, but I think the PR shows the general idea works.

So the block needs to tell the editor in some other way which fields it saves to a separate non attributes field so those can be enabled. Today that happens via a filterable array containing all the blocks that should remain editable when displayed in a locked template.

If we're talking about page editing in the site editor, I think this is a different concern, though maybe closely connected. When editing in this way, the container blocks that are part of the template are disabled (so contentOnly editing is inactive), and then there are those specific blocks you mention that remain editable in that mode (post title, featured image). That probably won't change (site title would still be disabled), though maybe with a binding it's possible to determine where the data is coming from, so it could be possible to revisit the hard-coded array and instead check which parts of the template are bound to the post.

[tellthemachines]

I'm noticing differences in the behaviour of some blocks depending on whether they're at root level or inside a container.

• Details block: can't edit summary only if it's inside a container, can edit if it's at root level.
• Quote and Media & Text blocks: can't add new Paragraphs on Enter if they're at root level, but can if they're inside another container; however trying to create different block with the slash inserter produces an error.
• Image block: can't add or remove captions. If the block is at root level "Add text over image" is available, but not if it's inside a container.

[youknowriad]

Quote and Media & Text blocks: can't add new Paragraphs on Enter if they're at root level, but can if they're inside another container; however trying to create different block with the slash inserter produces an error.

This sounds like a recent regression for me. AFAIK conceptually for the moment, it shouldn't be possible to add blocks even within containers. (maybe this regression impacts the two other cases, but that I don't know for sure)

[aaronrobertshaw]

While testing blocks wrapped in contentOnly locked groups, I noticed some weird behaviour where double-clicking would select multiple blocks at the top level. I could also replicate the same behaviour within the site editor. I'm out of time to dig into this but I can revisit on Monday when I'm back online.

Post Editor	Site Editor
Screen.Recording.2024-11-28.at.6.55.23.pm.mp4	Screen.Recording.2024-11-28.at.7.01.11.pm.mp4

[ramonjd]

Allow editing individual link text. Should be button be refactored to use ?

I added this question to the social link block. There's a bit of a disconnect between Write and Design mode (context) for this block, but a general question occurred to me:

How should blocks know about write mode? Many blocks are using the useBlockEditingMode hook to do custom things based on the "Write/Design" mode.

[fabiankaegy]

How should blocks know about write mode? Many blocks are using the useBlockEditingMode hook to do custom things based on the "Write/Design" mode.

As far as I understand things the write design mode simply sets blockEditingMode of every single block to contentOnly (with some more nuance. Like some also get disabled etc). But it should be possible to simply rely on useBlockEditingMode() like we do today to understand if you are in design or in writing mode

[ramonjd]

I noticed something while testing #67372 - should nested template parts be draggable?

When editing a template, there seems to be a general inconsistency with write mode blocks draggability - image blocks are draggable, but paragraphs aren't.

Should anything be draggable in write mode?

[talldan]

Should anything be draggable in write mode?

Only blocks that are sections (direct children of the section root). In your screenshot it might be correct if the top level 'Group' is the section root (it has the <main> tag).

image blocks are draggable, but paragraphs aren't.

This part might be a bug, recorded in #67408. Or it might be that the image was also a direct child of the section root.