WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#3682 closed defect (bug) (fixed)

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

Reported by: johnbillion Owned by: westi
Milestone: 2.5 Priority: normal
Severity: normal Version: 2.1
Component: Template Keywords: has-patch has-docs
Focuses: 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.
  1. Choose a static page to use as your front page.
  1. Insert a simple is_home() test in your template.
  1. Observe the result of the is_home() function is false

Attachments (3)

is_home.fix.diff (468 bytes) - added by m0n5t3r 8 years ago.
is_front.001.diff (640 bytes) - added by markjaquith 8 years ago.
adds is_front() function
3682.diff (925 bytes) - added by Nazgul 7 years ago.

Download all attachments as: .zip

Change History (39)

@m0n5t3r8 years ago

comment:1 @m0n5t3r8 years ago

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

comment:2 follow-up: @filosofo8 years ago

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.

comment:3 @johnbillion8 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:4 @Viper007Bond8 years ago

That does sound like a very useful function.

comment:5 @Viper007Bond8 years ago

  • Milestone 2.1.1 deleted

comment:6 in reply to: ↑ 2 @foolswisdom8 years ago

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"

comment:7 @johnbillion8 years ago

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.

comment:8 @rob1n8 years ago

  • Keywords dev-feedback 2nd-opinion added; is_home removed
  • Resolution wontfix deleted
  • Status changed from closed to reopened

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.

comment:9 @majelbstoat8 years ago

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.

comment:10 @markjaquith8 years ago

  • Milestone set to 2.2

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

comment:11 @JeremyVisser8 years ago

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?

comment:12 @majelbstoat8 years ago

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.

comment:13 @markjaquith8 years ago

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.

comment:14 follow-up: @markjaquith8 years ago

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()

comment:15 @markjaquith8 years ago

  • Description modified (diff)
  • 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

@markjaquith8 years ago

adds is_front() function

comment:16 @markjaquith8 years ago

is_front() patch added

comment:17 @filosofo8 years ago

+1 for Mark's idea.

comment:18 in reply to: ↑ 14 @foolswisdom8 years ago

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.

comment:19 @markjaquith8 years ago

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.

comment:20 @andy8 years ago

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_*.

comment:21 @andy8 years ago

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.

comment:22 @ryan8 years ago

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.

comment:23 @markjaquith8 years ago

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

comment:24 @foolswisdom8 years ago

  • Milestone changed from 2.2 to 2.3

comment:25 @joostdevalk8 years ago

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...

comment:26 @Otto428 years ago

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.

comment:27 follow-up: @Nazgul8 years ago

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.

comment:28 in reply to: ↑ 27 @Otto428 years ago

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.

comment:29 @Nazgul7 years ago

  • Milestone changed from 2.3 to 2.4 (next)

Still too much discussion, so pushing to 2.4.

comment:30 @gfindlay7 years ago

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/

comment:31 @thee177 years ago

  • Keywords has-patch added

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

comment:32 follow-up: @JeremyVisser7 years ago

Can this be committed already?

comment:33 in reply to: ↑ 32 ; follow-up: @westi7 years ago

  • Keywords needs-docs added; dev-feedback 2nd-opinion removed
  • 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 :-)

@Nazgul7 years ago

comment:34 in reply to: ↑ 33 @Nazgul7 years ago

  • Keywords has-docs added; needs-docs removed
  • Priority changed from high to normal

Replying to westi:

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

Like this?

comment:35 @ryan7 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:36 @ryan7 years ago

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

Note: See TracTickets for help on using tickets.