Site Editor: Don't allow removing the content block from post-type templates

[aristath]

Came up during a contributors day, from users testing FSE for the 1st time.

When editing the template for all pages, all posts etc, removing the content block from the template would break the expected behaviors of these templates.
Perhaps we should guard against that behavior by showing a notice and requiring users to confirm before the content block is removed from these templates?

[mtias]

We need to look a bit into default locks (with the possibility of unlocking) for some things. We have already added some initial lock attributes for using in patterns. cc @jorgefilipecosta

[mattwiebe]

Just chiming in here to say that this has come up a few times in internal testing of the Site Editor on WordPress.com. In our case what's generally happening is that users are trying to delete some default homepage content that we've generated for them, and wind up deleting the Post Content block along with it.

[apeatling]

+1 for supporting locking of blocks.

[cuemarie]

+1 - I'd love to see this implemented. Of course we don't want to make it impossible for folks to remove or customize these blocks, but some roadblocks to slow newer users down could help save them headaches in the long run!

[supernovia]

Now that blocks can be locked, could this be implemented?

[mtias]

It also seems regardless of locking we should show a modal for confirmation "Are you sure you want to remove the content block? The content is what allows ...".

[annezazu]

Returning to this after getting feedback that it remains difficult for folks to understand the impact of the action of removing the Content Block, even after adding in a warning as @mtias suggests above: #40618

There are a few ways forward:

• Locking the Post Content block as this suggests to prevent it from being removed.
• Evolving the language of the Post Content block's warning.
• Iterating on the placeholder content to make it clearer what this block does.

This problem is more pronounced in a way with the new template vs content editing UX where you can switch between a template and content with ease. Because the views look so similar though, it's easy to see how someone might switch over to view the template, not understand what the post content block is, and delete it only to find it to be quite convoluted to restore later. Here's a video to get the point across where, after deleting the post content block, the Site Editor page editing experience is not very useful:

Screen.Recording.2023-10-03.at.4.14.58.PM.mov

cc @WordPress/gutenberg-design for some ideas and feedback.

[jameskoster]

In the case of singular templates (single-post, page, etc) is there ever a valid reason for removing this block? I'm struggling to think of one, so it might be worth disabling the delete action entirely in those contexts. A modal could appear when the user hits backspace, or if they attempt to delete a containing block. This kind of friction might lead the user to better understand the purpose of this block.

That, coupled with an updated placeholder and closing #55025 could potentially help a lot.

[annezazu]

I don't think there is a valid reason and I really dig your plan 💥 Ship it!

[richtabor]

In the case of singular templates (single-post, page, etc) is there ever a valid reason for removing this block?

Only when a "template" is used incorrectly, where you're editing the template as the page.

[richtabor]

Another consideration if we're going to make it not possible to remove is that there may be more than one core/post-content block on a page (if there's a page with a posts feed under it). Currently when you try to delete either one you get the notice.

[mtias]

Of course there are valid reasons :) You might design a theme or site where the content is not used, or not used in a straightforward way because you only consume from meta fields and other meta data.

@annezazu it's not clear the context of that feedback, but it sounds like improving the description would be a better start.

[annezazu]

Yes! I think that's the easiest first step to try.

[annezazu]

Noting the work around this issue: #52392 including this PR to update the copy/design: #54715 Would love help to move this forward at this stage!

[mrfoxtalbot]

I have noticed that the Content block is now locked by default, which I think addresses this underlying problem.
Do we think we can close this issue now? @aristath, @annezazu

[annezazu]

@mrfoxtalbot where are you seeing that? Is it on the TT4 theme? If so, that was a choice by the theme authors here https://github.com/WordPress/twentytwentyfour/blob/trunk/templates/page.html#L22C4-L22C97 and it's not in place on all themes. This issue remains open as a result but theme authors can choose to lock :)

[mrfoxtalbot]

I see! Yes, it was 6.4.2 with TT4. I did not realize this was theme-dependant.

Thank you for the clarification @annezazu.

[davewhitley]

Locking the Content block by default would be a great start I think. To push this further, the block should be visually distinct to separate it from a normal paragraph block.

In the 2 examples below, other blocks have distinct visuals to communicate that they are "special". Purple is used to signify that the block is somehow linked/synced to content elsewhere. Can we do the same for the Content block? Maybe use an icon shown below?

[jameskoster]

Locking the Content block by default would be a great start I think

Agree this would be a good standard for theme authors to adopt, unsure if we should hard-code it.

To push this further, the block should be visually distinct to separate it from a normal paragraph block.

A while ago I suggested registering this block as a template part which would achieve this: #44362. This would result in the block appearing in the "Areas" section of the Inspector too.

In #61175 (comment) there's discussion about expanding the "areas" concept which feels related.