Za każdym razem, gdy pracujesz z szablonami archiwów w WordPress, posty są zazwyczaj sortowane według dat w porządku malejącym. Oznacza to, że najnowsze posty są wymienione na górze, a następnie zaczynają się stamtąd.
Ostatnio pracowałem nad kilkoma projektami, które integrują się z zewnętrznymi API. Te interfejsy API zwracają daty — czasami dwie daty, datę rozpoczęcia i datę zakończenia — dla danego wydarzenia, a klienci chcą używać tych informacji do wyświetlania postów, a nie ich daty. Oznacza to, że chcą niestandardowych szablonów archiwów.
Nie jest to zbyt trudne, ale zanim to zrobisz, myślę, że ważne jest, aby podać pewne podstawowe informacje na temat budowy projektu, aby uzyskać nieco więcej kontekstu, dlaczego, powiedzmy, potrzebne jest niestandardowe zapytanie i dlaczego możesz lub możesz nie trzeba zaglądać do pre_get_posts.
Zacznę jednak najpierw od TL;DR. W ten sposób możesz uzyskać pomysł przed przeczytaniem całości.
Niestandardowe szablony archiwum
Więc TL; DR za tym wszystkim jest tak:
- informacje o dacie dostarczone przez zewnętrzne API są przechowywane w tabeli metadanych postu,
- kluczem jest data rozpoczęcia, a wartość rzeczywista data,
- Uporządkowałem zawartość w porządku malejącym i według wartości meta.
Podział na strony może stanowić pewien problem, a jeśli używasz niestandardowego typu postu, będziesz potrzebować dodatkowych parametrów, ale jest to ogólna idea.
Teraz cała konfiguracja.
Niestandardowe typy postów
Jeśli chodzi o interfejs z zewnętrznymi interfejsami API, jestem wielkim fanem niestandardowych typów postów, ponieważ myślę o nich jako o hybrydzie między modelami i widokami.
- Składnik modelu zawiera wszystko, co jest stycznie powiązane i można je zapisać w bazie danych. Oznacza to wszelkie informacje o taksonomii lub post metadane.
- Komponent widoku to na ogół wszystko, co wchodzi do szablonu, które może wykorzystywać wszelkie wcześniej istniejące znaczniki szablonu, to wszystko, co może wymagać utworzenia, a także odczytuje informacje z bazy danych.
W tym poście użyję acme-event jako niestandardowego typu posta.
Opublikuj metadane
Ustawiam daty w metadanych postu, a nie w samym poście, ponieważ jeśli coś ma się wydarzyć w przyszłości, a dane są ustawione w samym rekordzie posta, WordPress potraktuje to jako zaplanowany post, który nie jest opublikowany .
Zamiast tego wolałbym opublikować post, a następnie zmienić sposób wyświetlania metadanych w szablonie.
Paginacja
WordPress wprowadza subtelne rozróżnienie z paginacją w swoim kodzie. Oznacza to, że zmienna zapytania dla witryn bez statycznej strony głównej wykorzystuje paged, a w przeciwnym przypadku — page.
Ma to znaczenie, gdy konstruujesz argumenty zapytania, do których za chwilę przejdę.
Tylko strony archiwum
Pamiętaj, że za każdym razem, gdy wprowadzasz paginację, chcesz zmienić zapytanie tylko wtedy, gdy jesteś na właściwej stronie archiwum.
Oznacza to, że nie przejmujesz się przypadkami, gdy jesteś w obszarze administracyjnym WordPressa i nie chcesz zmieniać zapytania dla archiwów innych niż niestandardowe posty. W tym celu upewnij się, że poprawnie ustawiasz zmienną zapytania w wywołaniu zwrotnym pre_get_posts.
Zauważ, że mogę pokazać funkcję, jak to zrobić, ale ze względu na to, jak piszemy kod w WordPressie – to znaczy niektórzy piszą kod proceduralny, inni piszą kod obiektowy – po prostu wyświetlę to w kodzie proceduralnym.
Łącząc to wszystko razem
Najpierw zbuduję zapytanie:
<?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
]);Zauważ, że w powyższym kodzie znajduje się argument paged. Za chwilę powiem o kodzie.
Następnie szablon będzie zawierał wszelkie informacje, które zdecydujesz się wyświetlić. Zdecydowałem się nie udostępniać kodu do mojego szablonu w tym poście, ponieważ nie ma to znaczenia dla większego pomysłu.
Dodatkowo masz wszystko, czego potrzebujesz do wyświetlania treści.
Następnie ustawię paginację. Najpierw muszę to zrobić za pomocą haka pre_get_posts, aby upewnić się, że ustawiona jest właściwa zmienna zapytania :
<?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);
}
}Następnie zaimplementuję paginację za pomocą niestandardowego zapytania:
<?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>A potem zresetuję globalną zmienną $post za pomocą wp_reset_postdata() na wypadek, gdyby trzeba było użyć czegokolwiek z oryginalnego postu.
<?php wp_reset_postdata(); ?>Jest to ogólnie uważane za dobre porządkowanie za każdym razem, gdy używasz niestandardowego zapytania.
Przydatne linki
Poniżej znajduje się lista funkcji, stron i odniesień, które mogą okazać się przydatne, ponieważ odnoszą się do powyższego kodu lub jakiejkolwiek przyszłej pracy, którą możesz wykonać.
- WP_Query
- Paginacja
- 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
- Pełny kod w tym poście.
Jeśli pracujesz z WordPressem od dłuższego czasu, niektóre z nich mogą wydawać się zbędne. W innych przypadkach może wydawać się nowy lub może rzucić światło na obszary API WordPressa, o których istnieniu nie wiedziałeś (przynajmniej tak było w moim przypadku).
Po co zawracać sobie głowę tym wszystkim?
Może się to wydawać długim postem dla pozornie prostego zadania, ale informacje są nieco rozproszone po całej sieci, ponieważ odnoszą się do robienia czegoś takiego.
Chciałem więc spróbować zebrać to wszystko razem z objaśnieniami, przykładowym kodem i linkami do stron, które mogą być interesujące w zależności od sposobu wdrożenia.
W końcu wielu z nas korzysta obecnie z WordPressa poza podstawowym zarządzaniem treścią, ale to nie znaczy, że nie powinniśmy w miarę możliwości wykorzystywać jego wbudowanych funkcji i interfejsów API.