Improve the edit experience for the page that displays latest posts according to reading settings

[jameskoster]

When configuring a 'Posts page' in reading settings and editing it in the Site Editor, the following issues arise:

1. Restricted Block Selection: Users cannot select or edit any blocks (except for the header and footer) unless they switch to template editing mode. This requirement is an unintuitive and cumbersome step for users.
2. Confusing Edit Environment: If the 'Show template' option is toggled off, users find themselves in an odd editing environment where they can add blocks that will never appear on the frontend.
3. Limited Settings Access: Users cannot manipulate settings like the number of posts per page without switching to template editing mode.

Proposed improvements

Given that the 'Posts page' is technically a template, it may be reasonable to allow users to directly manipulate the template blocks. The template that resolves to display this page (either home.html or index.html) will typically only display this one page (unless the theme does not include an archive.html template which is pretty rare), minimizing the risk of users unintentionally affecting other pages.

To improve the editing experience, I propose the following solutions:

• [ ] Unlock template editing: Allow users to select and edit template blocks directly in this context.
• [ ] Surface template settings (posts per page) in the inspector.
• [ ] Hide irrelevant page meta in the Inspector (template, author, publish date).

---

This issue is closely related to https://github.com/WordPress/gutenberg/issues/60772

[richtabor]

Here's a recording of the current experience:

https://github.com/user-attachments/assets/df988875-480f-49fd-82fd-9ca7c048f462

[felixarntz]

After initially thinking about this in https://github.com/WordPress/gutenberg/issues/60772#issuecomment-2329507992, sharing here some revision of that idea:

Rather than mixing page and template, might it be a better long-term solution to rethink what defines the blog of a WordPress site? Most confusion today stems from that this is both a page and a template.

I question why the blog needs to be a "page" (WordPress post type) in the first place. Why should there even be a page_for_posts option? Rationale:

• Already today, the blog may or may not have its own "page". It's only represented by a page if it's not configured as the home page. This shows that using a page for the blog is not necessary.
• It's confusing for users to have a page with such a special role and different behavior. Today this leads to the weird behavior where you keep the page content empty since it's just a placeholder for another template. What's being proposed here would IMO only work around that problem by allowing a template to be edited from a page - still very confusing IMO.
• At its root, the blog is simply the archive of all posts. WordPress already supports post type archives for any post type that needs one, and those archives are templates, not pages. So it would make sense for the blog (the "post" post type archive) to be no different how it uses templates.

Now I'm not saying the blog should be treated entirely like post type templates - it still does need a more prominent role in the UI. But I think for all of the above reasons we should work towards a solution that gets rid of having a "page" for the blog.

[jameskoster]

These are good thoughts, thanks for sharing :)

I question why the blog needs to be a "page"

One argument is that it leans into conventional mental models associated with site management. It seems quite safe to say that users generally think about websites in terms of pages; not templates, archives, or other esoteric concepts. For most people their blog is a page—maybe with some special properties—but for the most part no different to 'About', 'Services', 'Contact', and so on. If that assumption is correct then it seems reasonable that folks would expect to find their blog within the page management section of the admin.

This may go for other 'virtual' pages as well, e.g. the Shop page in WooCommerce, taxonomy archives, maybe even templates like 404 and search results. By presenting these as Pages we can simplify a lot.

I think there's also something to be said about simplifying the optics in the edit experience too. For instance if you go to edit your blog and find yourself editing a template with a complex name like "Index" that can be intimidating.

All that said I do appreciate that this is all a veneer to hide the underlying complexity. But without throwing out the template hierarchy it's tricky to see another approach. If there wasn't a page associated with the blog, what would the navigational flow to edit the blog look like? Currently you have to enter template management, work out which template resolves to display the blog and edit it. Clearly this is a very poor UX for any non-technical users, and difficult to document given there are several templates that can resolve to display the blog.

[felixarntz]

For most people their blog is a page

I question this statement. Even today, the blog is only a "page" in WordPress if it's not configured as the home page. It always is however a template (e.g. home.html/home.php).

No archive in WordPress (whether it's categories, tags, custom post types) is a page, they are all represented by templates. So why should the blog ("post" archive) be any different?

This may go for other 'virtual' pages as well, e.g. the Shop page in WooCommerce, taxonomy archives, maybe even templates like 404 and search results. By presenting these as Pages we can simplify a lot.

When you say "presenting these as Pages", do you mean showing them alongside other WordPress pages, or actually creating WordPress "page" instances for them too? Are you saying that there should be a page for every kind of archive that WordPress has?

[jameskoster]

Sorry, I was talking conceptually. I understand that the posts page is technically a template, the point was that users who are unfamiliar with the template hierarchy think of it as a page. The hypothesis is that the UI would feel more intuitive if it was aligned with that mental model.

When you say "presenting these as Pages", do you mean showing them alongside other WordPress pages, or actually creating WordPress "page" instances for them too? Are you saying that there should be a page for every kind of archive that WordPress has?

This part isn't 100% clear to me, and is where the technicalities get a bit tricky. These are all mostly ideas at this point, working on the assumption that pages are a familiar and intuitive concept, whereas templates (and by extension the template hierarchy) as they exist today are not; especially for 'virtual pages' like the posts page.

Worth reminding (as you know) that this is a very long-standing issue – editing the posts 'page' has been a poor experience in WP since forever. There is time to go broad on ideas.

[felixarntz]

Sorry, I was talking conceptually. I understand that the posts page is technically a template, the point was that users who are unfamiliar with the template hierarchy think of it as a page. The hypothesis is that the UI would feel more intuitive if it was aligned with that mental model.

Okay, so let's decouple the conceptual "page" from the WordPress post type "page" then. What would potentially make sense to me is:

• We show archives (e.g. the blog, category archives, tag archives, custom taxonomy archives, custom post type archives) alongside other pages (i.e. those that are using the WordPress "page" post type) because people consider them pages of their website.
• Technically, none of them are using the WordPress "page" post type though. From a technical WordPress perspective, they are templates.
  • This is already the case today, except for the blog which, if it is not also used as the home page, is technically a "page". We may want to get rid of this confusing technicality and handle it like all other WordPress archives.
• This could for example mean that, if you click "Edit" on one of those archives in the list, it would open the respective template for editing, not a WordPress "page".

WDYT?

[jameskoster]

if you click "Edit" on one of those archives in the list, it would open the respective template for editing, not a WordPress "page"

That's definitely one approach, but there is a drawback; the 'Edit' button is associated with a specific post/page, but the Editor UI will communicate that you're editing something totally different (a template) which might be confusing. There's also a question about what the canvas should show... generally when editing templates blocks will show placeholder content rather than actual content. This probably isn't ideal in a flow to edit a specific post category (for example).

An alternative approach would be to essentially replicate the page edit experience. So when you go to edit the "Recipes" category via pages:

• The UI tells you you're editing the "Recipes" page
• You can directly manipulate content associated with the category (title, description)
• The summary panel in the Inspector informs you which template is used, and via that UI you can access template editing where it's made clear that changes can affect all category pages.

I suppose the drawback to this approach is that we'd need to 'spoof' pages for all taxonomy archives. But if we're contemplating this for the homepage (when set to display latest posts) I'm not sure how much of a concern that would be? They can likely share the same rules.

which, if it is not also used as the home page, is technically a "page"

If we can refine the edit-ability aspect, the experience around the current posts page might be a decent example of how all of these 'virtual pages' could work.

[creativecoder]

I like the direction this discussion is going. Putting the technical challenges aside for a moment, I think expanding the idea of what a "page" is could greatly improve the usability of the site editing experience:

Redefining pages

Following this line of thought, the list of pages in the site editor should show any unique url on the site that isn't a single post, term, or custom post type

• This would bring some things we now call templates into the list of pages, mainly: front, home, and post archive (posts page) templates
• This makes intuitive sense because these aren't really templates (not reused across multiple urls)

The most relevant side-effect of this is that any "page" can then be assigned as the home page. Reading settings are flattened to just one setting -- which page is the homepage (very close to https://github.com/WordPress/gutenberg/issues/60772).

But I think it benefits other archive pages as well: author/date/taxonomy archives have their own urls, so could also show in the list of pages. By default, these may inherit the generic archive template. But customizing them to be unique can then be done as if editing any other page.

The huge benefit here is that when I visit the url, I can go and edit the content there without needing to understand the template hierarchy, until I want to make layout edits that apply in multiple places.

Templates

Layouts on the site that are re-used in some way, and don't have their own unique url, stay as templates. These continue to be edited through template editing mode or by going to the Templates section of the site editor.

• "Single" templates used across multiple pages, posts, terms, and custom post types
• "Custom" templates that can be assigned to individual pages or posts
• The generic archive template, 404, search.

---

Coming back to this issue, improving the experience of editing the home and posts pages from the pages list in the site editor seems like a good way to move in this direction.