Всякий раз, когда вы работаете с шаблонами архивов в WordPress, сообщения обычно перечислены по дате в порядке убывания. То есть самые последние посты перечислены вверху, а дальше уже оттуда.
В последнее время я работал над несколькими проектами, которые интегрируются со сторонними API. Эти API возвращают даты — иногда две даты, дату начала и дату окончания — для данного события, и клиенты хотят использовать эту информацию для составления списка сообщений, а не даты публикации. То есть им нужны настраиваемые шаблоны архивов.
Это не слишком сложно сделать, но перед этим, я думаю, важно дать некоторую справочную информацию о том, как построен проект, чтобы было немного больше контекста, почему, скажем, необходим пользовательский запрос и почему вы можете или можете не нужно заглядывать в pre_get_posts.
Однако сначала я начну с TL;DR. Таким образом, вы можете получить представление, прежде чем читать все это.
Пользовательские шаблоны архивов
Итак, TL;DR, стоящий за всем этим, таков:
- информация о дате, предоставленная сторонним API, хранится в таблице метаданных публикации,
- ключ — это дата начала, а значение — фактическая дата,
- Я упорядочиваю контент в порядке убывания и по мета-значению.
Разбивка на страницы может быть проблемой, и если вы используете пользовательский тип записи, вам понадобятся некоторые дополнительные параметры, но общая идея такова.
Теперь о всей настройке.
Пользовательские типы сообщений
Когда дело доходит до взаимодействия со сторонними API, я большой поклонник пользовательских типов сообщений, потому что я склонен думать о них как о гибриде между моделями и представлениями.
- Компонент модели включает в себя все, что косвенно связано и может быть записано в базу данных. Это означает любую информацию о таксономии или метаданные публикации.
- Компонент представления — это, как правило, все, что входит в шаблон, который может использовать любые ранее существовавшие теги шаблона, — это все, что может потребоваться создать, что также считывает информацию из базы данных.
Для этого поста я буду использовать acme-event в качестве пользовательского типа поста.
Опубликовать метаданные
Я устанавливаю даты в метаданных сообщения, а не в самом сообщении, потому что, если что-то произойдет в будущем, и данные будут установлены в самой записи сообщения, тогда WordPress будет рассматривать это как запланированное сообщение, которое не опубликовано. .
Вместо этого я бы предпочел опубликовать сообщение, а затем изменить способ отображения метаданных в шаблоне.
Пагинация
WordPress делает тонкое различие с нумерацией страниц в своей кодовой базе. То есть переменная запроса для сайтов без статической домашней страницы использует paged, а в противоположном случае — page.
Это имеет значение, когда вы создаете аргументы для запроса, к которому я сейчас перейду.
Только страницы архива
Помните, что всякий раз, когда вы вводите разбиение на страницы, вы хотите изменить запрос только тогда, когда вы находитесь на фактической странице архива.
Это означает, что вам не нужны случаи, когда вы находитесь в административной области WordPress и не хотите изменять запрос для архивов нестандартного типа записи. С этой целью вам нужно убедиться, что вы правильно устанавливаете переменную запроса в обратном вызове pre_get_posts.
Обратите внимание, что я могу показать функцию, как это сделать, но из-за того, как мы пишем код в WordPress — то есть одни пишут процедурный код, другие пишут объектно-ориентированный код — я просто покажу его в процедурном коде.
Собираем все вместе
Сначала я создам запрос:
<?php
$eventQuery = new WP_Query([
'post_type' => 'acme-events',
'post_status' => 'publish',
'orderby' => 'meta_value',
'order' => 'desc',
'meta_key' => 'acme-event-start-date-time',
'posts_per_archive_page' => 5,
'paged' => get_query_var('paged')? get_query_var('paged'): 1
]);Обратите внимание, что в приведенном выше коде есть аргумент paged. Я сейчас расскажу о коде для этого.
Затем шаблон будет включать любую информацию, которую вы решите отобразить. Я решил не публиковать код своего шаблона в этом посте, потому что он не имеет отношения к основной идее.
Кроме того, у вас есть все необходимое для отображения контента.
Далее я установлю пагинацию. Во-первых, мне нужно сделать это с помощью хука pre_get_posts, чтобы убедиться, что установлена правильная переменная запроса :
<?php
add_action('pre_get_posts', 'setCustomQueryVariable');
public function setCustomQueryVariable($query)
{
if (is_admin() || !is_archive()) {
return;
}
if ($query->is_archive('acme-events')) {
set_query_var('posts_per_page', 5);
}
}Затем я реализую разбиение на страницы с помощью пользовательского запроса:
<?php
<a class="next page-numbers" href="<?php echo esc_attr(get_next_posts_page_link($eventQuery->max_num_pages)); ?>">
Next Page
</a>
<a class="prev page-numbers" href="<?php echo esc_attr(get_previous_posts_page_link()); ?>">
Previous Page
</a>И после этого я сбрасываю глобальную переменную $post с помощью wp_reset_postdata() на всякий случай, если нужно будет использовать что-то из исходного сообщения.
<?php wp_reset_postdata(); ?>В любом случае, это обычно считается хорошей уборкой всякий раз, когда вы используете пользовательский запрос.
Полезные ссылки
Ниже приведен список функций, страниц и ссылок, которые могут оказаться полезными, поскольку они относятся к приведенному выше коду или любой будущей работе, которую вы можете выполнить.
- WP_Query
- Пагинация
- pre_get_posts
- get_query_var
- set_query_var
- get_next_posts_page_link
- get_previous_posts_page_link
- update_post_meta
- wp_reset_postdata
- Полный код в этом посте.
Если вы давно работаете с WordPress, некоторые из них могут показаться излишними. В других случаях это может показаться новым или может пролить свет на области API WordPress, о существовании которых вы не знали (по крайней мере, так было со мной).
Зачем заморачиваться со всем этим?
Это может показаться длинным постом для, казалось бы, простой задачи, но информация немного разбросана по всему Интернету, поскольку она относится к выполнению чего-то подобного.
Поэтому я хотел попытаться собрать все это вместе с пояснениями, примерами кода и ссылками на страницы, которые могут представлять интерес в зависимости от того, как выполняется реализация.
В конце концов, на данный момент многие из нас используют WordPress помимо базового управления контентом, но это не значит, что мы не должны использовать его встроенные функции и API, когда это возможно.