WordPress
Create and set a `page_for_posts` in the site editor
Related to https://github.com/WordPress/gutenberg/issues/63666.
When the homepage is set to display a static page, if you want to create a page to display latest posts you must exit the site editor and configure the reading settings which is quite disruptive.
In such cases, the UI might conditionally surface an option to create a page for the blog within the site editor:
If the user selects the option to create a blog, the new page is created as normal, and automatically set as page_for_posts.
In such cases, the UI might conditionally surface an option to create a page for the blog within the site editor:
Is this assuming you did not create a blog page when you assigned a static front page?
Yes, this menu would only appear when a static homepage is set, but page_for_posts is unset. IE this configuration:
Not necessarily, this affordance is about allowing users to create and set page_for_posts when a static homepage is configured.
Currently to do this you need to create the page, then exit the site editor, go to reading settings and set that new page as the "Posts page"... not a particularly smooth flow! :D
This pattern can be replicated for other dynamic pages. For instance if a public post type (e.g. Products) exists we might allow users to create a "Products page" from this menu.
I'm mostly asking because of the "Add new page" dropdown being shown in context of the pages section. Does it make sense to have this ability there, if the end result of what you create doesn't live in that section? Without that unification, "Blog page" remains a template, and could live in "Add new template" instead. I'm pro-unification, to be clear, just not sure this dropdown makes sense until such a thing has happened first.
Does it make sense to have this ability there, if the end result of what you create doesn't live in that section?
That's one of the confusing pieces around the posts page UX: if you have a static homepage and a posts page, the posts page is included in the pages list. But if you don't have a static homepage and display latest posts on the homepage, then it doesn't 😓
If anything I'd say it's blocked by https://github.com/WordPress/gutenberg/issues/63748.
I'm planning to work on this next since the Set as Homepage action has been merged. This feels like a good next step to allow editing the homepage display reading settings from the Editor.
Let me know if this doesn't sound like the best next step, or if there's anything else that should be worked on next.
In the associated PR there was feedback that the design in the OP is not the right direction:
Yes, we need to make it easier / more discoverable for users to decide what they want their blog page to be. But this here is too discoverable in my opinion. —fabiankaegy https://github.com/WordPress/gutenberg/pull/67648#issuecomment-2523844605
Let's continue exploring other options.
One idea could be a split button:
This way adding a regular page is still a single-click exercise, but the option to create a posts page is still within reach.
Yep, which can be useful for other CPTs too. Dare I even suggest post formats?
I like the idea of the split button. There was some feedback in https://github.com/WordPress/gutenberg/pull/67648 that it would likely be annoying to see a dropdown on clicking this button every time a user tries to create a new page, but I think having a split button addresses this.
It also felt a little strange to immediately publish the new page after selecting a "create blog page" option, so perhaps clicking this button could take the user to the new page flow in the Editor canvas, and the page can be published or drafted manually from there. However, I think the page needs to be published in order to be successfully set as the posts page, so we'd need to handle the case where the user doesn't publish the page. Maybe by displaying a notice/modal? (This works OK for the "set as homepage" action because it's only shown on published pages.)
Dare I even suggest post formats?
🔥 This would be cool!
I’ve been thinking about this and two things come to me that are visible in the following mockup
I would keep the “Regular” option as the first item to communicate all the types available. With this new split button, the “Add New Page” action is a quick-affordable version of the default option.
I inverted the meaning labels to prioritize the page "structure" rather than the content. The definition of a blog is subjective and it seems unnecessary to set it in the label. Yet I do see value in surfacing possible uses of this page, so suggesting it in the help text could ease the process. Especially for new users.
Users who want to create a page displaying the latest posts can be confused when seeing the “Add a blog” option.
Conceptually I like the suggestions, but I wonder about the labelling from an a11y perspective. Specifically; assuming the buttons are grouped, do the item labels in the menu require an 'Add' prefix ('Add latest posts'), or can that be omitted if the group has aria-label="Add new? Something like:
<div role="group" aria-label="Add new">
<button>Add new page</button>
<button aria-haspopup="menu" aria-expanded="false" aria-controls="menu-id">▼</button>
</div>
<ul id="menu-id" role="menu" hidden>
<li role="menuitem">Regular page</li>
<li role="menuitem">Latest posts</li>
</ul>
As there is some work already done on this, for now I am going to remove the needs design label to focus the task on feedback. We can always bring that label back in though.
