[ad_1]
\n<\/p>\n
By default, in any given context, WordPress uses the main query to determine pagination. The main query object is stored in the When you use a custom query<\/a>, you create an entirely separate query object:<\/p>\n And that query is output via an entirely separate loop:<\/p>\n But pagination template tags, including If the current context is an archive index of some sort, the main Assuming that the custom query uses an args array:<\/p>\n You will need to pass the correct You can then append that parameter to your custom query args array:<\/p>\n Note:<\/strong> If your page is a static front page<\/strong>, be sure to use Now, when the custom query is fetched, the correct set of paginated posts will be returned.<\/p>\n In order for pagination functions to yield the correct output – i.e. previous\/next\/page links relative to the custom query – WordPress needs to be forced to recognize the custom query. This requires a bit of a “hack”: replacing the main Swap the custom query into the main query object: This “hack” must be done before calling any pagination functions<\/em><\/p>\n Once pagination functions have been output, reset the main query object:<\/p>\n The As with other query parameters, by default the function will use The following is a basic construct of a custom query loop with properly functioning pagination functions:<\/p>\n If you’re using If you merely want to modify the parameters for the main loop query<\/em> – such as changing the posts per page, or excluding a category – you may be tempted to use The solution is to filter the main query before posts are fetched<\/em>, via the Instead of adding this to the category template file ( Add the following to Instead of adding this to the blog posts index template file ( Add the following to That way, WordPress will use the already-modified Research this question and answer and this question and answer to understand how and when to use $wp_query<\/code> global, which is also used to output the main query loop:<\/p>\nif ( have_posts() ) : while ( have_posts() ) : the_post();\n<\/code><\/pre>\n$custom_query = new WP_Query( $custom_query_args );\n<\/code><\/pre>\nif ( $custom_query->have_posts() ) : \n while ( $custom_query->have_posts() ) : \n $custom_query->the_post();\n<\/code><\/pre>\nprevious_posts_link()<\/code><\/a>, next_posts_link()<\/code><\/a>, posts_nav_link()<\/code><\/a>, and paginate_links()<\/code><\/a>, base their output on the main query object<\/em>, $wp_query<\/code>. That main query may or may not be paginated. If the current context is a custom page template, for example, the main $wp_query<\/code> object will consist of only a single post<\/em> – that of the ID of the page to which the custom page template is assigned. <\/p>\n$wp_query<\/code> may consist of enough posts to cause pagination, which leads to the next part of the problem: for the main $wp_query<\/code> object, WordPress will pass a paged<\/code> parameter to the query, based on the paged<\/code> URL query variable. When the query is fetched, that paged<\/code> parameter will be used to determine which set of paginated posts to return. If a displayed pagination link is clicked, and the next page loaded, your custom query won’t have any way to know that the pagination has changed<\/em>.<\/p>\nThe Solution<\/h1>\n
Passing Correct Paged Parameter to the Custom Query<\/h2>\n
$custom_query_args = array(\n \/\/ Custom query parameters go here\n);\n<\/code><\/pre>\npaged<\/code> parameter to the array. You can do so by fetching the URL query variable used to determine the current page, via get_query_var()<\/code><\/a>:<\/p>\nget_query_var( 'paged' );\n<\/code><\/pre>\n$custom_query_args['paged'] = get_query_var( 'paged' ) \n ? get_query_var( 'paged' ) \n : 1;\n<\/code><\/pre>\npage<\/code> instead of paged<\/code> as a static front page uses page<\/code> and not paged<\/code>. This is what you should have for a static front page<\/p>\n$custom_query_args['paged'] = get_query_var( 'page' ) \n ? get_query_var( 'page' ) \n : 1;\n<\/code><\/pre>\nUsing Custom Query Object for Pagination Functions<\/h2>\n
$wp_query<\/code> object with the custom query object, $custom_query<\/code>:<\/p>\nHack the main query object<\/h3>\n
\n
$temp_query = $wp_query<\/code><\/li>\n$wp_query = NULL;<\/code><\/li>\n$wp_query = $custom_query;<\/code><\/p>\n$temp_query = $wp_query;\n$wp_query = NULL;\n$wp_query = $custom_query;\n<\/code><\/pre>\n<\/li>\n<\/ol>\nReset the main query object<\/h3>\n
$wp_query = NULL;\n$wp_query = $temp_query;\n<\/code><\/pre>\nPagination Function Fixes<\/h2>\n
previous_posts_link()<\/code><\/a> function will work normally, regardless of pagination. It merely determines the current page, and then outputs the link for page - 1<\/code>. However, a fix is required for next_posts_link()<\/code><\/a> to output properly. This is because next_posts_link()<\/code><\/a> uses the max_num_pages<\/code> parameter:<\/p>\n<?php next_posts_link( $label , $max_pages ); ?>\n<\/code><\/pre>\nmax_num_pages<\/code> for the main $wp_query<\/code> object. In order to force next_posts_link()<\/code><\/a> to account for the $custom_query<\/code> object, you will need to pass the max_num_pages<\/code> to the function. You can fetch this value from the $custom_query<\/code> object: $custom_query->max_num_pages<\/code>:<\/p>\n<?php next_posts_link( 'Older Posts' , $custom_query->max_num_pages ); ?>\n<\/code><\/pre>\nPutting it all together<\/h1>\n
\/\/ Define custom query parameters\n$custom_query_args = array( \/* Parameters go here *\/ );\n\n\/\/ Get current page and append to custom query parameters array\n$custom_query_args['paged'] = get_query_var( 'paged' ) ? get_query_var( 'paged' ) : 1;\n\n\/\/ Instantiate custom query\n$custom_query = new WP_Query( $custom_query_args );\n\n\/\/ Pagination fix\n$temp_query = $wp_query;\n$wp_query = NULL;\n$wp_query = $custom_query;\n\n\/\/ Output custom query loop\nif ( $custom_query->have_posts() ) :\n while ( $custom_query->have_posts() ) :\n $custom_query->the_post();\n \/\/ Loop output goes here\n endwhile;\nendif;\n\/\/ Reset postdata\nwp_reset_postdata();\n\n\/\/ Custom query loop pagination\nprevious_posts_link( 'Older Posts' );\nnext_posts_link( 'Newer Posts', $custom_query->max_num_pages );\n\n\/\/ Reset main query object\n$wp_query = NULL;\n$wp_query = $temp_query;\n<\/code><\/pre>\nAddendum: What About
query_posts()<\/code>?<\/h1>\nquery_posts()<\/code> for Secondary Loops<\/h2>\nquery_posts()<\/code><\/a> to output a custom loop, rather then instantiating a separate object for the custom query via WP_Query()<\/code><\/a>, then you’re _doing_it_wrong()<\/code><\/a>, and will run into several problems (not the least<\/em> of which will be pagination issues). The first step to resolving those issues will be to convert the improper use of query_posts()<\/code><\/a> to a proper WP_Query()<\/code><\/a> call.<\/p>\nUsing
query_posts()<\/code> to Modify the Main Loop<\/h2>\nquery_posts()<\/code><\/a>. But you still shouldn’t. When you use query_posts()<\/code><\/a>, you force WordPress to replace<\/em> the main query object. (WordPress actually makes a second query, and overwrites $wp_query<\/code>.) The problem, though, is that it does this replacement too late in the process to update the pagination.<\/p>\npre_get_posts<\/code> hook.<\/p>\ncategory.php<\/code>):<\/p>\nquery_posts( array(\n 'posts_per_page' => 5\n) );\n<\/code><\/pre>\nfunctions.php<\/code>:<\/p>\nfunction wpse120407_pre_get_posts( $query ) {\n \/\/ Test for category archive index\n \/\/ and ensure that the query is the main query\n \/\/ and not a secondary query (such as a nav menu\n \/\/ or recent posts widget output, etc.\n if ( is_category() && $query->is_main_query() ) {\n \/\/ Modify posts per page\n $query->set( 'posts_per_page', 5 ); \n }\n}\nadd_action( 'pre_get_posts', 'wpse120407_pre_get_posts' );\n<\/code><\/pre>\nhome.php<\/code>):<\/p>\nquery_posts( array(\n 'cat' => '-5'\n) );\n<\/code><\/pre>\nfunctions.php<\/code>:<\/p>\nfunction wpse120407_pre_get_posts( $query ) {\n \/\/ Test for main blog posts index\n \/\/ and ensure that the query is the main query\n \/\/ and not a secondary query (such as a nav menu\n \/\/ or recent posts widget output, etc.\n if ( is_home() && $query->is_main_query() ) {\n \/\/ Exclude category ID 5\n $query->set( 'category__not_in', array( 5 ) ); \n }\n}\nadd_action( 'pre_get_posts', 'wpse120407_pre_get_posts' );\n<\/code><\/pre>\n$wp_query<\/code> object when determining pagination, with no template modification required. <\/p>\nWhen to use what function<\/h2>\n
WP_Query<\/code><\/a>, pre_get_posts<\/code><\/a>, and query_posts()<\/code><\/a>.<\/p>\n<\/p><\/div>\n