Щоразу, коли ви працюєте з шаблонами архівів у 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, коли це можливо.