Select page to show as the front page

First pass with rough UI

Patch adds Front Page options to Options->General. Pages are shown in dropdowns. Note that when you choose to show the latest posts on a page named "Blog", for example, "Blog" will display the latest posts but permalinks will not be re-rooted underneath /blog/. They will still be under "/" or wherever the permalink structure puts them. It's much simpler this way, and permalinks won't jump around when the blog page changes. I can see the arguments for re-rooting though. Discuss.

Sounds like you took the same route taken by the fantastic Filosofo Home Page Control plugin, which is an excellent strategy. If you haven't checked out that plugin, you should do so immediately, as it is a fully functional plugin-based solution to this problem. It might cut back on your work.

Hunk 2 is failing to patch for me... latest SVN as of this posting.

As for automatic re-routing... I say NO. Give the user the choice. Again, you could take a page from Filosofo Home Page Control here... that plugin will warn you that your posts will be displaying under root, and tells you how to go add "/blog/" to your permalink structure if that's what you want. Hot. Even better, it could give you a one-click button to do it.

Some people might want the blog to live in /blog/ but have their permalinks lack the /blog/ prefix, so we shouldn't force them.

Update

Updated patch against latest svn.

Yes, I've seen that plugin. Doing it in core requires a lot less code. :-)

For reference.

http://www.ilfilosofo.com/blog/home-page-control/

Trivial tweaks for your consideration:

1) "Show [page-dropdown] on the front page" might be better as "Show this page on the front page: [page-dropdown]" 2) Same for the next option

But what do I know, I'm no UI expert.

Functionally, it seems to work as expected.

Do you think it would be worthwhile having a little notice pop up after they change to using another page as their blog listing? It could read something like this:

"Your latest blog posts are now shown on http://site.com/blog/. If you would like your post permalinks to appear beneath that URI, you will have to add "/blog/" to the front of your permalink structure."

the whole "you will have to add ... permalink structure" phrase would be a link to Options/Permalinks.

Or, to play devil's advocate against myself, we could leave them to figure that out on their own, because making that change will break their old permalinks, and WP has no built-in mechanism to redirect the old permalinks. In fact, I may have just dissuaded myself. :-)

Considering how many people I've pointed towards Home Page Control plugin, I imagine this will be a headline feature of WordPress 2.1

using front_page.2.diff doing new install.php

1. Your description above says patch adds this ability to Options->General but it really is in Options->Reading. Guess you could argue for either location but Options->Reading does seem the best ;-)

2. Both the new pull-down boxes don't 'stay pulled-down' when you click on the pull-down arrow. See the Show at most: pull-down on that same page.

3. UI changes with Mark's suggestions:

Show the latest posts on the front page: O
Show this page AS the front page: [page-dropdown]

Show this latest posts on: [page-dropdown]

Trying to show that the 2nd and 3rd options are 'grouped'.

4. Is there a way to signify that the last two options are disabled when the first option is set? And if the last two options are set, show the first option disabled?

UI tweak

The dropdowns did not like being part of the radio input's label. That's why they didn't stay down. So, I moved them outside of the label and rephrased along the line of Mark's suggestion. It now looks a bit like Options->Permalinks. We could probably steal the JS bits from Options->Permalink so that clicking one of the dropdowns causes the corresponding radio to be selected.

[3581]

I committed so that folks can get a look at it and kick the widgets. We'll give it some UI love and improve error checking as we iterate. Report problems on this bug.

Regarding the UI, to balance the look of that panel, suggest placing the text to the left of the two radio buttons and making the text bold.

layout/wording tweaks

options_reading.diff changes the layout a bit, matching what I'm seeing on other WP options pages in terms of HTML. I added the bold text on the left as MichaelH suggested. I also changed the wording to go along with the options below, where the text on the left starts a sentence and the option selected finishes it. front/blog page options are in an unordered list which indents them, and maybe helps associate them with the second radio button. This might be a good place for some JS love... hiding the dropdowns when their parent radio button isn't selected. Thoughts?

Also, I added an error message that shows up under the front/blog page options if they are set to be the same (and if they are showing a WP page on their front page). I took a hint from Akismet and gave it an ID and a FAT class so it does the nice red-to-blue fade.

Example: http://img498.imageshack.us/img498/7435/picture29vj.png

Thoughts?

Much better. Not sure about the dots in front of the "Show..." text lines and wonder if the "Show..." should be aligned with the "A" in the text "A static page"

Definitely much better.

[3583]

Canonical URL schemes suffer here because siteurl and the static page's natural permalink are different URLs for the same resource.

wp_list_pages() also suffers because it includes a link to the home page but with a different URL.

I use the following filter to modify this behavior. If it seems like correct behavior, it can be rolled into get_page_link().

function front_page_link($link, $id) {
	global $wp_query;
	if ( 'page' == get_option('show_on_front') && $id == get_option('page_on_front') )
		return get_settings('home');
	return $link;
}
add_filter('page_link', 'front_page_link', 10, 2);

Related to wp_list_pages() and walk_page_tree(), there is a problem with the "Page" that is selected for display of posts. From wp_list_pages():

$current_page = $wp_query->get_queried_object_id();
$output .= walk_page_tree($pages, $depth, $current_page, $r['show_date'], $r['date_format']);

When viewing the "Page" for posts, $current_page is not set to the requested Page ID. The current_page_item class is therefore not applied.

I'm using WP as a CMS and I'm sure others are too, and with the new option to show a static page as the front page in the core (very CMS friendly), I have to choose a page to "show the latest posts" on - but I don't want to show the latest posts on any pages (because I have no posts). I want all my pages to be static pages and I want one page to be displayed as the index/home page.

Right now, clicking on the page assigned to "show the latest posts on" with no posts in the system displays a 404 page. Why not have the "show the latest posts on this page" be optional? Give the ability to choose "None" in the dropdown?

Oh, and when you delete the page chosen for "show the latest posts on", it removes the option in the options table... and the Options->Reading page displays the option as the top value in the dropdown (but that's not the actual value) - because nothing is selected. This should show the option as "None" if you delete the page. And maybe it should default it back to "Front page displays the latest posts" when you delete the page chosen for "show this page on the front page"?

Otherwise, you leave users (like me) very confused when they try to view a page they know is there and all they see is a 404 error page. This stumped me for awhile until I figured it out. :-) Thanks!

allow blank option

whoops - ignore last patch - typo

We use show_option_none in other places to indicate nothing is selected. Let's use that instead of show_blank.

'show_option_none=' . __('- Select -')

Something to that affect.

skeltoac's suggestion looks like a good candidate for inclusion into get_page_link().

Rework last patch to use show_option_none

Thanks Ryan. I submitted a new patch with show_option_none instead.

[3852] for show_option_none.

[3853] for the canonical URL.

In changeset [3853], returning the siteurl for get_page_link will break get_attachment_link if the attachment is a child to the front page. For instance, "/home/somefile/" will become "/somefile/". This was mentioned in #2792.

get_attachment_link needs to do some filtering to put the true permalink back

Hm, we sort of run in circles if we try to filter get_attachment_link... no way to get the permalink of that page!

check out my uploaded patch... it's not elegant, but it gets around it.

Patch for /trunk/ that returns the proper page permalink when asked to

It would be really really nice if invalid queries also returned to this home page - or even better if we had a new option for '404' type queries.

I've logged the 404 idea as #2996, since it is really a separate issue.

I'm making this comment here because the fallback (if no 404 page) should be the front page. Refer to #2996 for details

When will this be committed to the trunk?

What are the outstanding issues? Maybe someone with more insight than me can comment on it, summarizing them (and perhaps providing bug numbers)?

This would certainly kill my Home page for WordPress plugin - not that anyone wants that alive. BTW, my plugin followed a different approach: I just hijacked the query on is_home() using the posts_where and posts_orderby hooks/filters, making so that the selected "home page" appears as a post, *first* on the front page, followed by regular posts (very much like Owen's adhesive, but IMHO better).

If someone wants to have a "front page" or "intro post/page" followed by posts, I'd advise them to take a look at Home page for WordPress.

Although, for my own purposes, I'd certainly prefer the approach laid out in this report over HP4WP any day!!!!

As RuddO has pointed out, this feature has currently broken 404 handling. I've had a little look but I haven't confirmed why.

Just quickly - I set up a separate server with code as at [4079] and got the expected 404 error, so I updated the main server to the same revision - it still occurs. So it would appear this is environment-related. Server with the program is PHP4, server without is PHP5 - I don't know if that is a factor.

Sorry that should have said "Server with the problem is PHP4"

I recant, apologise, retreat and sulk:

• The bit about it working was rubbish, it worked because the test server didn't have mod_rewrite enabled and thus Apache (not WP) was generating the 404 message. Nothing to do with php5 and everything to do with my own carelessness
• 404 handling works ok if your theme has a 404.php. I don't know where mine had gone (perhaps I should add Template:default to my style.css...)

<blush> I don't think at this stage that anything is actually wrong here. Certainly this behaviour would appear to predate [3581] by many months!

new internal function

2515.diff

1. get_page_link() as before.
2. new _get_page_link() used internally when need to ignore page_on_front.

(In [4475]) Fix attachment links for page on front. Props mdawaffe. fixes #2515