WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 months ago

Last modified 2 months ago

#45537 closed defect (bug) (fixed)

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

Reported by: cameronjonesweb Owned by: SergeyBiryukov
Milestone: 5.8 Priority: normal
Severity: minor Version: 5.0
Component: Editor Keywords: has-patch commit needs-dev-note needs-codex
Focuses: Cc:

Description

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.

Attachments (2)

45537.diff (720 bytes) - added by cameronjonesweb 3 years ago.
Capture d’écran 2021-06-08 à 23.27.11.png (318.6 KB) - added by audrasjb 3 months ago.
Patch tested

Download all attachments as: .zip

Change History (27)

#1 @swissspidy
3 years ago

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

#2 @cameronjonesweb
3 years ago

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.

#3 @hannahmalcolm
3 years ago

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.

#4 @swissspidy
3 years ago

  • Milestone changed from Awaiting Review to Future Release

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

#5 @swissspidy
2 years ago

#47198 was marked as a duplicate.

#6 @Fantasy1125
2 years ago

@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.

#7 @gchtr
2 years ago

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.

#8 @ArnaudBan
21 months ago

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.

#9 @grantmkin
5 months ago

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

#10 @youknowriad
5 months ago

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?

#11 @grantmkin
5 months ago

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 🎉.

Last edited 4 months ago by SergeyBiryukov (previous) (diff)

#12 follow-up: @youknowriad
5 months ago

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.

#13 in reply to: ↑ 12 @knutsp
5 months ago

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.

#14 @youknowriad
5 months ago

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.

This ticket was mentioned in PR #1265 on WordPress/wordpress-develop by creativecoder.


4 months ago

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.

#16 @grantmkin
4 months ago

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

#17 @SergeyBiryukov
4 months ago

  • Milestone changed from Future Release to 5.8
  • Owner set to SergeyBiryukov
  • Status changed from new to reviewing

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.
Version 0, edited 4 months ago by SergeyBiryukov (next)

#18 @grantmkin
4 months ago

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.

#19 @audrasjb
3 months ago

  • Keywords commit added

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.

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


3 months ago

#21 @whyisjake
3 months ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

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.

#22 @audrasjb
3 months ago

  • Keywords needs-dev-note added

#23 @audrasjb
3 months ago

  • Keywords needs-codex added

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

#24 @SergeyBiryukov
3 months ago

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.

Note: See TracTickets for help on using tickets.