is_home() returns FALSE when using a static page as your front page

[johnbillion]

When a static page is being used as the front page of your blog, the is_home() function returns false. There is no simple function for determining "front of site, regardless of blog or page"

To recreate:

1. Go to Options -> Reading in your admin panel.

2. Choose a static page to use as your front page.

4. Insert a simple is_home() test in your template.

4. Observe the result of the is_home() function is false

[m0n5t3r]

I found where the issue originates from, but I'm not so sure about the author's intent here; patch attached

[filosofo]

Actually, is_home() is supposed to return true for the "blog" home page, where your most recent posts show up, not the "front" home page.

Initially, I didn't like the idea either (shouldn't is_home() be true on the "home" page?), but now I think it was the right decision. That's because theme developers create templates that test for "is_home()"; if you apply it to a page instead of the most recent posts, you usually get some odd behavior.

[johnbillion]

I can see filosofo's point here and after giving it further thought I agree that actually is_home() is better returning true on the 'blog' home rather than the actual home page.

Maybe another conditional function could be implemented, for example is_front_page() .

Closing with wontfix, unless a dev wants to discuss this further here.

[Viper007Bond]

That does sound like a very useful function.

[foolswisdom]

No action, only a comment as I am not a user of this functionality.

Replying to filosofo:

Actually, is_home() is supposed to return true for the "blog" home page, where your most recent posts show up, not the "front" home page.

It is bizarre logic that people will always stumble upon.

home: ​A site's main page.

BACKGROUND

​http://comox.textdrive.com/pipermail/wp-testers/2006-November/003251.html

"meant is_page('frontpage') ... that assumes your desginated front page page (sigh) has a slug of "frontpage"

[johnbillion]

Just as an update for anyone else who was stumped by this, I now use is_page(1), with 1 being the ID of the page used as the static front page.

[rob1n]

I don't agree with #2 and #3. The home page is what the user sees when they load up your site initially (example.com). is_home() should reflect that, and if the home is to be considered where the blog posts are, then this is against the philosophy that WordPress is more than a blogging system, but a CMS.

[majelbstoat]

There are already hundreds of plugins and themes that are designed based on how is_home() currently works. The naming is unfortunate and yes, confusing, but it would be best not to change it now. is_front_page() is a good solution.

[markjaquith]

Someone code up an is_front_page() patch and we can get it into 2.2

[JeremyVisser]

You know why MS Windows (particularly the latest instalment, Vista) is so broken now? Because they have retained the same API for 20 years while aiming to break _nothing_. Theoretically, legacy applications from the 1980s will still run on Windows Vista. Do we really want WordPress to follow the same path, growing three extra heads in the process?

[majelbstoat]

But you're talking about breaking virtually every theme out there to some degree. I'm not against changes that might cause some breakage per se - I really want to go to MySQL 4.1 for instance, but this is too big a change to something that theme designers have probably already taken some time getting their head round. Besides, making the distinction between something that is always the front page (is_front_page), and something that is always the most recent posts (is_home) is a pretty useful addition.

[markjaquith]

I see two solutions:

• make is_home() represent whatever is on the front page, and then introduce is_blog_home() for differentiation
• keep is_home() as representing the blog view, and create is_front_page() to represent all front page situations for differentiation

Second solution results in fewer issues with older themes. First solution is more elegant and less verbally confusing. I could go either way. But either way, we need to pick something. Start weighing in and lets make a decision.

[markjaquith]

Talked it out with a few people and here's my proposal:

is_front() represents the front of the site, whether blog or page.

is_home() is left untouched and represents the main blog view (where ever it appears)

This gives you all the logic you need.

Front of site, showing a page:

is_front() && is_page()

Front of site, showing the blog:

is_front() && is_home()

Blog, not on front of site:

!is_front() && is_home()

[markjaquith]

adds is_front() function

[markjaquith]

is_front() patch added

[filosofo]

+1 for Mark's idea.

[foolswisdom]

Replying to markjaquith:

Talked it out with a few people and here's my proposal

Seems like a elegant, well thought through proposal, but I feel it does not address the fundamental issue that the definition of home is equivalent to front page, and people will continue to stumble on our "alternate" definition.

[markjaquith]

Each way has its downsides. I've flipped and flopped back and forth on this a few times. Putting a stake into the ground and putting up some code has a way of bringing out other people's opinions.

I don't really feel strongly one way or the other (hence my flip-flopping), but we need to decide one way or the other. Ryan and Matt have yet to weigh in and might bring additional perspectives to the table.

[andy]

I would prefer not to have two meanings for "home". The original meaning, the one in the option called "home", is the URL of the front page of the blog. The original is_home() worked on that basis. So please let's keep is_home() consistent with the "home" option. Its logic might even be simplified: is REQUEST_URI equivalent to the path component of the "home" option?

What we need is a function that detects whether we're displaying the first page of the blog's posts. It needs a name. The logic can test the emptiness of certain query_vars and/or other is_*.

[andy]

Mark, I believe there's a logic bug in your patch: when you view the "front" page at its permalink or query string URL, you have a non-canonical view of the blog's front page.

Either that or we need to stop serving the same content from two URLs.

[ryan]

I've flip-flopped too for the reasons mentioned, but after more though I think I'm with Andy on this one. is_home() means the front page. It has never been safe to assume that the front page contains posts because so many people use plugins and other means to put static pages and other things up front.

[markjaquith]

Andy, maybe we should redirect such requests to the front page.

[joostdevalk]

Although I know it breaks some stuff out there, I'd go with is_home for the frontpage... That's what every new developer will expect, as well as every template developer...

[Otto42]

I disagree with Andy and other people here: I think is_home() should be the blog, wherever it is.

So, in order to achieve consensus, I suggest the following:

• Leave is_home() as it is now, to avoid breaking everything.
• Deprecate is_home() for the next several versions.
• Create is_frontpage() and is_blogpage(). Uses of these should be obvious.

The reasoning behind my suggestion is simple: "is_home" is semantically uncertain anyway, as this very discussion shows. It's not obvious what it should be pointing to. The fact that you can flip-flop on it and see it both ways proves this. So let's leave it as it is but deprecate it, and introduce replacements which are a lot more obvious.

[Nazgul]

I'd suggest:

• Make is_home return true on a static frontpage (what people expect)
• Make is_home return true for the blog homepage as well (current behaviour)
• Introduce an is_blog_as_home and is_page_as_home function which can be used to distinguish between the two.

[Otto42]

Replying to Nazgul:

I'd suggest:

• Make is_home return true on a static frontpage (what people expect)

The problem is that that behavior breaks plugins and themes and anything else that expects is_home() to return true for the main posts page, which, up until recently, was the case. If you used a static homepage (home.php) in versions of WordPress before the easy menu options to do so were added, then it didn't work this way. This break backward compatibility.

• Make is_home return true for the blog homepage as well (current behaviour)
• Introduce an is_blog_as_home and is_page_as_home function which can be used to distinguish between the two.

I vote for just these two options. Although I like is_front and is_blog better.

[Nazgul]

Still too much discussion, so pushing to 2.4.

[gfindlay]

Why on earth is there so much debate about this. It should be simple - keep the meaning consistent.

What happens when you use get_settings('home');? You get the HOME page defined in the options, not the blog page with all the posts. EVERYWHERE in WordPress where "home" is mentioned, it points to that. So is_home should return true when you're on that page and no other.

This already breaks a number of plugins for me because the plugin authors expect is_home to point to the home page, whatever it is - i.e. ​http://mysite.tld/

[thee17]

+1 for including it (Marks parch) in 2.4.

[JeremyVisser]

Can this be committed already?

[westi]

Replying to JeremyVisser:

Can this be committed already?

If some adds some phpdoc to an updated patch yes :-)

[Nazgul]

Replying to westi:

If some adds some phpdoc to an updated patch yes :-)

Like this?

[ryan]

(In [6704]) is_front() from markjaquith and Nazgul. fixes #3682

[ryan]

(In [6740]) Rename is_front() to is_front_page() to avoid conflict with bbPress. see #3682