Include homepage in page lists when set to display latest posts

[jameskoster]

The default configuration for the majority of WordPress sites is to display the latest posts on the homepage. However, the current edit flow for this setup is awkward and confusing for most users.

Identifying the Problem

The initial challenge in the edit flow is simply finding the page. Since the homepage displaying the latest posts is not technically a page, it does not appear in the page management interface (pages data view). This discrepancy means that users are directed to an area that does not support the editing task.

There are two primary pathways to edit the homepage in this scenario, neither of which is ideal:

1. Site Editor Root Frame: Users can click the frame at the root of the Site Editor. This method is not clear to new users, only becoming so through experience.
2. Templates Section: Users must identify the correct template to edit from options like Front Page, Blog Home, or Index. This process is complex and often beyond the grasp of those without technical expertise.

Once users navigate to one of these pathways, they encounter a template editing context filled with confusing titles such as "Blog Home" or "Index" and technical descriptions like, "Displays the latest posts as either the site homepage or as the 'Posts page' as defined under reading settings. If it exists, the Front Page template overrides this template when posts are shown on the homepage." This environment might be clear to seasoned theme developers, but it can overwhelm average users.

Proposed Improvements

To improve the user experience, I suggest the following changes:

• Force show_on_front to always be page (or maybe deprecate this option altogether)
• Automatically register a page object on fresh installs
  • Set this page as both: page_on_front, page_for_posts
• Simplify reading settings UI

Original issue

### The problem

In WordPress 6.5 the "Pages" panel in the site editor includes links to edit special 'pages' that resolve to display templates, specifically:

• Posts page (when homepage is set to display latest posts in reading settings)
• 404
• Search results

For WordPress 6.6, this sidebar is being replaced with the "List" layout in data views:

A consequence of this replacement is the loss of those aforementioned links.

Continuing to provide shortcuts to the 404 and search results templates seems useful, but it's probably most important to provide access to edit the homepage when set to display latest posts.

A solution

A 'Utility' view accessed from the footer of the Pages sidebar could include any templates users often consider to be pages, IE:

• Blog Home / Front Page (when homepage is set to display latest posts)
• 404
• Search results

In the future this could be expanded to include general archive templates like category, tag, author, etc. and any taxonomy-term-specific templates e.g. category-recipes, author-admin.

[jameskoster]

I noticed an item in #59659 which describes a "Utility" view which includes 404 and search results.

That seems like the path of least resistance here, and avoids mixing record types in a single view which can often lead to awkward experiences due to incompatible fields.

[jarekmorawski]

To me, Utility feels a bit foreign in this context because the other items are related to page statuses and Utility is more of a type or function.

Maybe we'd move the link to the bottom of the sidebar, similar to the manage links under Patterns and Templates?

[jameskoster]

Yup, I think that can definitely work. The footer property of SidebarNavigationScreen can handle this placement.

[youknowriad]

Personally, I'm not sure we should be showing another data view for utility pages. There will be a lot of small issues like what happens when you click "back" on these pages, if these have a canonical url, you'll probably be back to the "templates" page.

Continuing to provide shortcuts to the 404 and search results templates seems useful

I understand the reasoning behind this: "Templates" is too confusing for regular users and they consider these as "pages" but I'd argue that trying to hide this distinction is in fact more confusing sometimes. So I wonder, how can we measure this? How can we ensure that it's actually solving an issue rather than adding more confusion.

For me it feels like a half baked solution: I think if we are to merge templates and pages, we should merge them fully (in the UI I mean) :P

[jameskoster]

we should merge them fully

I would support that, but wouldn't it create technical issues? Templates and Pages do not share all fields, so how would things like sorting & filtering work?

[youknowriad]

I would support that, but wouldn't it create technical issues? Templates and Pages do not share all fields, so how would things like sorting & filtering work?

Yes, indeed it's complex maybe it's fine to keep them separate like "static pages" and "dynamic pages" but my point is that we shouldn't have templates both in "templates" and "utility pages".

[jameskoster]

It may not be ideal, but to your point about confusion there are a couple of hints in the UI that indicate these are special/different to regular pages;

• Layout icon applied to menu item
• Placement at the bottom of the sidebar
• We could try 'Utility' as the label rather than 'Utility pages'. Or another label entirely. 'System pages' maybe? I'm open to ideas there :)

Alternatively we could be more explicit; name the view "Page templates" and also include templates like page.html.

In any case, as it stands this could arguably be called a regression from 6.5. It's hard to say how often folks are using the existing shortcuts, but I'm a little anxious about removing them entirely.

[colorful-tones]

With WordPress 6.6 Beta 1 targeted to be released in less than a day - Editor Triage Leads will move this to Punted to 6.6.1 for now.

[ellatrix]

I don't think this is material for a point release? Also how is this both an enhancement and a regression?

[jameskoster]

I updated this issue to concentrate solely on the "homepage set to display latest posts" issue(s).

[jameskoster]

I think if we are to merge templates and pages, we should merge them fully (in the UI I mean) :P

@youknowriad Noodling on this a bit, here's a potential design:

• "Latest posts" is presented as a page in the Pages list.
  • This is a special page, hence no author, status, publish date, etc.
  • It also has a reduced set of actions, for instance it cannot be deleted.
  • Also not eligible for bulk editing.
  • Clicking it takes you to a page-centric edit experience with a customized Inspector.
    • The Template tab in the Inspector provides quick access to template settings.
• The Single Post template could be included in the pages list too, as a child of the Latest posts page
  • The edit experience would be similar, with an added affordance to switch which post is loaded into the template (I believe the site editor had such a feature many moons ago).
  • In terms of routing, this would be a different experience the one accessed via the Templates data view. Specifically: The Inspector includes tabs for the template and the post, plus the aforementioned post switcher.
  • Category, Tag, Author templates could also be surfaced this way.

[jameskoster]

Stripping the above back to an even smaller change; surfacing the latest posts page in the pages data view:

• "Latest posts" is presented as a page in the Pages list.
  • This is a special page, hence no author, status, publish date, etc.
  • It also has a reduced set of actions, for instance it cannot be deleted.
  • Also not eligible for bulk editing.
  • Clicking it takes you to a page-centric edit experience with a customized UX;
    • Unlock template editing: Allow users to select and edit template blocks directly in this context.
    • Hide irrelevant page meta in the Inspector (status, template, author, publish date).
    • Surface template settings (posts per page) in the inspector.

cc @WordPress/gutenberg-design @youknowriad for feedback.

[jasmussen]

Can work. I wonder if that gray "homepage" chip can become blueberry with white text when the row is selected? And can/should that same chip be integrated in the description area on the right in the editor too?

[youknowriad]

I want to mention that technically is a bit too complex to that the point that I wonder if it's worth it. It's doable but without issues / bugs / big changes.

Basically we'll be showing two separate "entities" in the data views.

• How do you apply filter/sorting... knowing that today these things are handled server side and can be altered by plugins.
• How do you handle quick edit, bulk selection
• We need to refactor a lot of "actions" and "fields" to make them be fields that can be used across post types which is not something we optimized for and likely be a big technical change.

[jameskoster]

Yes this issue brings into stark focus the complexity burden that the template hierarchy places on users 🙃

I wonder if it's worth it

I just want to re-iterate the problem, to make sure we're agreed that something needs to be done...

• The default WP configuration sets the homepage to display latest posts.
• In the site editor it is not obvious how to edit this 'page'.
• Editing the homepage is a very common task, often the first thing folks want to do after setting up their site.
• It's not included in the Pages section, which is where a user would likely go to find it.

In regards to the questions, the idea was to 'hard-code' a page in the database. In terms of edit-ability and behavior it would be very similar to page_for_posts. So despite having a one or two of special rules (can't be deleted), it would still have all the standard meta data, so filtering / sorting would work as expected. It also means the page would appear in the wp-admin pages list too.

Does that make it sound any more (or less) feasible?

[youknowriad]

In regards to the questions, the idea was to 'hard-code' a page in the database.

You say in the "database", what does that mean. Actually create a page object? This is not how things work, today there's no "page" in the database, so the endpoint to fetch pages... don't return anything. If we are to force the presence of a page object in this case, we need IMO to create a trac ticket and discuss what that means for the WP framework (storage, when to create a page, is it always present when you install WP, what's the impact on the different php functions...)

[jameskoster]

Actually create a page object?

Yes, I appreciate I am trivialising 😭

Let's continue to explore other design options. Perhaps there's something we could do with the Navigation section to surface the homepage when set to display latest posts. That could make it more easily accessible in the site editor, but obviously require some re-imagining of the Navigation section.

It wouldn't solve the confusion around why this page doesn't appear in the page management view, but perhaps a more polished Navigation section would make that issue less prominent.

What do you think @richtabor ?

[youknowriad]

To be honest, For me, it makes sense to always have a page set as "posts page" and that the WP settings would be about setting another static page as "front page" or "home page". I suspect that this is a bit easier to understand for user but this would be a change that is a bit more "fundamental" and not something that can be driven from the UI side only.

[jameskoster]

For me, it makes sense to always have a page set as "posts page"

That sounds very much like what has been suggested. IE on a fresh install there is a page object associated with displaying posts. In reading settings there would be one dropdown in the homepage control, no more radios:

Additionally:

• That page can be found in the pages list(s).
• Editing the posts page has some unique characteristics (Improve the edit experience for the page that displays latest posts according to reading settings #63748).
• If you set a static homepage then delete the posts page, it should be possible to re-add it (Create and set a page_for_posts in the site editor #63667).
• Whatever page is set as the homepage cannot be deleted.

Or are you suggesting there could be a way to do this without registering the page object for latest posts?

[youknowriad]

@jameskoster yes, it's the same, basically I agree with you that this flow sounds great. The problem is that it's challenging and it's better addressed in Core (and not in Gutenberg)

[richtabor]

That sounds very much like what has been suggested. IE on a fresh install there is a page object associated with displaying posts. In reading settings there would be one dropdown in the homepage control, no more radios:

Yes, this is interesting.

The problem is that it's challenging and it's better addressed in Core (and not in Gutenberg)

How do we tackle this?

[youknowriad]

How do we tackle this?

Technically you mean, I have no idea.
Practically I think we should consider opening a trac ticket to get more feedback from folks there and see how to proceed there. We also need a dev committed to push this forward as it's very impactful.

[jameskoster]

What's the best way to frame the trac ticket? I'm trying to boil this down to the bare essentials which is obviously quite tricky as it touches a lot:

• Force show_on_front to always be page (or maybe deprecate this option altogether)
• Automatically register a page object on fresh installs
  • Set this page as both: page_on_front, page_for_posts
• Simplify the homepage controls in Reading settings
• Provide a way to create/assign page_for_posts when it doesn't already exist (Create and set a page_for_posts in the site editor #63667)
• Make the page_on_front un-deletable (Prevent deletion of page_on_front #64645)

[felixarntz]

@jameskoster Thanks for pinging me on #64620, great to find the conversation here!

Leaving some feedback based on how I understand what's being discussed:

• Having show_on_front always be page makes sense to me, at least for fresh sites or for sites where that's already the case (we need to consider backward compatibility implications).
• For fresh sites, +1 to creating a new page and assigning it to both page_on_front and page_for_posts.
• Question: Is the idea that we would still have UI controls for both page_on_front and page_for_posts? I'm asking because I think we still need both, as there are 3 scenarios to consider:
  • The site should have latest posts on the home page. --> Assign the same page to both page_on_front and page_for_posts.
  • The site should have a separate blog outside of the home page. --> Assign different pages to page_on_front and page_for_posts.
  • The site should not have a blog at all. --> Assign a page to page_on_front, but no page to page_for_posts.
• +1 for preventing deletion of the page_on_front.

In terms of backward compatibility, I could see something like this work:

• If a fresh site, set show_on_front to page and don't show any UI to change it.
• If an existing site where show_on_front is set to page, no longer show the UI either and thus don't allow changing it.
• If an existing site where show_on_front is set to posts, we should maintain the current UI for the time being.
  • In theory we might be able to create a new page, assign it to both page_on_front and page_for_posts and then changing show_on_front to page, but it is a very risky change that could break existing sites in various ways because there would now technically be a page present where before it wasn't.
  • If we want to make this transition even for those sites, I think we would need to somehow prompt the site owner to make that transition, but we can't reasonably do it for them automatically without risking breakage.

Curious to discuss this further, and FWIW I'd be happy to support this from the Core side.

[felixarntz]

Related to #64620 (reply in thread), I wonder how we would handle block template rendering for the page_for_posts. Currently, the majority of themes will simply ignore whatever that page's content is, and render the blog template (home) instead. For that reason, WordPress users experienced with this will simply create the page and leave it empty.

This is strange UX though. So I wonder if what's rendered on that page could be tied more directly to the page itself. For example, if you want to use the page to render the blog, you can do so by having it render a relevant core/query block with inherit:true. We don't really need a separate template for this anymore, so I feel like the home template could be deprecated entirely, in favor of patterns that show the blog, which you could for instance select when creating the page_for_posts.

[jameskoster]

Is the idea that we would still have UI controls for both page_on_front and page_for_posts?

The idea was to simplify the UI/X by only having a single control; "Your homepage displays: page_on_front". I don't know that being able to change the posts page is all that intuitive, and it's a flow prone to user error.

Tracking page_for_posts would happen behind the scenes, when that page is created, see #63667. Obviously we'd need to figure out how this would work in wp-admin.

If you wanted your blog to be the homepage you'd just mark it as page_on_front, either in the reading settings or in the editor (#63666).

Do you see any pitfalls to this approach?

I wonder how we would handle block template rendering for the page_for_posts. Currently, the majority of themes will simply ignore whatever that page's content is, and render the blog template (home) instead.

Rather than adjusting the template behavior, a unique edit experience for page_for_posts seems reasonable to me. We have an issue for this one too: #63748

Deprecating certain templates is an interesting idea and probably worth exploring, but it seems trickier to handle so likely a bit further off in the distance.

Curious to discuss this further, and FWIW I'd be happy to support this from the Core side.

Thank you ❤️

[felixarntz]

@jameskoster

Do you see any pitfalls to this approach?

I think there's one crucial problem with the approach: Not every site needs or wants to have a blog. So it would not be right to create a page_for_posts for every site and not provide a way to change/get rid of it.

Maybe a separate control is not the right way. But this scenario of not having any blog needs to be easily possible. Potentially we could solve this in a smart way, maybe automatically have a page_for_posts but only if/once there are any posts? Conversely, if there are no posts, that page would get deleted? Not sure about this, just thinking out loud. We do need to find a solution for this though.

Rather than adjusting the template behavior, a unique edit experience for page_for_posts seems reasonable to me. We have an issue for this one too: #63748

Awesome, I'll take a look.

Deprecating certain templates is an interesting idea and probably worth exploring, but it seems trickier to handle so likely a bit further off in the distance.

I'm not sure how tricky it really is, but I get the sentiment. That said, I do think we should look at this with the long-term vision in mind and not focus on another solution just to avoid deprecating templates. What I mean is: If deprecating a template is what it takes to get the ideal solution, we shouldn't shy away from it in favor of a different path.

[jameskoster]

Not every site needs or wants to have a blog

Oh I agree 100%. To clarify; if the proposed changes were implemented, you'd remove the blog by setting the homepage to display a different page first, then simply delete your page_for_posts. To me this feels a bit more intuitive than setting the "Posts page" to nothing, then being left with a superfluous "Blog" page that you'll likely end up deleting anyway.

It also means we could further tidy up the reading settings UI by conditionally showing/hiding options like "Blog pages show at most" based on whether page_for_posts is set.

If deprecating a template is what it takes to get the ideal solution, we shouldn't shy away from it in favor of a different path.

Fair point, I agree we should explore all options.

[felixarntz]

Not every site needs or wants to have a blog

Oh I agree 100%. To clarify; if the proposed changes were implemented, you'd remove the blog by setting the homepage to display a different page first, then simply delete your page_for_posts. To me this feels a bit more intuitive than setting the "Posts page" to nothing, then being left with a superfluous "Blog" page that you'll likely end up deleting anyway.

That makes sense to me. Follow up question: How could a user get back a blog if they changed their mind?

It also means we could further tidy up the reading settings UI by conditionally showing/hiding options like "Blog pages show at most" based on whether page_for_posts is set.

Great idea, potentially. I'm not entirely sure though whether these options are only used for the blog. There are all kinds of other archives in WordPress that are unrelated but may still use those options, so we need to consider that.