Shouldn't there be a mention of the 'include_children' parameter for tax_query? It's important and works at least with categories to stop hierarchical child posts from being returned. JeremyClarke

---

I hope I was correct in adding a short example using wp_reset_query. I felt this was an important addition to this page as it has certainly solved me a lot of head-scratching.

Alex 09:07, 19 October 2010 (UTC)

paged != page

Pagination_Parameters says that:

You should set get_query_var( 'page' ); if you want your query to work with pagination. Since Wordpress 3.0.2, you do get_query_var( 'page' ) instead of get_query_var( 'paged' ). The pagination parameter 'paged' for WP_Query() remains the same.

But AFAIK, recent WP uses paged, not page. Amiright?

Your comment is old, but it looks like the paged / page documentation is still screwy. It currently states:

page (int) - number of page for a static front page. Show the posts that would normally show up just on page X of a Static Front Page.

That suggests that the 'page' parameter is only used in one case: the static front page. From my research it seems that this isn't the case, and it's used any time you have a single page broken up into <!--nextpage-->. I'm not confident enough in this to update the page, but as it's worded I find it raises more questions than it answers.

Webaware 09:13, 5 September 2012 (UTC)

Modified the usage example

Strange enough it wasn't done before, in second example you don't need to use the global $post and get to maintain your local $post variable.

Can somebody confirm the pagination parameters are correct

Has the "paged" query var changed in recent versions (as Webaware mentions above)? The "page" query var is used when a single post/page is paginated (), or for a static front page (template) with a query on the loop. On all other template files the query var is "paged". I don't think this has ever changed and the information on this parameter is very confusing (or wrong). Can somebody confirm this.

Keesiemeijer 11:15, 14 September 2012 (UTC)

Pagination Parameters

I added notes that any 'offset' parameter is ignored when 'posts_per_page'=>-1 is used. The underlying reason for this is probably too pedantic to justify explanation in the main article, yet should be documented so no one needs to figure out why again. The added notes are a result of Trac #26833.

The offset and posts_per_page values find their way into the SQL query string as part of the LIMIT clause, which is constructed something like this:

$query .="LIMIT $offset,$posts_per_page";

When 'posts_per_page'=> -1 is used (to return all posts), the entire LIMIT clause is dropped, so observing the offset value in such a case is problematic. Where would the value be placed?

The LIMIT clause is used primarily for pagination where the offset value alone would be illogical. If someone should need to query for all posts except the first n posts, they would need to supply a ridiculously large number for 'posts_per_page' to ensure all posts except for the n offset are returned. - Bcworkz 08:21, 18 January 2014 (UTC)

The the_title() function in this example

the codex you can prepend and append markup around the_title(). This example does not do that. There should also be a feature to extend get_the_title() to allow more than just the $id since that exist in the_title()

 <?php the_title( $before, $after, $echo ); ?> 

inetbizo 10:28, 6 February 2014 (UTC)

Hi Inetbizo. I don't think that it is necessary to use the full features of the_title() in these examples. The examples are demonstrating the use of WP_Query, and should be kept as simple as possible in regard to the other functions used.

As for as adding the $before and $after parameters to get_the_title(), I don't think that is necessary. You can just use the_title() for this, with the $echo parameter set to false, or just handle it yourself. If you still think it is a useful feature, you could open up a new ticket for it on WordPress Trac, which is the place to request such features.

Jdgrimes 14:38, 6 February 2014 (UTC)

Multiple Loops example

Currently, the Multiple Loops example includes this block after using each of two new WP_Query instances:

/* Restore original Post Data 
 * NB: Because we are using new WP_Query we aren't stomping on the 
 * original $wp_query and it does not need to be reset.
*/
wp_reset_postdata();

The comment seems to indicate the call to wp_reset_postdata() is un-necessary, or am I mis-understanding something? I thought that IF I'm using the global WP_Query object, I should reset the postdata after I'm done, but in this case, we're using our own WP_Query instance...no? FrancescoRizzi 15:09, 25 May 2014 (UTC)

Hi Francesco. The call to wp_reset_postdata() is necessary. You just don't need to call wp_reset_query(). You only need to reset the post data to that of the main query (the $post global), but you don't need to reset the entire query (the $wp_query global). I've made an edit to clarify this. You may find this visualization of it on the query_posts() page helpful.

-Jdgrimes 13:14, 26 May 2014 (UTC)

Thank you Jdgrimes. I like the edit and the related links you provided: they helped me understand the difference! FrancescoRizzi 00:43, 28 May 2014 (UTC)

"pagename" for page slug

This doesn't seem to work anymore (4.2.2). I used 'name' to successfully pull a page by it's slug.

Maybe this is a bug, or you are using a plugin that is modifying the behavior. Does it make any difference if you set 'post_type' => 'page'? -Jdgrimes (talk) 13:22, 7 July 2015 (UTC)