Как исправить нумерацию страниц для пользовательских циклов?

Проблема

По умолчанию в любом данном контексте WordPress использует основной запрос для определения нумерации страниц. Основной объект запроса хранится в глобальном $wp_query, который также используется для вывода основного цикла запроса:

if ( have_posts() ) : while ( have_posts() ) : the_post();

Когда вы используете пользовательский запрос, вы создаете совершенно отдельный объект запроса:

$custom_query = new WP_Query( $custom_query_args );

И этот запрос выводится через совершенно отдельный цикл:

if ( $custom_query->have_posts() ) : 
    while ( $custom_query->have_posts() ) : 
        $custom_query->the_post();

Но теги шаблона нумерации страниц, в том числе previous_posts_link(), next_posts_link(), posts_nav_link(), и paginate_links(), базируются на основном объекте запроса main query object, $wp_query. Этот основной запрос может быть или не быть разбит на страницы. Например, если текущий контекст представляет собой пользовательский шаблон страницы, основной объект $wp_query будет состоять только из одного сообщения — идентификатора страницы, которой назначен пользовательскому шаблону страницы.

Если текущий контекст является каким-либо архивным индексом, основной $wp_query может состоять из достаточного количества сообщений, чтобы вызвать разбиение на страницы, что приводит к следующей части проблемы: для основного $wp_query Объект , WordPress передает в запрос параметр paged , основанный на переменной запроса URL paged . Когда запрос извлекается, этот параметр paged будет использоваться для определения того, какой набор постраничных постов должен возвращаться. Если щелкнуть на отображаемую ссылку нумерации страниц и загрузить следующую страницу, ваш пользовательский запрос не сможет узнать, что нумерация страниц изменилась .

Решение

Передача правильного постраничного параметра в пользовательский запрос

Предполагая, что пользовательский запрос использует массив args:

$custom_query_args = array(
    // Пользовательские параметры запроса
);

Вам нужно будет передать в массив правильный параметр paged . Это можно сделать, выбрав переменную запроса URL-адреса, используемую для определения текущей страницы, с помощью get_query_var() :

get_query_var( 'paged' );

Затем вы можете добавить этот параметр в ваш массив args запроса:

$custom_query_args['paged'] = get_query_var( 'paged' ) 
    ? get_query_var( 'paged' ) 
    : 1;

Примечание. Если ваша страница является статической главной страницей , обязательно используйте page вместо paged в качестве статической главной страницы.

$custom_query_args['paged'] = get_query_var( 'page' ) 
    ? get_query_var( 'page' ) 
    : 1;

Теперь при получении пользовательского запроса будет возвращен правильный набор постраничных постов.

Использование пользовательского объекта запроса для функций разбиения на страницы

Чтобы функции разбиения на страницы могли выдавать правильный вывод, т. е. ссылки на предыдущую / следующую страницу, относящиеся к пользовательскому запросу, WordPress необходимо принудительно распознать пользовательский запрос. Это требует некоторого «взлома»: замена основного объекта $ wp_query на пользовательский объект запроса, $custom_query :

«Взлом» основного объекта запроса:

1. Резервная копия основного объекта запроса: $temp_query = $wp_query
2. Обнулить основной объект запроса: $wp_query = NULL;

3. Изменение пользовательского запроса на основной объект запроса: $wp_query = $custom_query;

   $temp_query = $wp_query;
   $wp_query   = NULL;
   $wp_query   = $custom_query;
   

Этот хак должен быть выполнен перед вызовом любых функций нумерации страниц

Сбросить основной объект запроса

После того, как функции пагинации были выведены, сбросьте основной объект запроса:

$wp_query = NULL;
$wp_query = $temp_query;

Исправления функции пагинации

Функция previous_posts_link () будет работать нормально, независимо от нумерации страниц. Она просто определяет текущую страницу, а затем выводит ссылку для page - 1 . Однако для корректного вывода next_posts_link () требуется исправление. Это происходит потому, что next_posts_link () использует max_num_pages параметр:

<?php next_posts_link( $label , $max_pages ); ?>

Как и в случае с другими параметрами запроса, по умолчанию функция будет использовать max_num_pages для основного объекта $wp_query . Чтобы заставить next_posts_link() отвечать за Объект $custom_query , вам нужно будет передать функцию max_num_pages в функцию. Вы можете получить это значение из объекта $custom_query : $custom_query- & gt; max_num_pages :

<?php next_posts_link( 'Older Posts' , $custom_query->max_num_pages ); ?>

Все вместе

Ниже приведена базовая конструкция пользовательского цикла запроса с правильно функционирующими функциями нумерации страниц:

// Определить пользовательские параметры запроса
$custom_query_args = array( /* Параметры */ );

// Получить текущую страницу и добавить к массиву пользовательских параметров запроса
$custom_query_args['paged'] = get_query_var( 'paged' ) ? get_query_var( 'paged' ) : 1;

// Создание пользовательского запроса
$custom_query = new WP_Query( $custom_query_args );

// Исправление нумерации страниц
$temp_query = $wp_query;
$wp_query   = NULL;
$wp_query   = $custom_query;

// Вывод пользовательского цикла запроса
if ( $custom_query->have_posts() ) :
    while ( $custom_query->have_posts() ) :
        $custom_query->the_post();
        // Циклический выход
    endwhile;
endif;

wp_reset_postdata();

// Пользовательский цикл запроса разбиения на страницы 
previous_posts_link( 'Older Posts' );
next_posts_link( 'Newer Posts', $custom_query->max_num_pages );

// Сбросить основной объект запроса
$wp_query = NULL;
$wp_query = $temp_query;

Приложение: Как насчет query_posts()?

query_posts() для дочерних циклов

Если вы используете query_posts() для вывода пользовательского цикла, а не создание отдельного объекта для пользовательского запроса с помощью WP_Query() , тогда вы _doing_it_wrong() столкнетесь с несколькими проблемами (не наименьшими из которых будут проблемы нумерации страниц). Первым шагом к решению этих проблем будет устранение неправильного использования query_posts() на правильный WP_Query() .

Использование query_posts () для изменения основного цикла

Если вы просто хотите изменить параметры для запроса основного цикла — например, изменить посты на странице или исключить категорию — у вас может возникнуть желание использовать query_posts() . Но все равно не нужно. Когда вы используете query_posts() , вы заставляете WordPress заменить основной объект запроса. (На самом деле WordPress делает второй запрос и перезаписывает $wp_query .) Однако проблема в том, что он выполняет эту замену слишком поздно, чтобы обновить нумерацию страниц.

Решение состоит в том, чтобы отфильтровать основной запрос перед извлечением сообщений , с помощью ловушки pre_get_posts .

Вместо добавления этого в файл шаблона категории ( category.php ):

query_posts( array(
    'posts_per_page' => 5
) );

Добавьте следующий код в functions.php:

function wpse120407_pre_get_posts( $query ) {
  
    if ( is_category() && $query->is_main_query() ) {
        // Modify posts per page
        $query->set( 'posts_per_page', 5 ); 
    }
}
add_action( 'pre_get_posts', 'wpse120407_pre_get_posts' );

Вместо файла (home.php):

query_posts( array(
    'cat' => '-5'
) );

В functions.php:

function wpse120407_pre_get_posts( $query ) {
  
    if ( is_home() && $query->is_main_query() ) {
        // Exclude category ID 5
        $query->set( 'category__not_in', array( 5 ) ); 
    }
}
add_action( 'pre_get_posts', 'wpse120407_pre_get_posts' );

Таким образом, WordPress будет использовать уже измененный объект $ wp_query при определении нумерации страниц без необходимости изменения шаблона.