Anpassade arkivmallar: En kort guide
När du arbetar med arkivmallar i WordPress listas inlägg vanligtvis efter datum i fallande ordning. Det vill säga, de senaste inläggen listas överst, och sedan går det därifrån.
På sistone har jag arbetat med några projekt som integreras med tredjeparts API:er. Dessa API:er returnerar datum – ibland två datum, ett startdatum och ett slutdatum – för en given händelse och kunder vill använda den informationen för att lista inlägg snarare än datumet för inlägget. Det vill säga att de vill ha anpassade arkivmallar.
Det är inte så svårt att göra det här, men innan du gör det tycker jag att det är viktigt att ge lite bakgrundsinformation om hur projektet är byggt så att det finns lite mer sammanhang kring varför, till exempel, en anpassad fråga behövs och varför du kan eller kanske behöver inte titta på pre_get_posts.
Jag börjar dock med en TL;DR först. På så sätt kan du få idén innan du läser det hela.
Anpassade arkivmallar
Så TL;DR bakom det hela är detta:
- datuminformationen som tillhandahålls av tredje parts API sparas i post-metadatatabellen,
- nyckeln är startdatumet och värdet är det faktiska datumet,
- Jag beställer innehållet i fallande ordning och efter metavärdet.
Paginering kan vara lite av ett problem, och om du använder en anpassad inläggstyp behöver du några extra parametrar, men det finns den allmänna idén.
Nu till hela upplägget.
Anpassade inläggstyper
När det kommer till gränssnitt med tredje parts API:er är jag ett stort fan av anpassade inläggstyper eftersom jag tenderar att tänka på dem som en hybrid mellan modeller och vyer.
- Modellkomponenten inkluderar allt som är tangentiellt relaterat och kan skrivas till databasen. Detta innebär all taxonomiinformation eller postmetadata.
- View-komponenten är i allmänhet allt som går in i mallen som kan utnyttja alla redan existerande malltaggar är allt som kan behöva skapas som också läser information från databasen.
För det här inlägget kommer jag att använda acme-event som den anpassade posttypen.
Lägg upp metadata
Jag ställer in datumen i inläggets metadata snarare än i själva inlägget, för om något kommer att hända i framtiden och data ställs in på själva postposten, kommer WordPress att behandla det som ett schemalagt inlägg som är opublicerat .
Istället vill jag hellre ha inlägget publicerat och sedan ändra hur metadata visas i mallen.
Paginering
WordPress gör en subtil skillnad med paginering i sin kodbas. Det vill säga att frågevariabeln för webbplatser utan en statisk hemsida använder paged och det motsatta fallet använder page.
Det här spelar roll när du konstruerar argumenten för frågan som jag kommer till ett ögonblick.
Endast arkivsidor
Kom ihåg att när du introducerar sidnumrering vill du bara ändra frågan när du är på den faktiska arkivsidan.
Det betyder att du inte bryr dig om fall när du är i det administrativa området för WordPress och du inte vill ändra frågan för arkiv av icke-anpassad posttyp. För det ändamålet vill du se till att du ställer in frågevariabeln korrekt i pre_get_posts-återuppringningen.
Observera att jag kan visa en funktion för hur man gör detta, men på grund av hur vi skriver kod i WordPress – det vill säga vissa skriver procedurkod, andra skriver objektorienterad kod – så visar jag det helt enkelt i procedurkod.
Att föra ihop allt
Först ska jag bygga frågan:
<?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
]);Observera att i koden ovan finns ett argument för paged. Jag ska prata om koden för detta ett ögonblick.
Då kommer mallen att innehålla all information du väljer att visa. Jag väljer att inte dela koden för min mall i det här inlägget eftersom det är irrelevant för den större idén som finns.
Dessutom har du allt du behöver för att visa innehållet.
Därefter ska jag ställa in paginering. Först måste jag göra detta med pre_get_posts-kroken för att se till att rätt frågevariabel är inställd :
<?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);
}
}Sedan implementerar jag pagineringen med hjälp av den anpassade frågan:
<?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>Och efter det kommer jag att återställa den globala $post-variabeln med wp_reset_postdata() ifall någonting från det ursprungliga inlägget behöver användas.
<?php wp_reset_postdata(); ?>Detta anses generellt sett vara bra hushållning när du använder en anpassad fråga i alla fall.
Användbara länkar
Nedan finns en lista över funktioner, sidor och referenser som du kan ha nytta av när det gäller koden ovan eller eventuellt framtida arbete du kan göra.
- WP_Query
- Paginering
- 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
- Hela koden i detta inlägg.
Om du har arbetat med WordPress länge kan vissa av dessa verka överflödiga. I andra fall kan det verka nytt, eller så kan det kasta ljus över delar av WordPress API:er som du inte visste fanns (åtminstone var det fallet för mig).
Varför bry sig om allt detta?
Det här kan se ut som ett långt inlägg för en till synes enkel uppgift, men informationen är lite spridd över hela webben när det gäller att göra något sådant här.
Så jag ville försöka få ihop det hela med förklaringar, exempelkod och länkar till sidor som kan vara av intresse beroende på hur implementeringen går till.
När allt kommer omkring använder många av oss WordPress utöver grundläggande innehållshantering vid det här laget, men det betyder inte att vi inte bör utnyttja dess inbyggda funktioner och API:er när det är möjligt.