Hide the "Post *" blocks in the post editor

[jameskoster]

While editing a post it's currently possible to insert all manner of data driven blocks like "Post Content", "Post Date", "Post Title", "Post Comments", etc.

Some of these work. The Post Date block will display the publish date of the post being edited. Others do not work, like Post Content.

Do these blocks have a place in the post editor at all? I worry that when you start inserting things like Post Comments in the post itself users can be misled in to believing that they are editing the template. Or being confused when they see two instances of the comment list on the frontend. For 5.8 we might consider hiding these blocks in the post editor Inserter, and revealing them in the template editor only.

The only caveat I can think of is the Query block. Perhaps if you add a Query to a post, it should be possible to insert the Post blocks, but only inside the Query block.

[jameskoster]

The only caveat I can think of is the Query block. Perhaps if you add a Query to a post, it should be possible to insert the Post blocks, but only inside the Query block.

This does raise a question that may need some design exploration to answer: What happens if you drag a Post Excerpt block out of the Query and into the root level of the post?

[priethor]

I agree these blocks can be misleading in a post context outside the Query block, and the Post Content block can lead to some strange recursion:

Grabacion.de.pantalla.2021-05-14.a.las.13.29.48.mov

It seems to me that at least the Post Content block should not be available in this context, given the message it displays the user, and I can't seem to find use cases for the other ones.

[carolinan]

There are use cases for things like post categories and tags, post date and author because not all themes display this and might not have options to display them.

[jameskoster]

There are use cases for things like post categories and tags, post date and author because not all themes display this and might not have options to display them.

Wouldn't the argument there be: Create a template and add the blocks there?

Otherwise you could end up with some posts with meta, and some without. And then if you switch themes, some could have double meta 🙈

[justintadlock]

Right now, I use post-meta types of blocks alongside per-post custom info/text/etc. when creating various hero/cover headers alongside a custom template that removes the site title. These new blocks have allowed me to do that without manually re-writing the title, author, date, etc. As some of these blocks mature and templating in FSE becomes better, I'll need this less and less. But, for now, I have a use case at least.

The Post Content block is the only post-related one that I cannot see needing except when nested inside of Query. I can't imagine needing the comment-related blocks.

[carlomanf]

I left some comments at #30668 that apply equally to this issue.

I will also add this, in case it helps clarify what I was trying to say over there. As a plugin developer, I'm generally not fussed about what default design decisions the core team makes, and I'm happy to stay out of those discussions. However, I am interested in how they are implemented, and whether there are filters or similar mechanisms that I can use to reverse those decisions if I need to.

Furthermore, I think it misses the point to ask me to come up with "use cases" off the top of my head, to justify the need for such mechanisms. At the moment, I don't have a specific objection to the proposal here, but who knows whether that might change a year from now?

I think that allowing plugin developers the option to reverse decisions like this "just in case" is a good idea, because it's a reason they choose to develop for this platform rather than another platform.

[jameskoster]

Furthermore, I think it misses the point to ask me to come up with "use cases" off the top of my head

That's fair. Perhaps a better approach would be to ask: In the overall UX, how defined do we think the lines between template and post editing should be for an average end-user?

Is the concern that folks less experienced than @justintadlock will conflate post and template editing legitimate? If so, we may need to take a harder line. If not then perhaps (as suggested) only things like Post Content and the comment blocks should be omitted from the post editor.

While answering these questions it seems important to consider not only where things stand today, but where we'll be in the near future. FSE may still be a way off on the horizon, but block template creation/editing will arrive very soon in 5.8.

My hypothesis is that clearer lines might help people better understand this relatively complex new feature (creating and editing templates). This can be important if we consider a future where plugins may need to toggle visibility based on whether the user is editing content or template. For example I don't think it makes sense for SEO features to be visible in the template editor. Likewise a Product Filtering block serves no purpose in the post editor.

Either way, it seems reasonable that a developer could be able to filter the default configuration, whatever that ends up being.

[carlomanf]

Either way, it seems reasonable that a developer could be able to filter the default configuration, whatever that ends up being.

If so, then someone having a rare use case need not cause any headaches to the decision making process here, as those people can just be directed to install a mini-plugin that modifies the filter.

[annezazu]

Noting the current experience as these blocks are visible in the Inserter, no longer have the "post" name appended to the front, and are deprioritized much further in the Inserter groupings. In my mind, this adds some friction that satisfies this issue. Adding this to the Polish board though in hopes of a final say perhaps from @WordPress/gutenberg-design

[richtabor]

I actually think they can be useful. The single post views on my blog use a book cover pattern with the post title in it, so I can opt to use post titles or not on single views.

I lean towards consistency, even if it's a bit odd. Even perhaps bringing back template parts into pages. 🤷‍♂️

[jameskoster]

Given the de-prioritisation in the Inserter and much clearer separation between template + page editing I agree it's fine for these to remain. Let's close this one.