Aina kun työskentelet arkistopohjien kanssa WordPressissä, viestit on yleensä listattu päivämäärän mukaan laskevassa järjestyksessä. Toisin sanoen viimeisimmät viestit luetellaan yläreunassa, ja sitten se siirtyy sieltä.
Viime aikoina olen työskennellyt muutaman projektin parissa, jotka integroituvat kolmannen osapuolen sovellusliittymiin. Näiden sovellusliittymien palautuspäivät – joskus kaksi päivämäärää, aloituspäivä ja lopetuspäivä – tietylle tapahtumalle, ja asiakkaat haluavat käyttää näitä tietoja julkaisujen luetteloimiseen julkaisun päivämäärän sijaan. Eli he haluavat mukautettuja arkistomalleja.
Tämän tekeminen ei ole liian vaikeaa, mutta ennen kuin teet niin, mielestäni on tärkeää antaa taustatietoja siitä, miten projekti on rakennettu, jotta on hieman enemmän kontekstia sille, miksi esimerkiksi mukautettu kysely tarvitaan ja miksi saatat tai saatat. ei tarvitse tarkastella pre_get_posts -tiedostoja.
Aloitan kuitenkin ensin TL;DR:stä. Näin saat idean ennen kuin luet koko jutun.
Mukautetut arkistomallit
Joten TL;DR koko asian takana on tämä:
- kolmannen osapuolen API:n tarjoamat päivämäärätiedot säilytetään metatietotaulukossa,
- avain on aloituspäivä ja arvo on todellinen päivämäärä,
- Järjestän sisällön laskevassa järjestyksessä ja meta-arvon mukaan.
Sivutus voi olla ongelmallinen, ja jos käytät mukautettua viestityyppiä, tarvitset joitain lisäparametreja, mutta yleisidea on olemassa.
Nyt koko kokoonpanoon.
Mukautetut viestityypit
Mitä tulee liitäntään kolmansien osapuolien sovellusliittymiin, olen suuri mukautettujen viestityyppien fani, koska minulla on tapana ajatella niitä mallien ja näkymien hybridinä.
- Mallikomponentti sisältää kaiken, mikä liittyy tangentiaalisesti ja voidaan kirjoittaa tietokantaan. Tämä tarkoittaa kaikkia taksonomiatietoja tai post metatietoja.
- Näkymäkomponentti on yleensä mitä tahansa, joka menee malliin ja joka voi hyödyntää olemassa olevia mallitunnisteita, on mitä tahansa, joka on ehkä luotava ja joka myös lukee tietoja tietokannasta.
Tässä viestissä aion käyttää acme-event mukautettuna viestityyppinä.
Lähetä metatiedot
Asetan päivämäärät julkaisun metatietoihin pikemminkin kuin itse viestiin, koska jos jotain tapahtuu tulevaisuudessa ja tiedot asetetaan itse viestitietueeseen, WordPress käsittelee sitä ajoitettuna postauksena, jota ei julkaista. .
Sen sijaan julkaisen viestin mieluummin ja muutan sitten tapaa, jolla metatiedot näytetään mallissa.
Sivunumerointi
WordPress tekee hienovaraisen eron koodipohjassaan olevalla sivutuksella. Toisin sanoen kyselymuuttuja sivustoille, joilla ei ole staattista kotisivua, käyttää paged ja päinvastaisessa tapauksessa sivua.
Tällä on merkitystä, kun rakennat kyselyn argumentteja, joihin pääsen hetken kuluttua.
Vain arkistosivut
Muista, että aina kun otat käyttöön sivutuksen, haluat muuttaa kyselyä vain, kun olet varsinaisella arkistosivulla.
Tämä tarkoittaa, että et välitä tapauksista, joissa olet WordPressin hallinnollisella alueella etkä halua muuttaa ei-mukautetun post-tyyppisten arkistojen kyselyä. Tätä varten sinun kannattaa varmistaa, että asetat kyselymuuttujan oikein pre_get_posts-vastakutsussa.
Huomaa, että voin näyttää toiminnon, kuinka tämä tehdään, mutta koska kirjoitamme koodia WordPressissä – toisin sanoen jotkut kirjoittavat prosessikoodia, toiset taas oliokoodia – näytän sen yksinkertaisesti prosessikoodina.
Tuo kaikki yhteen
Ensin teen kyselyn:
<?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
]);Huomaa, että yllä olevassa koodissa on argumentti sivulle. Puhun tämän koodista hetken kuluttua.
Sitten malli sisältää kaikki tiedot, jotka haluat näyttää. Päätän olla jakamatta mallini koodia tässä viestissä, koska sillä ei ole merkitystä käsillä olevan suuremman idean kannalta.
Lisäksi sinulla on kaikki mitä tarvitset sisällön näyttämiseen.
Seuraavaksi asetan sivuttamisen. Ensin minun on tehtävä tämä käyttämällä pre_get_posts-koukkua varmistaakseni, että oikea kyselymuuttuja on asetettu :
<?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);
}
}Sitten toteutan sivutuksen mukautetulla kyselyllä:
<?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>Ja sen jälkeen nollaan globaalin $post-muuttujan komennolla wp_reset_postdata() siltä varalta, että jotain alkuperäisestä viestistä on käytettävä.
<?php wp_reset_postdata(); ?>Tätä pidetään yleensä hyvänä siivouksena aina, kun käytät mukautettua kyselyä.
hyödyllisiä linkkejä
Alla on luettelo toiminnoista, sivuista ja viittauksista, jotka saattavat olla hyödyllisiä, koska ne liittyvät yllä olevaan koodiin tai mihin tahansa tulevaan työhön, jota saatat tehdä.
- WP_Kysely
- Sivunumerointi
- 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
- Täysi koodi tässä viestissä.
Jos olet työskennellyt WordPressin kanssa pitkään, osa näistä saattaa tuntua tarpeettomilta. Muissa tapauksissa se voi vaikuttaa uudelta tai se saattaa valaista WordPress-sovellusliittymien alueita, joiden olemassaolosta et tiennyt (ainakin minun kohdallani).
Miksi vaivautua tämän kaiken kanssa?
Tämä saattaa tulla pitkä viesti näennäisen yksinkertaista tehtävää varten, mutta tiedot ovat hieman hajallaan verkossa, koska ne liittyvät tällaiseen tekemiseen.
Halusin siis yrittää yhdistää kaiken selityksien, esimerkkikoodien ja linkkien avulla sivuille, jotka saattavat olla kiinnostavia toteutustavan mukaan.
Loppujen lopuksi monet meistä käyttävät WordPressiä perussisällönhallinnan lisäksi tällä hetkellä, mutta se ei tarkoita, että meidän ei pitäisi hyödyntää sen sisäänrakennettuja toimintoja ja API-liittymiä mahdollisuuksien mukaan.