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.

[tanjoymor]

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.

@mtias Can you provide a live, real world example of this? I genuinely cannot visualize this in action.

I agree with preventing the block from being removable. But perhaps conditional that there has to be at least one instance of the block, additional instances could be removable.

Even if there is real life edge case where someone might use the Pages and Single Posts multi-use templates for one singular purpose (rather than the intended use of these templates pairing with multiple content pieces) I don’t see the Content block getting in the way of doing, the block itself doesn’t display.

[mtias]

@tanjoymor plenty of cases where the template may only render a featured image or other custom fields in place of the content.

I think there's a lot of problems with clarity of placeholder elements when editing a template. It's most notorious on the content block. Having regular text there is very misleading and likely conditioning users that they need to remove it somehow, that it's the same as starter content they can edit or remove. We should display this in an entirely different way to start.

[tanjoymor]

plenty of cases where the template may only render a featured image or other custom fields in place of the content

And that page is content added directly to the Pages template? What templates are your other pages using @mtias?

[mtias]

That one specifically is a single post format template.

Another place where we should say something if the content block is not present is on this panel:

[tanjoymor]

We should display this in an entirely different way to start.

I agree with this @mtias. I do think an explanation is needed, but the placeholder shouldn’t look like a nice piece of content. Something about it should look different, stand out more.

I also think the issue with the text is the actual wording. It reads more like what you said, placeholder content that is intended to be removed. It doesn’t say anything about removing it from certain templates will break their site.

(The grey square with diagonal line for image placeholders also makes things feel broken, that square would be better to include the word “placeholder” but that’s a different topic.)

[tanjoymor]

That one specifically is a single post format template.

@mtias So you created an empty “blog post”, paired it with the Single Posts template, and then put the content directly into the template and removed the Content block from the template.

And you did this because ? you’re not going to use “blog posts” on this site?

Again, just trying to understand what this use case is for regular users, how it works, and why someone should/would do this. Is this the best way to achieve this outcome? Is there possibly a better, more user friendly way that we should be focused on and promoting?

I’ve commented in other places, just because something can be done doesn’t mean it should be done. We shouldn’t be making it easy for regular users to make bad decisions. If there are quirky edge cases that someone might want to do, cool, let them via more complex, harder to find options. But focus on the intended and best practice use cases for everyone else.

[mtias]

The setup is pretty straightforward, just a template that uses the featured image but no title and no content blocks to display the post. The theme pulls the average color of the image and applies it as the background. The archive view is just showing multiple posts of that type so it looks like a stream, but it's all single posts.

It's just an example. Other cases are views like https://wpmovies.dev/movies/the-godfather/ where the description of the movie might be using the excerpt or a separate specific field and not the "content".

In any case, my main point is we need to make the placeholders intuitive and comprehensible in the first place. Adding locks can also help, but if a user was feeling the need to remove the content block they'll also get frustrated seeing a chunk of text that they seemingly can't remove but they want to.

[tanjoymor]

@mtias I'd love access to that wpmovies site to learn how it's setup. Though it appears to be using a custom theme, possibly with some custom coding.

The thing that I'm getting at here is more about the "out-of-the-box" experience of WordPress. The default behaviors that anyone not tech savvy, not using custom themes, not using custom code would experience.

WordPress itself is capable of anything a user or developer is capable of doing. But those custom cases aren't where the problems exist. The problems we see users struggling with, as explained in many comments on this thread, are with regular non-tech users simply trying to use the software, as is, to build a site with a normal theme and normal tools.

I agree that making the placeholders more intuitive in the first place is a great idea. But I guess the question is, how far do we want to go with guardrails for average users? How easy do we want to make it for anyone to use WordPress? And how much convenience can we get away with sacrificing for power users who are going to push the limits?

For me, it's not about preventing custom builds, it's about shifting the approach to custom builds that prevents average users from accidentally falling into that category unintentionally (which is what is currently happening).

In Classic themes, you had to understand accessing and editing the theme files to do advanced tasks and custom adjustments. It was hard (not impossible) for an average user to really break things. We've brought that developer level capability forward and made it much easier to break things. Does the situation maybe call for more of a theme level solution than a Core solution?

Browsers have incredible features behind a label for "developer tools" but the average user isn't going to venture there.

Would it be so bad for WordPress to implement a similar concept? To make the "out-of-the-box" experience viable and easy for anyone while adding menu items for "Developer features" where we put options that could break a site if you don't know what you're doing? Or a toggle that puts the Site Editor into a "Developer Mode" that opens up more (potentially damaging) options, while keeping them hidden for all other users? Basically imposing logical, best practice use case limitations as the default environment, with a single flip of a switch to unleash the full power of everything else (including the ability to delete the Content block from the Pages or Single Posts templates).

This could solve a lot problems for multiple components rather than focusing on one piece or one block at a time. But I'm not a developer and I have no idea if something like this is viable. But from a user perspective, it would make a lot of sense.

[mtias]

You are not far off from what the "content only" work is exploring #60021! A way to ensure regular users can do lighter touch edits without the complexity of the full editing experience. The content block should fall there with that interaction mode. It probably wouldn't even be selectable. I'd rather we take a more holistic approach instead of going block by block with exceptions or requiring themes to do things in a certain way.