1 and 3 make sense. If you want a page on front, then you obviously need to create a page to live there, along with its content, and then designate it. But the "Blog" page is just a dummy. It's sole purpose is to create and maintain a URL for your blog. So why not just have something like this?

If a page exists in the URL they type, it gets used. If not, we create one on the fly as a dummy. This seems a more natural way of doing it. You don't care about the dummy page — you just want to choose an appropriate URL for your blog.

Any reason why 1 and 3 shouldn't also have a streamlined process? Every time I launch a site I have to go through the same process for both front page and blog page. Why not streamline it for both; sounds like your approach would allow one that already exists to be use anyway?

Because you're not choosing a dummy page. You're choosing a real page, with real content. So you have to create the page and its content anyway. Not so with the Blog dummy page.

That feels like an arbitrary distinction.

I guess the question is, how often does someone use the when the are initially setting up a site vs. how often do they use it for an existing site? My guess (which could be wrong) is that +85% of the time they are doing it upon initial setup with the actual page has not yet been created. Why not create it for them as a placeholder if its not already there, or associate with one that's already been created?

Again, it just seems arbitrary to make that distinction and in the 100% of the use-cases that I have it would be helpful if I could just go and configure front page+post list page and it would create the pages for me.

Of course either way you decide it's still trivial effort, it's just an annoyance that should be annoying IMO.

1 and 3 make sense. If you want a page on front, then you obviously need to create a page to live there, along with its content, and then designate it. But the "Blog" page is just a dummy. It's sole purpose is to create and maintain a URL for your blog.

In some respects I'd disagree that 1 and 3 made sense, it all depends on the purpose of your front page yes, and how you want to display things right? If you had a custom Page Template, which didn't require any text input, you've effectively got a dummy front page here. Now I don't know how we could use the front-page.php​template, I suppose I need to get my head around how it works! :)

If a page exists in the URL they type, it gets used. If not, we create one on the fly as a dummy. This seems a more natural way of doing it. You don't care about the dummy page — you just want to choose an appropriate URL for your blog.

I was thinking out loud the other day in #wordpress-dev before @nacin pointed me in the direction of this ticket (which I couldn't initially find) on possibly using the new CPT Archives we introduced in 3.1? I think it makes perfect sense, not fully sure how it could be executed, so that we can retain backwords compatibility (as @nacin also pointed out to me!) -- Anyway, thought I'd just air my thoughts!

I have added a concept for what I think the front page settings need to be. While I like the new process, getting rid of the dropdown all together seems to make things more complicated than it needs to be. Instead, I'd have a checkbox next to the Posts page that, when checked, would display the new page input.

I asked Dave to make it so the dropdowns only show if static page is selected and to change "Front" to "Home" to better reflect how most people talk about their sites (per the wireframe he just uploaded). I would like to see what he mocked up replace what we have now.

The progressive menu display was supposed to be done before (#15205) but as of 3.4 it's not there.

A 'posts page' meaning 'A default archive-esque page that will list your most recent posts' makes sense to me. But if I step back and look at that from a new user I would wonder 'Posts? I made posts already. What's this post 'page' mean?'

There's a gap there. Front page is pretty explanatory (I was talking to Andrea on Sunday or Friday about it) but there's no way right now to make that connection being 'posts page' and 'page that lists recent posts'

It is (perhaps unfortunately) well-established in WordPress that "home" refers to the Blog Posts Index, and "front page" refers to the Site Front Page.

I would debate that it is "well-established", at least the point of clarity and understanding. I've been working with WordPress professionally for 3+ years and I still get confused by this terminology. God help someone who doesn't live-and-breath WordPress to be able to understand it as it is currently applied.

Jane's suggestion makes a lot of sense IMO as those who pay enough attention to already understand it will certainly read the articles explaining how things have changed.

It is (perhaps unfortunately) well-established in WordPress that "home" refers to the Blog Posts Index, and "front page" refers to the Site Front Page.

I would debate that it is "well-established", at least the point of clarity and understanding. I've been working with WordPress professionally for 3+ years and I still get confused by this terminology. God help someone who doesn't live-and-breath WordPress to be able to understand it as it is currently applied.

By well-established, I am referring to how the terms are used in core.

Jane's suggestion makes a lot of sense IMO as those who pay enough attention to already understand it will certainly read the articles explaining how things have changed.

And I counter that this change will only make things more confusing, especially for developers, by introducing even more conflation of the terms home and front page; primarily, conflation of home as site front page as opposed to blog posts index.

Just to toss in something I see from many new users with this setting - if the theme uses a home.php to present something other than a list of recent blog posts, the user almost always tries to set a specific page as the home page. Some going so far as to making a page called "home". (possibly this could be a reserved name?)

If the home.php has a bunch of widget areas, the user is confused that settings a static page as home overrides this. (Yes, I am aware of when to use home.php versus front-page.php, I'm just reporting user confusion.)

You're right. I could definitely see this new terminology as confusing for developers.

But what about the average user? Who uses the phrase "Front page" anymore? It's like this setting got lost in the late-nineties ;-)

If we're talking solely about what is best for the average user, I'd vote to make the swap to "home page" and for the time being let developers figure it out (with the hope that we could formalize better terminology down the line).

With that said, I'd rather not throw the baby out with the bath water on this one. If changing "front page" to "home page" is a true blocker, let's just keep it as "front page" and get the inline "Create a new page" functionality committed.

This would make "Home Page" or "Front Page" a property of a page you can set, rather than a global setting that is completely separated from Pages in the admin, despite the fact that you need to create certain pages in order to use this setting.

Pros:

More discoverable

Better mental model than current approach

Keeps the user in one part of the admin

Prevents to user from trying to set a Front Page before having the pages available

Seems like it would be faster.

Cons:

Clutters the Pages screen for a setting that will probably only be set once.

There are probably more, but I haven't thought of them yet

Alternative, but similar solutions:

Rather than having action links, add a setting on the "Edit Page" screen and the "Quick Edit" settings. Would reduce clutter, but keep the same mental concept. Would also reduce discoverability.

_dropdown_pages() in options-reading.php is a simplified version of wp_dropdown_pages(). Tried to use that one first, but couldn't find a decent way to make it return the lists with different attributes if no pages are currently published (the patch handles #15208 as well).

How about "Blog home page" and "Site home page" (also "Network home page"). These are clear, especially when juxtaposed.

Also, the page template and conditional tags are confusing. Those should be deprecated and is_blog_home(), is_site_home() and blog-home.php, site-home.php should be introduced.

I like this idea of "types" of home pages. This could be extended to post types, sections, etc... What if is_home() was just modified to take an optional variable, so you could do is_home( 'site' ), is_home( 'blog' ), is_home( 'my_post_type' ).

is_front_page() could just stay as is and be deprecated?

The only problem with any of these, whether is_home( 'blog' ) or _is_blog_home(), or even the idea of assigning a "blog" page relates to the discussion about renaming the "Posts" menu item to "Blog", discussed here: ​http://core.trac.wordpress.org/ticket/20956

There are reasons why it does not make sense to just force the word "Blog" on the posts section. Some would call it news, etc... For me, that would be another reason to keep it something versatile like is_home( 'something' ), or instead of is_home( 'blog' ), you could just do is_home( 'posts' )?

Only related to a tangent at the end here, but I've also found the front-page.php template to be unintuitive. Every time I go to make a new homepage template, I'll create a new file called page-front.php before realizing my mistake and changing it to front-page.php.

Only related to a tangent at the end here, but I've also found the front-page.php template to be unintuitive. Every time I go to make a new homepage template, I'll create a new file called page-front.php before realizing my mistake and changing it to front-page.php.

Definitely liking the latest concept, lessbloat. I love how everything is spelled out in plain English, making it much easier for new users to understand what each setting does.

In general, I feel this issue of the "dummy page" is equally applicable to Custom Post Types & their archive pages (although probably less urgent). Is there a related / separate ticket for that already?

1) This version omits the default radio button for "Your latest posts". I'd be in favor of leaving it in, as I think it helps newer users understand the difference between the two settings. Thoughts?

2) The post page is now set by entering a slug, rather than a page title. This definitely makes more sense, BUT if we're still going to list the page_for_posts page under Pages, then the title will matter, and trying to automatically convert the slug to a title might not be the best option. If we can get to a point where we're no longer displaying it as a "Page", however, then I think this solution works. It's just a matter of knowing how/when that will change.

Immediately clicking "Show latest posts on a separate page" after "Show a page instead of your latest posts" without saving first results in a bunch of PHP errors: ​http://cl.ly/image/053G2h0E2W2L as $pag_for_posts isn't set.

_dropdown_pages() doesn't appear to do anything with the "selected" parameter.

In _dropdown_pages() the "selected" equals get_option( 'page_on_front' ). Do we need to do some validation on this to make sure that the page that was previously set as get_option( 'page_on_front' ) still exists.

Last, we need to duplicate this functionality in the customizer's "Static Front Page" section.

I really like the work going on on this ticket. No doubt its a good improvement.

Nevertheless I would like to continue the discussion with those who think we could have an alternative for the dummy pages. I had a discussion on wp-hackers recently that ended up in a plugin to demonstrate how this could work (​https://github.com/vmassuchetto/wordpress-force-front-page/) - I beleive it could be an add_theme_support thing.

Anyways, this is not the place to discuss it, and Im not sure if it should be a ticket or a thread on wp-hackers, so I decided to drop a line here because I saw I could find some people withe similar ideas,

In _dropdown_pages() the "selected" equals get_option( 'page_on_front' ). Do we need to do some validation on this to make sure that the page that was previously set as get_option( 'page_on_front' ) still exists.

We don't currently validate that in options-reading.php. Walker_PageDropdown can handle zero 'selected' value.

Use get_current_screen() instead of the $current_screen global. There is no need to esc_html( stripslashes() ) the data going to wp_insert/update_post(). They expect slashed data and will handle sanitization.

Remove unnecessary .tog class from checkboxes on the Permalink Settings screen. Designed originally for the admin color scheme choice (see [7259]), it causes vertical misalignment and lack of spacing between the checkbox and corresponding label. see #16379.

Yeah, so, autosave.js also makes an XHR call to sample-permalink. I didn't catch that. The original patches from Sergey and lessbloat at least avoided the notice by confirming we had a current screen, so let's do that.

Move the static front page saving routine to a single sanitize_option() callback for show_on_front. page_on_front and page_for_posts are now manually set by this callback, and not separately by options.php. see #16379.

[22136] was necessary because it got to a point where you couldn't set page_for_posts or page_on_front from this routine without options.php overwriting them. If you moved them to be updated first, then you wouldn't be able to avoid updating them at all, leaving the current value.

For page_on_front, if the user selects "Add new page", and the title they enter is the same as a title of a page that already exists we should just add another page with the same title.

My rationale:

First off, doing it this way shouldn't affect new users (unless they choose "Sample Page" as their title which is unlikely).

But let's say a user with 20 pages decides to add a static front page:

They go to settings -> reading

Click "Show a page instead of your latest posts"

The drop down at this point says "-- Select --"

Once they expand the drop down, they'd see all of their pages, so you'd think if they wanted to select an existing page, they'd just go ahead and select it.

But let's say they do select "-- Add new page --" and they enter the title of "Home" (when a page with the title of "Home" already exists), upon saving, the drop down would go ahead and auto-select the new "Home" page for them.

The only confusing part might be when they go to edit their static front page titled "Home", as there will be 2 in the listing, but they kind of brought it on themselves :-).

For page_for_posts, I think we need to use the existing blog page if one exists.

Rationale:

First, doing this shouldn't pose a problem for new users.

For existing users with pages, there would be no way to select an existing page otherwise.

Thoughts?

So, that makes sense. But the @todo brings up a few other questions:

What if the existing page we find isn't published? Even if the user *can* publish pages (and they might not be able to), we probably shouldn't publish a non-published item. (3.4 only allows published pages to be selected.) At that point, we might need to settle for blog-2. We *could* show a conflict note if we detect one.

What if the existing page can't be edited by the user? That means they can't change the title or slug. If for some reason, the user can't *create* pages, I've already coded it so a dropdown shows of existing pages. We might need to do the same for when the user can't edit pages either.

Maybe I'm missing the logic here, but why not just supply the dropdown for each of the two options from the very start? If they want to create a new page that holds their latest posts, why can't they just select --Add New Page-- same as the first option? If you can't create new pages, hide the "add" option, if you can't manage options, you wouldn't be on the page in the first place.

What if the existing page we find isn't published? Even if the user *can* publish pages (and they might not be able to), we probably shouldn't publish a non-published item. (3.4 only allows published pages to be selected.) At that point, we might need to settle for blog-2. We *could* show a conflict note if we detect one.

Right, I don't think we should publish an existing non-published page without them knowing. My gut says that throwing an error would be the best approach. Something along the lines of "You'll need to publish your existing "blog" page before you can use it for latest posts.". Mostly because personally I'd never want my blog directory to be blog-2.

What if the existing page can't be edited by the user? That means they can't change the title or slug. If for some reason, the user can't *create* pages, I've already coded it so a dropdown shows of existing pages. We might need to do the same for when the user can't edit pages either.

Seems odd to me that a user could manage options, but not have access to edit pages. Regardless, should a user have access to settings, and not have access to edit pages, I'd just treat it the same as we're treating users who can't create pages (just don't show the "Add new page" drop down option). It seems like such an edge case, that I'd hate to see us add any more code than that to handle it.

WP show me an error box: "You must select a page to set a static front page."

Not exactly what the user expects. Page isn't created, neither.

So I still have to create the page manually.

Szenario 2:
Now I've created the page "Home" manually and want the posts on the page "Blog". So I select the "Show latest posts on a separate page" checkbox and click "Save settings". Surprisingly there is no dropdown menu for the page selection.

-> This time it seems to work, the page "Blog" is created. Did not expect that because the UI didn't tell me that the page is created automatically (in contrast to the Home page).

It's just a proposal (and I know it's late in the game to be throwing out proposals like this), but I feel like using auto-complete instead of a drop down + title field combo would offer a better experience.

Question: Will new users (I mean the newest of the new) understand what is happening without a little explanation text? It might be a little *too* streamlined for those users. How about a brief prompt above the text boxes, like:

"Type the name of the page you want to use. If you haven't created it yet, just type in the name you want to use, and we'll create it for you."

I just played around with things until I felt better about the implementation. 16379.10.patch is a bit of a departure from what we've got in trunk now. It actually brings us much closer to where we were in 3.4. Essentially, I've just replaced the "front page" and "posts page" drop downs in 3.4 with auto-complete text fields, and updated the copy a bit:

I also added a message to the page used for "page_for_post", and removed the editor there (since it's always replaced by the latest posts loop):

Please take it for a spin if you have a sec, and let me know what you think.

Happy to make any further improvements to this patch if we are happy with this direction.

I have several sites where I have used the editable area on this page to provide content that can be displayed at the top of the post archive template.

I hadn't considered that. To be honest, I could easily be convinced to remove all tweaks to that page (leave it the way it is in 3.4). Alternatively, we could leave the editor visible by default, and still show the message - calling the message from a hook, so it could be turned off? Do you think having the message there is helpful?

I also added a message to the page used for "page_for_post", and removed the editor there (since it's always replaced by the latest posts loop):

I don't think that this is a valid assumption. The Loop may be replaced, but $post->post_content itself can still be output directly. (And I don't think the use case in which a Theme does so is trivial, since it is a simple way to allow for user customization of the Front Page and the Blog Posts Index.)

I think the message is helpful, regardless of whether the the post editor remains or not. I think it's a great reminder for new users who don't understand (or possibly just forget) that this is not a "normal" page anymore.

I would vote for leaving the page as 3.4 with editor, but having a message which could be removed via a hook if required (or perhaps filtered so you could change the message - if message is blank, don't show)?

I would vote for leaving the page as 3.4 with editor, but having a message which could be removed via a hook if required (or perhaps filtered so you could change the message - if message is blank, don't show)?

I like this approach as it sort of eases people into the right way of thinking about page on front. And +1 for a hook to filter to the message.

Added a hook for the page_for_post message, and restored the editor in 16379.11.patch.

I also tweaked the message to read, "This page is set to display your latest posts. As a result, the main content for this page (as seen in the editor below) will not be displayed. Visit your reading settings to change the 'front page displays' option."

16379.12.diff​ fixes a couple of notices on options-reading, adds some spacing on the sprintf's and switches single for double quoting in the edit-form-advanced message.

We should also maybe look at an informative message on the page set as static front page. It doesn't have the same caveats that latest posts page does but it still might help reinforce what's going on.

Edit: Just as an addition, I noticed that when I updated the page earmarked as 'latest posts', the updated message showed at the top then dropped below our new message, almost like they were jockeying for position.

1.) inexperienced users should be able to use a static page without the need to ask anybody else. I can't count the times I answered a question on how to change the front page to a static page.

2.) it should be a single step process, not like in 3.4 where you have to realize that you have to create a page first before you can use it as the front page AND to create an additional page to be used for the posts. This procedure overstrains many users.

We tried an intuitive new thing here and had it done early. It ended up not working well. That's not what we expected, but it's okay. We can try again. The autocomplete UI shows good progress. It's just too late to run with it now. ocean90 is right. Even two weeks ago, we were way too late to pivot here.

After trying to understand the current behavior (what is it supposed to do) for a pretty long time, I was (gladly) pointed at this ticket.

Here're my 0.2 cents:

If one selects (in the current UI) "A static page" and selects nothing from the drop-downs, then WP automatically resets it to "Your latest posts" without any further notice why this happened. When I got a home.php and a front-page.php file in my theme, then I'd expect WP to use them by default, not only if I've created and selected a page for it. This simply isn't needed in every case (front page with just a title and a searchform for e.g.), so why force it? Or at least tell - in some admin notice - that there has to be a real site instead of just moving to a setting the user never made by himself.

We need to make the UI simpler, not more complex with more choices. I would imagine that CPT support for the homepage would be a filter for developers, not a default behavior. We can see what turning on such an option would do to the UI if it happens, but I don't think we need to accommodate it until then.

Have seen ​my reply above? I already tried to simplify it automating most of the choices depending on what is present in the Theme.

If one selects (in the current UI) "A static page" and selects nothing from the drop-downs, then WP automatically resets it to "Your latest posts" without any further notice why this happened. When I got a home.php and a front-page.php file in my theme, then I'd expect WP to use them by default, not only if I've created and selected a page for it. This simply isn't needed in every case (front page with just a title and a searchform for e.g.), so why force it? Or at least tell - in some admin notice - that there has to be a real site instead of just moving to a setting the user never made by himself.

@melchoyce @lessbloat i think that's a great idea, but i'd wager that a majority of the time, people who are using a static page on front also need to select a custom template for it. they will still have to go to the page listing, and edit the new page to select the custom home page template.

this doesn't feel like it'd save a ton of time without removing that step as well.

people who are using a static page on front also need to select a custom template for it

That's why there's a "Edit $page" link right there. :)

this doesn't feel like it'd save a ton of time without removing that step as well.

I feel there are two problems the proposal above addresses:

confusion in how to do it

ease of use

Where "confusion" in my experience is the biggest one there. I've yet to run a single user test with someone that doesn't get confused by that small UI.

Note also that it makes the "blog" page implicit, transforming it from a needed page to a string you just type (and _can_ have an associated page to keep backward compatibility, or not).

Of course, I read this improvement as incremental. Personally I'd remove that piece of UI entirely from there and move it under the Pages administration, where it belongs logically. But that would mean more work, and might confuse some people that built an habit. So I'd start with this one first. :)

In the last four years here have been many opinions on how to make the functionality of selecting a static front page simpler and more intuitive. IMO most of them make it for the new and average user even harder to understand what to do.

Maybe we should remember the WordPress mantra "Decisions, not Options." I would assume that the vast majority of users (if not every user) call their recent posts page "blog". Why not define "blog" as the default name for this page if a static front page is selected? This would simplify the UI a bit and free the user from understanding how to create a blog page, which seems to be the main problem.

Of course there will be some users complaining that they want to have a different name for the recent posts page but for this few users we could add a filter. If you want to change the name you should be able to do an add_filter() (and there will be various plugins within seconds).

Well... That's exactly what the proposal above does: by default you see it suggests "/blog" as the default name, and they can edit it from there too. We can't take it away otherwise people will start wondering "where can I see my blog", so by showing where, we make it editable too. Win-win. :)

So: if you just switch the home page, you select it in the dropdown and automatically you get the blog at "/blog", and it tells you so. :)