Проблема

По умолчанию в любом данном контексте 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(), основывают свои выходные данные на основном объекте запроса , $wp_query. Этот основной запрос может быть разбит на страницы, а может и не быть. Если текущий контекст является пользовательским шаблоном страницы, например, основной объект $wp_query будет состоять только из одной записи - идентификатора страницы, которой назначен пользовательский шаблон страницы.

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

В Решение

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

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

$custom_query_args = array(
    // Custom query parameters go here
);

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

get_query_var( 'paged' );

Затем вы можете добавить этот параметр в массив аргументов пользовательского запроса:

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

Примечание: Если ваша страница является статической первая страница, обязательно используйте page вместо paged, поскольку статическая первая страница использует 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->max_num_pages:

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

Собирая все это вместе

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

// Define custom query parameters
$custom_query_args = array( /* Parameters go here */ );

// Get current page and append to custom query parameters array
$custom_query_args['paged'] = get_query_var( 'paged' ) ? get_query_var( 'paged' ) : 1;

// Instantiate custom query
$custom_query = new WP_Query( $custom_query_args );

// Pagination fix
$temp_query = $wp_query;
$wp_query   = NULL;
$wp_query   = $custom_query;

// Output custom query loop
if ( $custom_query->have_posts() ) :
    while ( $custom_query->have_posts() ) :
        $custom_query->the_post();
        // Loop output goes here
    endwhile;
endif;
// Reset postdata
wp_reset_postdata();

// Custom query loop pagination
previous_posts_link( 'Older Posts' );
next_posts_link( 'Newer Posts', $custom_query->max_num_pages );

// Reset main query object
$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 ) {
    // Test for category archive index
    // and ensure that the query is the main query
    // and not a secondary query (such as a nav menu
    // or recent posts widget output, etc.
    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 ) {
    // Test for main blog posts index
    // and ensure that the query is the main query
    // and not a secondary query (such as a nav menu
    // or recent posts widget output, etc.
    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 при определении разбиения на страницы, без необходимости изменения шаблона.

Когда использовать какую функцию

Исследуйте этот вопрос и ответ и этот вопрос и ответ , чтобы понять, как и когда использовать WP_Query, pre_get_posts, и query_posts().