Ticket #3682 (closed defect: fixed)

Opened 1 year ago

Last modified 5 months ago

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

Reported by: johnbillion Assigned to: westi
Priority: normal Milestone: 2.5
Component: Template Version: 2.1
Severity: normal Keywords: has-patch has-docs
Cc:

Description (Last modified by markjaquith)

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

Attachments

is_home.fix.diff (468 bytes) - added by m0n5t3r on 01/26/07 17:45:52.
is_front.001.diff (0.6 kB) - added by markjaquith on 02/23/07 11:45:23.
adds is_front() function
3682.diff (0.9 kB) - added by Nazgul on 01/31/08 23:33:16.

Change History

01/26/07 17:45:52 changed by m0n5t3r

  • attachment is_home.fix.diff added.

01/26/07 17:46:16 changed by m0n5t3r

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

(follow-up: ↓ 6 ) 01/26/07 18:14:27 changed by 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.

01/27/07 06:10:58 changed by johnbillion

  • status changed from new to closed.
  • resolution set to wontfix.

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.

01/27/07 13:08:09 changed by Viper007Bond

That does sound like a very useful function.

01/27/07 13:08:20 changed by Viper007Bond

  • milestone deleted.

(in reply to: ↑ 2 ) 02/01/07 01:42:24 changed by 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"

02/11/07 16:08:10 changed by 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.

02/17/07 23:17:02 changed by rob1n

  • keywords changed from is_home to dev-feedback 2nd-opinion.
  • status changed from closed to reopened.
  • resolution deleted.

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.

02/18/07 02:07:52 changed by 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.

02/18/07 03:42:08 changed by markjaquith

  • milestone set to 2.2.

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

02/18/07 10:06:19 changed by 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?

02/18/07 10:28:06 changed by 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.

02/23/07 10:14:17 changed by 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.

(follow-up: ↓ 18 ) 02/23/07 10:28:05 changed by 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()

02/23/07 10:29:51 changed by markjaquith

  • description changed.
  • summary changed from is_home() returns FALSE when using a static page as your front page, should return TRUE to is_home() returns FALSE when using a static page as your front page.

02/23/07 11:45:23 changed by markjaquith

  • attachment is_front.001.diff added.

adds is_front() function

02/23/07 11:46:29 changed by markjaquith

is_front() patch added

02/23/07 12:24:52 changed by filosofo

+1 for Mark's idea.

(in reply to: ↑ 14 ) 02/23/07 21:57:46 changed by 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.

02/25/07 13:55:27 changed by 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.

02/26/07 02:54:37 changed by 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_*.

02/26/07 02:57:33 changed by 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.

02/26/07 03:48:15 changed by 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.

02/26/07 05:37:12 changed by markjaquith

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

04/12/07 18:10:10 changed by foolswisdom

  • milestone changed from 2.2 to 2.3.

08/24/07 18:46:47 changed by 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...

08/24/07 19:41:49 changed by 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.

(follow-up: ↓ 28 ) 08/24/07 20:36:09 changed by 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.

(in reply to: ↑ 27 ) 08/24/07 21:15:51 changed by 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.

09/07/07 11:13:53 changed by Nazgul

  • milestone changed from 2.3 to 2.4 (next).

Still too much discussion, so pushing to 2.4.

12/17/07 17:59:43 changed by 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/

12/31/07 02:08:00 changed by thee17

  • keywords changed from dev-feedback 2nd-opinion to has-patch dev-feedback 2nd-opinion.

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

(follow-up: ↓ 33 ) 01/18/08 11:10:23 changed by JeremyVisser

Can this be committed already?

(in reply to: ↑ 32 ; follow-up: ↓ 34 ) 01/18/08 11:21:33 changed by westi

  • keywords changed from has-patch dev-feedback 2nd-opinion to has-patch needs-docs.
  • owner changed from anonymous to westi.
  • status changed from reopened to new.

Replying to JeremyVisser:

Can this be committed already?

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

01/31/08 23:33:16 changed by Nazgul

  • attachment 3682.diff added.

(in reply to: ↑ 33 ) 01/31/08 23:34:14 changed by Nazgul

  • keywords changed from has-patch needs-docs to has-patch has-docs.
  • priority changed from high to normal.

Replying to westi:

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

Like this?

02/02/08 00:13:34 changed by ryan

  • status changed from new to closed.
  • resolution set to fixed.

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

02/06/08 21:21:22 changed by ryan

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