Пагинация возвращает 404 после страницы 20

I got a paged loop that pulls in 4 posts per page from custom post type. It works great, with the only downside that the pagination wont go over the page/20 everything after that is 404, and the posts_nav_link won’t show the next arrow at all. Like the pages just aren’t there.

Я получил постраничный цикл, который извлекает 4 поста на страницу из пользовательского типа записей. Это хорошо работает, с единственным недостатком, что нумерация страниц не работает после 20, а posts_nav_link вообще не показывает следующую. Как будто страниц просто нет.

Вот мой код:

<?php
$paged = get_query_var('paged') ? get_query_var('paged') : 1;
$args  = array(
    'posts_per_page' => 4,
    'orderby'        => 'modified',
    'post_type'      => "projekte",
    'paged'          => $paged
);
$custom_query = new WP_Query($args);
$c = 0;
while($custom_query->have_posts()) :
    $custom_query->the_post();
    ?>
    <article>...</article>
    <?php
endwhile;
wp_reset_postdata();
?>

Я много раз просматривал файл functions.php в поисках ограничивающего фильтра get_pre_posts, но ничего не вижу.

В журнале ошибок тоже ничего нет.

Понравилась статья? Поделиться с друзьями:
WPAsk
Ответов: 2
  1. Pieter Goosen

    Сделайте тест, добавьте 'suppress_filters' => true, для ваших аргументов. Это запретит всем фильтрам изменять ваш запрос. Просто ради интереса, в каком шаблоне вы делаете это

  2. Pieter Goosen

    То, что вы испытываете, вполне нормально и ожидаемо. Это одна из главных причин, по которой я всегда склоняюсь к этому, никогда не использую пользовательские запросы для замены основного запроса на домашней странице или на странице архива любого типа. Они решают одну проблему, но создают множество новых.

    Давайте посмотрим, что у вас есть и почему вы получаете эти результаты:

    Основы

    Хотя вы не видите вывод на своей странице архива, основной запрос выполняется при каждой загрузке страницы и возвращает массив записей независимо от этого. Удаление цикла не останавливает выполнение основного запроса. Цикл просто отображает то, что извлекается основным запросом. Итак, что в основном происходит, вы получаете два набора постов на страницу загрузки, если вы замените цикл по умолчанию на собственный. Записи, полученные с помощью основного запроса, и записи, полученные с помощью пользовательского запроса. Если вы хотите проверить это, добавьте следующую строку кода вне цикла на странице архива в тегах php

    ?><pre><?php var_dump( $wp_query->posts ); ?></pre><?php
    

    Это выведет массив записей, полученных основным запросом на этой конкретной странице

    Это делает пользовательские запросы очень неэффективными, когда заменяется основной запрос.

    Ваш сценарий

    • 119 записей из вашего пользовательского типа

    • Количество постов на странице — 6

    • Пользовательский запрос настроен на получение 4 записей на странице

    Ваш основной запрос вернет 20 страниц, которые вы можете протестировать с помощью $wp_query->max_num_pages;. Математика проста, у вас есть 119 записей, которые вы также можете проверить с помощью echo $wp_query->found_posts;, количество записейна странице установлено 6 для администратора, поэтому 119/6 = 20

    Что касается пользовательского запроса, вы можете получить доступ к той же информации, что и выше, изменив $wp_query на $custom_query . Вы увидите, что у вас все еще есть 119 записей, но у вас будет 30 страниц, потому что количество записей на странице теперь установлено 4. Верхний предел для 119/4 = 30

    Ошибка 404 на странице 21

    Всякий раз, когда по основному запросу нет записей для отображения, запускается 404, и это то, что вы видите. Есть достаточно записей, чтобы заполнить 20 страниц, а не 21 или больше. Поэтому, когда вы переходите на страницу 21, основной запрос 404 выполняется просто потому, что больше нет записей для отображения, независимо от того, есть ли еще что-то, что можно отобразить из пользовательского запроса.

    Я видел посты, в которых люди говорят, что решение легко, просто измените количество постов на странице на странице администратора, чтобы оно соответствовало вашему пользовательскому запросу. Никогда не делай этого . Да, это решает проблему, но она устраняет реальную проблему, заключающуюся в том, что вы не должны заменять основной запрос на пользовательский. И кстати, реальное решение проблемы довольно простое, чистое и является правильным правильным методом для достижения того, что вам нужно

    Почему кастомный запрос

    Вы решили выполнить пользовательский запрос из-за двух вещей

    • Различное количество постов на странице архива вашего пользовательского типа поста, что и на остальной части сайта

    • Посты, отсортированные по дате изменения, а не по умолчанию

    Как видите, вы решили две проблемы с помощью пользовательского запроса, но создали другие проблемы

    Решение

    Это правильный, простой способ решить вашу проблему. Используйте pre_get_posts , чтобы изменить основной запрос перед его выполнением. pre_get_posts соответственно изменяет переменные запроса, которые используются для вычисления запроса SQL для конкретного запроса страницы.

    Здесь нужно сделать две вещи, во-первых, удалить свой пользовательский запрос на странице архива и заменить его циклом по умолчанию. Как только вы это сделаете, вы увидите 6 постов на странице, упорядоченных по дате публикации, как и должно быть по умолчанию.

    add_action( 'pre_get_posts', function ( $q ) 
    {
        if(    !is_admin() 
            && $q->is_main_query() 
            && $q->is_post_type_archive( 'projekte' ) 
        ) {
            $q->set( 'posts_per_page', 4          );
            $q->set( 'orderby',        'modified' );
        }
    });
    

    Теперь вы должны видеть 4 записи на странице, упорядоченные по дате изменения, правильно размещенные на странице архива настраиваемого типа записей projekte

Добавить ответ

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: