[wp-hackers] is_front_page() after modifying query_posts

[Jeremy Clarke]

On Fri, Mar 11, 2011 at 3:22 PM, Otto <otto at ottodestruct.com> wrote:

>
> First, in WP, *all* pages are really "index.php". So I assume you
> meant for the root page. http://example.com/ for example.
>
>
Sidenote: "Root page" is a MUCH better label than "front page" which is not
very clear, especially in relation to "home" which is semantically
equivalent to "front page" but in this case indicates an important
difference.

How many puppies would need to be sacrificed to get these two confusing
functions to be deprecated in favor of is_root() and is_blog(). is_blog()
would tell you if you are on the 'posts archive', whether it is on the root
or in a 'page'.

As for the question about is_front_page() I think it's worth dealing with
extra hassle for the consistency in this case.

I really don't think anyone should use query_posts() for any reason ever, so
the fact that the change would help that use-case makes me even less
friendly to it. query_posts is ALWAYS the wrong way to do something. If what
you want is a secondary query to add to the main content (more headlines,
related etc.) you should use new WP_Query() to avoid overwriting the main
query. If what you want is to modify the main query then query_posts is
terrible because it lets the main query still run, then just throws away the
original results in favor of the new ones. This means a very wasteful posts
query (in my case doing it that way was really hurting database performance
till i fixed it).

By comparison you are way better off modifying the query using filters on
the original main query, inserting whatever values it is you want. This
keeps the single posts query and also helps you preserve any other query
values that you don't predict, like paging and homepage status. Filtering
the main query is pretty tricky but IMHO it is the right way to do it, and
if you do it that way you don't have to worry about is_front_page getting
mangled.

So far the biggest issue I had with this was being able to identify only the
main query. I think there is a new function for it in 3.0/3.1 that I
couldn't use, so it's probably easier now. My solution was to attach an
action to 'pre_get_posts' which runs before every query, but remove the
action inside itself, so that it only ran once, on the very first query
which was also the main query.

-- 
Jeremy Clarke • jeremyclarke.org
Code and Design • globalvoicesonline.org