When editing the page_for_posts page the canvas should match the front end

[jameskoster]

Setting a static home page unlocks an affordance to specify a separate page to display the post archive:

When presented in the editor the content of this page does not reflect what you see on the frontend. Indeed any changes you make are essentially ignored until you unset this page as the page_for_posts.

Here's an example of a perfectly reasonable user flow which behaves in a very unexpected way:

confusion.mp4

I appreciate this isn't really a bug – WordPress has always handled this the same way. But with all the blocks we've built for the Site Editor there's potential for us to do better in this specific instance. To kick off discussion, one idea would be for this page to display a single Query block, which cannot be removed. Perhaps some of the attributes are locked as well. Pattern transforms (#28736) could be possible.

It's worth acknowledging that this issue is not restricted to the page for posts. There are other templates in the site editor that should 'lock down' specific blocks. I think that is a slightly different issue though, and worth discussing elsewhere (#27848 (comment)).

Edit: This is somewhat related to #28341

[jameskoster]

I don't know that this necessarily needs design.

Essentially if I open the page assigned to page_for_posts in the editor, I should see the relevant query block from the home template if it exists, or the index template if it doesn't. Those blocks should of course be locked, and inherit attributes like posts_per_page from the site settings.

[jameskoster]

This issue is especially pertinent now that it is possible to directly move from editing a page to editing a template:

posts.page.mp4

Edit: Re-adding the needs design label. This needs some consideration to account for both classic and block themes.

[jameskoster]

It's actually possible to "break" the functionality currently by assigning the "wrong" template. Using a general page template would result in the posts page no longer displaying posts.

Initial thought: Since the template for this page resolves automatically, It should not be possible to change the template in the UI. Creating a new template should be possible once – this action spawns the home template (hopefully with a better name 😅).

Edit: After a chat with @youknowriad, it probably makes most sense to simply hide the template panel for this page for 5.8. This mimics how the classic editor treats this page.

[creativecoder]

Here's an experiment that allows editing the Posts page template (and any other page template) when editing a page: #32022

[jameskoster]

It would be nice to revisit this now that the site editor is live.

One option might be to redirect folks to the Site Editor and open the home or index template when they edit this "page". This would solve the awkward experience where content added to the page never actually appears on the frontend.

Another option would be to open the template editor that exists in the post editor.

[paaljoachim]

What if clicking the posts page be it the front page or a designated posts page would show the Query Loop block in place with a kind of default block structure in place? This way one still have access to only the Posts Page outside the site editor.

Going from currently this:

To

Something like this:

[jameskoster]

Yup, that is another option. But it's tricky for a few reasons:

• We'd need to hide most options on the Query block since they would be inherited from the URL and other global settings (posts per page etc)
• The Query Template would need to be synced with the underlying template
• The UI must be clarify that changes to this Query could affect other pages
• We'd need to prohibit the addition of blocks outside the Query – that is template editing territory
• Should folks be able to edit the posts returned by the Query?

All of this might result in too much of a detachment from the expected page editing experience.

[paaljoachim]

@aurooba made this associated issue:
[FSE] When static front page/posts page is set, disable the page editor, redirect to Site Editor
#38389

Also sharing the Core Editor Slack conversation that is also happening:
https://wordpress.slack.com/archives/C02QB2JS7/p1644323569973349

[aurooba]

I'm going to go ahead and close #38389 and add my thoughts here because it makes a bit more sense to keep it all in an issue:

---

This is a confusion I encountered myself – despite understanding the WordPress Template Hierarchy extremely well – and have watched others encounter too. It stems from being able to do things one way before and having the paradigm change in FSE.

When you set a page as the static front page in a block theme, you should be editing the Front Page template in the Site Editor rather than in the Page Editor. However, because you can still add things to the Page you set as the Front Page, it's easy to get confused and starting working on the page there.

When a Page is set as the Posts page, there is a little notice in the snackbar letting you know you are editing the Posts page.

This is better, but still not enough, because the phrasing leads you to believe that you are making actual edits to the Posts page, when in fact, edits here will do nothing, because you should be editing the Home template in the Site Editor (the fact that it's called the Home page, directly coming from the Template Hierarchy is super problematic and I'll leave that for another issue I'll inevitably make).

Here's what I'm thinking

When a Front Page is set, the Block Editor should be disabled and have a button to take you to the Site Editor, the same goes for the Posts page. Or better yet, let's make it automatic! Clicking Edit on the page set as the Front Page or the Posts page could automatically redirect you to the appropriate template in the Site Editor.

[carlomanf]

I think redirecting to the site editor makes sense. Maybe the code from #36294 could be re-purposed for this.

[jameskoster]

Noting that this experience still feels buggy. On the backend, the preview frame and edit experience still show something completely different to what you see on the frontend.

Backend

Frontend

[ellatrix]

This doesn't seem like a regression, so punting

[jameskoster]

I'd appreciate more testing, but this may be fixed now.

Backend	Frontend

Note that the correct template is referenced in the Inspector, compared with the screenshots above.

Tentatively closing, but let's re-open if there reports to the contrary.