Allow block editor to be used on the posts page using filters

[cameronjonesweb]

Currently it doesn't seem possible to use filters to make the block editor on the posts page unless the page already has content. This is a regression from the Gutenberg plugin where this was possible. Considering it is and was possible to edit the posts page using the classic editor using filters, it makes sense that we can enable the block editor to be used on the posts page.

[swissspidy]

The patch looks reasonable, but what‘s the use case for being able to edit the posts page?

[cameronjonesweb]

Treating the posts page like an archive. We have get_the_archive_description for post types and taxonomy terms, content on the posts page serves a similar purpose. I use it on my site and I've had to do it on a number of client sites too

But like I said, it's already possible, it just can't use the block editor.

[hannahmalcolm]

This is something that every content marketer I've run into wants as well. They want to add content to the top of the "Blog" page.

I've had requests for social media feeds and all sorts of things, so it's not just "simple" text content. Being able to use the block editor for this page gives a consistent user experience and allows for some of the more dynamic and complex blocks to be added.

[swissspidy]

This becomes more relevant when there's gonna be a "Posts Page" block at some point. Moving to Future Release.

[swissspidy]

#47198 was marked as a duplicate.

[Fantasy1125]

@swissspidy In our agency we have a lot of these use cases as well. Archive pages need to have a certain amount of content to rank good in Google to improve the SEO. Almost all of our clients need this kind of functionality. We would really appreciate that this patch would be merged.

[gchtr]

I can only agree with @hannahmalcolm and @Fantasy1125.

We recently added our own archive block that can be used on any page that acts as a post type archive. This way, our clients can add blocks before and after the archive output. It works for all custom post types, but without this patch, we can’t make it work for the posts page without first adding some dummy text to make the switch to the Block Editor. We would love to see this patch being merged soon.

[ArnaudBan]

My use case :

I use a filter on 'editor.PostFeaturedImage' to add more option related to the featured image. It works nice but not on the posts page because it doesn't use the block editor like all the other pages of the site.

[grantmkin]

It would be great to get this patch lined up for the next WordPress release!

Allowing the block editor to be used on the posts page (via a filter) is needed for the full site editing work happening in Gutenberg. See these issues which reference editing the posts page, for example: ​https://github.com/WordPress/gutenberg/issues/29821 and ​https://github.com/WordPress/gutenberg/issues/28341#issuecomment-801911429

[youknowriad]

Is there any reason why we can't use Gutenberg on the posts page by default? Can we make a patch to do that instead?

[grantmkin]

Is there any reason why we can't use Gutenberg on the posts page by default? Can we make a patch to do that instead?

@youknowriad Trying to understand the context around this I found #17470. The content editing UI is hidden on the empty page_for_posts page in an effort reduce user confusion, since themes typically don't display the post_content of that page.

Is there a good way to disable post_content editing when loading Gutenberg for that page? If not, that seems like a reason to continue disabling Gutenberg by default, but adopt the change proposed in this ticket to allow filtering (at least for now).

With the filtering enabled, in the near term I imagine the Gutenberg plugin would enable the block editor on the posts page for block based themes and load the appropriate template for editing, which would solve the problem of edits for that page not being shown by the theme 🎉.

[youknowriad]

When I try to edit the "posts" page, I'm shown the classic editor with the "content" area visible and editable, so I'm not sure why we'd want to do otherwise in Gutenberg.

[knutsp]

Replying to youknowriad:

When I try to edit the "posts" page, I'm shown the classic editor with the "content" area visible and editable, so I'm not sure why we'd want to do otherwise in Gutenberg.

I do sometimes, and sometimes not, depending on what site I'm on. I have not been able to find out what triggers the content area to be shown, despite being the posts page. There was a change many years ago that introduced a non-editable content area, but it don't always work. May be it shows if it's not completely empty, even if it's invisible, like empty html elements.

As I wrote on a related ticket, this should be investigated, so that the behavior is consistent, from site to site and across supported editors.

[youknowriad]

So right it seems that we have many inconsistencies, the most visible one is that:

• if the page has content when it's assigned as a "posts" page, Gutenberg shows
• if it's empty, classic editor shows.

I think the first step would be to always show "Gutenberg" and clear that confusion.

We can always consider a content-less Gutenberg page after but for me this also raises the question about removing the check that shows classic editor for content less CPTs entirely.

Summary of changes

• Default to the block editor when opening the page_for_posts page in the editor
• Add a notice to the block editor for this page: "You are currently editing the page that shows your latest posts."

Trac ticket: https://core.trac.wordpress.org/ticket/45537

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See ​GitHub Pull Requests for Code Review in the Core Handbook for more details.

[grantmkin]

When I try to edit the "posts" page, I'm shown the classic editor with the "content" area visible and editable, so I'm not sure why we'd want to do otherwise in Gutenberg.

Note that I believe this was an unintended regression, more details at: https://core.trac.wordpress.org/ticket/52995#comment:5

I think the first step would be to always show "Gutenberg" and clear that confusion.

This makes sense to me, in that showing the classic editor for this one particular case can be quite jolting.

Here's a first attempt at that, which includes adding the same notice in the editor: ​https://github.com/WordPress/wordpress-develop/pull/1265

[SergeyBiryukov]

Thanks for the PR! This looks good to me at a glance, I would suggest a few minor changes:

• It looks like unit tests currently fail due to an extra comma on line 2687 inside the sprintf() call. The PHP compatibility check displays a notice: "Trailing comma's are not allowed in function calls in PHP 7.2 or earlier".
• The function name should probably start with an underscore, for consistency with _wp_posts_page_notice().
• Instead of always hooking the function to admin_notices and then checking the post ID inside the function, let's perform that check in wp-admin/edit-form-blocks.php, for consistency with how it's done for the classic editor in wp-admin/edit-form-advanced.php​.

[grantmkin]

Thanks for the prompt feedback!

I've made all three of the suggested changes in ​https://github.com/WordPress/wordpress-develop/pull/1265/commits/30dd67501b2756dd799b85e82fffcbf4ff510099.

I hooked _wp_block_editor_posts_page_notice into admin_enqueue_scripts (but conditionally based on $post->ID), thinking that themes/plugins might want to unhook it to remove or override the notice. For example, they might provide functionality specific to editing the Posts page that makes the notice unnecessary.

[audrasjb]

Patch tested

[audrasjb]

I applied the PR and it works really good on my side.

That's indeed the best solution for now.

Also, given FSE’s first steps are going to ship in 5.8, I think it's the best time to get rid of that kind of small inconsistencies in our templating system :)

Moving for commit consideration.

[whyisjake]

In 51116:

Editor: Ensure that the block editor can be used on the page post type.

Additionally, add a notice for when you are editing the "latest posts" page.

Fixes #45537.

Props cameronjonesweb, swissspidy, hannahmalcolm, Fantasy1125, ArnaudBan, grantmkin, youknowriad, knutsp, SergeyBiryukov, audrasjb, whyisjake.

[audrasjb]

(adding needs-codex as well, even if I'm unsure the blog page is somehow described in the end-user docs)

[SergeyBiryukov]

In 51158:

Coding Standards: Use consistent formatting for _wp_posts_page_notice() and _wp_block_editor_posts_page_notice().

Remove redundant casting to int for post ID, which is always an integer.

Follow-up to [51116].

See #45537, #52627.

Merged in https://core.trac.wordpress.org/changeset/51116