Site Editing: Explore how we might set what's displayed on the front of a site from within the site editor

[p-jackson]

What problem does this address?

The site editor is replacing many of the functions of the customiser. One important feature of the customiser is to set which page appears on the front of the site.

As the site editor is getting developed now it seems to me that we should be exploring ways users can set the page they're working on as the front page.

I think this means having a way to set the page_on_front site option, but maybe we should explore ways to set show_on_front and page_for_posts too? Are they still relevant in a full-site editing world?

What is your proposed solution?

No solution here, this is more of a todo task :) @jameskoster

[simison]

This could be a feature not just in site-editor, but in regular page editor as well.

[vindl]

As a first pass maybe we could expose this option in the document settings dropdown. It would only be enabled in page editing context (when specific page is selected for editing) and disabled when we are editing templates and template parts.

[overclokk]

I think this means having a way to set the page_on_front site option, but maybe we should explore ways to set show_on_front and page_for_posts too? Are they still relevant in a full-site editing world?

From my point of view yes, I think they are relevant too.
Maybe should be explored other option too, like allowed comments, permalink and so on.

[jameskoster]

We need to carefully consider the relationship between show_on_front and page_for_posts.

It's easy to imagine a "Set as homepage" checkbox somewhere in the Inspector when editing a page. But users need to be aware that doing this will pseudo-remove their post archive, unless they specify a page to display it on.

Perhaps a modal appears when that checkbox is toggled on, explaining the situation and offering an optional shortcut to create a new page for posts?

[jameskoster]

Finally I have something to share here :)

I tried a number of different approaches where folks could manipulate the home/posts pages settings directly in the editor, but ran in to lots of issues due to the complexities surrounding how the posts page actually works, and its relationship with the home page setting. Not to mention how templates like front-page and home factor in to the equation 🤯

In the end, applying a layer of friction by opening the settings in a separate view felt like the most effective solution.

Flow: Setting a home page

setting.a.home.page.mp4

In this video you'll see my site is currently set to display latest posts on the homepage. While editing the "Welcome" page, via the new page card at the top of the Inspector I am able to access the home page settings through a modal. There I can configure the home page display settings. In the posts page dropdown there is an option to draft a "blog" page as the new home for posts. Upon save a number of things happen:

• "Welcome" is set as the home page in the reading settings.
• The "page" icon in the inspector is replaced with the "home" icon.
• The "page" type definition is updated from "page" to "home page".
• The template automatically switches from page to front-page. (This would only occur if the front-page template exists, otherwise page is retained).
• A "Blog" page is published and set as the posts page.
• The "Blog" page template is updated to home or index depending on which templates are present.

On that last point, it's important to note that while subsequently editing the posts page ("Blog" in this case), the canvas really must reflect what appears on the frontend. IE it should display a list of posts rather than the page content. This will resolve #29821.

To clarify, here's what I should see when I edit the posts page:

edit.posts.page.mp4

Note the template, and the icon / grey page type declaration in the page card.

Needless to say, while editing the posts page (or the home page for that matter), certain blocks will need to be locked (#29864) in order to stop users wreaking havoc by doing something like; editing the posts page, deleting the posts list and replacing it with content instead.

Page card

In other editor views, the inspector displays a card detailing the selected element. E.g. blocks and templates:

Block	Template

I am proposing that we bring this to the Page tab as well. This not only provides access to the home page settings via ellipsis menu, but also creates a space to outline other important details such as the page type (regular page, home page, posts page, privacy policy page... maybe shop page if plugins like WooCommerce integrate). It could even become a home for the page name input and permalink... I kept the scope narrow for now though.

Here's how the Page card would adapt for the use cases required for home page configuration:

Editing the home page	Editing the posts page	Editing a regular page

Note the icon and page type (grey text) changing in each screen shot. It may be that we don't need the "Page" demarkation for regular pages since the "Page" tab is just a few pixels away and does pretty much the same job :)

The finer details (button labels, icons etc) could probably use some refinement, and there is perhaps a case to be made for moving this to the document dropdown proposed in #27093. But as a starting point this feels OK to me.

Editing the template applied to a static home page

What follows isn't necessarily something we need right now, but it serves to illustrate why putting the settings in a modal is the way to go.

In the video below I navigate from editing the "Welcome" page, to editing the "front page" template. I then change the home page setting to display a new page titled "Hello", and see that change immediately reflected on the canvas.

setting.a.homepage.from.a.template.mp4

A simpler initial implementation?

Sheesh that was a lot 😭 Turns out the home / posts page rabbit hole goes quite deep, and there are many 🐉's lurking in the depths.

It may be simpler initially to implement the page card, but link out to the existing settings page in wp-admin rather than displaying them in a modal. This would be quite disruptive if you've made changes to the document you're editing. But it would be a simple way of resolving the issue in the OP.

Either way, it seems vitally important to me that

1. The lock status for blocks (On Locking and TemplateLocking #29864) is implemented, and
2. The canvas matches the front end (When editing the page_for_posts page the canvas should match the front end #29821)

In order for home page manipulation in the block editor to feel remotely intuitive.

[creativecoder]

Related to this issue, the posts page (page_for_posts) cannot currently use the Gutenberg editor (via a filter), unless it already has post_content. Here's the relevant Trac issue for adding filtering: https://core.trac.wordpress.org/ticket/45537.

[jameskoster]

I shared an idea in #20338 (comment) which is somewhat relevant to this issue.