Front Page template: Include homepage settings

[jameskoster]

Front Page is the only template that will unilaterally resolve to the site homepage regardless of:

1. Which other templates exist.
2. Whether the homepage is set to display latest posts or a static page.

We can do better, and at least show a link to Reading settings, there. I.e. to /options-reading.php. Mockup:

If additional tools turn out to be needed, this could be a good place to surface homepage settings in the site editor. Mockup:

When set to display latest posts, settings relating to the blog (e.g. posts per page) can be surfaced.

When displaying a static page, the user should be able to choose which page content (page_on_front) to pull in, and which page should serve as the posts page (page_for_posts).

Tasks

1. Add a hyperlink to "Reading settings".
2. If additional features are needed, add additional options.

[annezazu]

Noting that we should consider surfacing these homepage settings when live previewing a block theme. Knowing what's going to happen with your homepage template when switching is critical and can change based on the theme. This can worsen due to this issue #25071 where you can face a form of content loss when switching and losing homepage content depending on how the template was setup.

[richtabor]

We really need to figure out a way to consolidate this. Would be nice if it wasn't theme dependent, but I don't know what that looks like.

I still think it's confusing to have a "Front Page" within the editor, and an option to change its content via another page (like the "Welcome" page is referenced above. I wonder if something along the lines of a "Make this my homepage" setting in the Pages view, which would then make that exactly the homepage, would work better than the template v. blog v. page confusion we're facing now.

And then perhaps the details view on the left would always reference the site's homepage, with surfaced controls relevant to the blocks on the page (such as posts per page, if there is a query loop on the page).

[SaxonF]

I wonder if something along the lines of a "Make this my homepage" setting in the Pages view, which would then make that exactly the homepage, would work better than the template v. blog v. page confusion we're facing now.

And then perhaps the details view on the left would always reference the site's homepage, with surfaced controls relevant to the blocks on the page (such as posts per page, if there is a query loop on the page).

The template hierarchy is just a source of confusion all round and I'd love to discuss whether there is a pathway towards simplifying. Templates just being "dumb" wrappers around pages. Dream state:

• Homepage is just a page that can be set as home as @richtabor suggested. You can apply whatever template you want to the homepage
• Every post type has a collection/single page that can use whatever template you want. Page settings include url structure.
• Every taxonomy has an index page that can use whatever template you want.
• Blog/events/portfolio/whatever are just normal pages with the query loop inserted that queries a specific post type (or in future many).
• Utility pages like 404 are just pages and can use whatever template you want

If you don't want a blog, just remove the blog page.

[jameskoster]

Agree the intrinsic link between templates, 'dynamic pages', and settings makes for a very opaque experience, and that "Dumb" templates could make more sense in the site editor/block theme world.

Homepage is just a page that can be set as home as @richtabor suggested. You can apply whatever template you want to the homepage

This is already possible for regular pages, and would work for dynamic pages like the blog, shop, portfolio, etc. if Saxon's proposal above was implemented. The issue is that Front Page will continue to override whatever template is applied unless it's removed, or its behavior is adjusted. This could have very serious backwards compatibility consequences so would require very careful planning. One option might be to remove it's special behavior (IE convert it to a dumb template) and assign it to the current homepage automatically on update. The same treatment could potentially be applied to similar templates like home.html, category-recipes.html, etc.

One other consideration is theme switching. Ideally themes retain the ability to be somewhat opinionated about the homepage appearance (that's what templates like Front Page and Home were created for initially) without significant user intervention. Perhaps that could be handled a part of a theme onboarding experience?

[richtabor]

The issue is that Front Page will continue to override whatever template is applied unless it's removed, or its behavior is adjusted.

Wouldn't that still be the "Home" page though? Do we need a different details view (or any indicator) in the UI if your theme uses a front page, posts for home, or home template?

[jameskoster]

I was mostly responding to this part: "You can apply whatever template you want to the homepage", and the "dumb template" idea in general when Front Page exists. Getting the backwards compatibility right is tricky, so perhaps that's better discussed elsewhere.

Do we need a different details view (or any indicator) in the UI if your theme uses a front page, posts for home, or home template?

When Front Page exists the user cannot swap the template applied to their static homepage, and it's not really clear why. Similar for Home – you have a "Posts page" alongside your other pages, but you cannot change the template. Basically, for these cases (and for taxonomy archives) I think we need to try and combine the template in the page in the UX so that the user interprets them as one and the same. Perhaps we can achieve this by leaning into patterns, IE:

• Hide the template switching UI when editing those pages, replacing it with;
• Front Page / Home pattern suggestions as a way of changing the overall layout

[jameskoster]

I wonder if something along the lines of a "Make this my homepage" setting in the Pages view

I made a quick mockup of how this might work in the details panel:

If the current homepage is set to display latest posts the user is prompted to create a page (or choose an existing one) for the blog. They can skip this if they don't need a blog at that moment. If no blog pages exists then perhaps the [+] button in the Pages panel could include a "Add a blog" option. This would ensure the full scope of the homepage settings are accounted for in the Site Editor.

[getdave]

I've been thinking about this as well so I was pleased to find this Issue and the mockups. To avoid cluttering this Issue I've made another Issue on the specific point of finding and editing the Home page.

I'm not sure if I'm duplicating here but I want to avoid additional noise - let me know if you think it's a duplicate.

Note: my rationale in #56244 is based on observations from several user testing sessions.

[annezazu]

Noting that the details view has been removed in favor of the Inspector so these designs will need to be refreshed: #59689

[jameskoster]

Noting that the details view has been removed in favor of the Inspector so these designs will need to be refreshed: #59689

I updated the design to reflect this change. The UI in the popover more accurately reflects the reading settings. Feedback welcome!

[richtabor]

Question. If a theme does not have a frontpage template, then they wouldn't have these settings easily available to set these reading settings, yea?

Would this same setting be available on whatever the home of the site is, regardless of template?

[jameskoster]

@richtabor I'm working on a few issues closely-related to address that, feedback very welcome:

• Provide a way to set the homepage in the site editor #63666
• Create and set a page_for_posts in the site editor #63667
• When editing the posts page, include relevant template settings in the Inspector #63662

These would allow users to (indirectly) update the reading settings in a variety of flows. I don't know that we're ready to fully replicate the reading settings UI in the Site Editor yet, given we'll eventually get to that with the admin redesign project (#53322).

[jasmussen]

Revisiting this one. The fact that this template exists, and as mentioned, unilaterally overrides other template settings, that is a compelling reason to show—if not display options—then at least something that explains uniquely what this template does. At the very least, we can do better than what's shown at the moment:

Rich makes good points, though. This is optimizing only for one type of theme, the one that includes a front-page template. Which means any reading settings we surface here won't benefit other themes. It may also turn out to be a rabbit hole, as alluded to here, to actually pull in the content of other templates inside one template. How does that actually get represented in the list view, for example?

None of that is actually saying we shouldn't necessarily surface reading settings here. But perhaps we can start smaller, first, and then see where that takes us:

• Start by landing a fix to Provide a way to set the homepage in the site editor #63666, which is a quick win and provides one half of the flow.
• Perhaps improve the description for this template, make it more verbose, and maybe even include just a link to the WordPress reading settings. For the moment, that means /options-reading.php.

What do you think?

[jameskoster]

I don't mind starting simply by adding a link to reading settings 👍