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
, но ничего не вижу.
В журнале ошибок тоже ничего нет.
Сделайте тест, добавьте
'suppress_filters' => true,
для ваших аргументов. Это запретит всем фильтрам изменять ваш запрос. Просто ради интереса, в каком шаблоне вы делаете этоТо, что вы испытываете, вполне нормально и ожидаемо. Это одна из главных причин, по которой я всегда склоняюсь к этому, никогда не использую пользовательские запросы для замены основного запроса на домашней странице или на странице архива любого типа. Они решают одну проблему, но создают множество новых.
Давайте посмотрим, что у вас есть и почему вы получаете эти результаты:
Основы
Хотя вы не видите вывод на своей странице архива, основной запрос выполняется при каждой загрузке страницы и возвращает массив записей независимо от этого. Удаление цикла не останавливает выполнение основного запроса. Цикл просто отображает то, что извлекается основным запросом. Итак, что в основном происходит, вы получаете два набора постов на страницу загрузки, если вы замените цикл по умолчанию на собственный. Записи, полученные с помощью основного запроса, и записи, полученные с помощью пользовательского запроса. Если вы хотите проверить это, добавьте следующую строку кода вне цикла на странице архива в тегах 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 постов на странице, упорядоченных по дате публикации, как и должно быть по умолчанию.
Теперь вы должны видеть 4 записи на странице, упорядоченные по дате изменения, правильно размещенные на странице архива настраиваемого типа записей
projekte