Kui töötate WordPressis arhiivimallidega, loetletakse postitused tavaliselt kuupäeva järgi kahanevas järjekorras. See tähendab, et kõige värskemad postitused on loetletud ülaosas ja sealt edasi läheb.
Viimasel ajal olen töötanud mõne projekti kallal, mis integreeritakse kolmandate osapoolte API-dega. Nende API-de tagastuskuupäevad (mõnikord kaks kuupäeva, alguskuupäev ja lõppkuupäev) antud sündmuse jaoks ja kliendid soovivad seda teavet kasutada postituste loetlemiseks, mitte postituse kuupäeva. See tähendab, et nad tahavad kohandatud arhiivimalle.
Seda pole liiga raske teha, kuid arvan, et enne seda on oluline anda taustateavet selle kohta, kuidas projekt on üles ehitatud, et oleks natuke rohkem konteksti selle kohta, miks näiteks on vaja kohandatud päringut ja miks seda võib teha või võib. ei pea uurima jaotist pre_get_posts.
Ma alustan siiski kõigepealt TL;DR-iga. Nii saate enne kogu asja lugemist aimu.
Kohandatud arhiivimallid
Nii et TL; DR kogu asja taga on järgmine:
- kolmanda osapoole API pakutavat kuupäevateavet hoitakse metaandmete tabelis,
- võti on alguskuupäev ja väärtus on tegelik kuupäev,
- Järjestan sisu kahanevas järjekorras ja metaväärtuse järgi.
Lehtede lehitsemine võib olla pisut probleemne ja kui kasutate kohandatud postituse tüüpi, on teil vaja lisaparameetreid, kuid üldine idee on olemas.
Nüüd kogu seadest.
Kohandatud postituste tüübid
Mis puutub liidestesse kolmandate osapoolte API-dega, siis olen suur kohandatud postitustüüpide fänn, sest kipun neid pidama mudelite ja vaadete hübriidiks.
- Mudeli komponent sisaldab kõike, mis on puutujaga seotud ja mida saab andmebaasi kirjutada. See tähendab mis tahes taksonoomia teavet või postituse metaandmeid.
- Vaatekomponent on üldiselt kõik, mis läheb malli, mis võib kasutada olemasolevaid mallisilte, on kõik, mis võib tekkida vajadus luua, mis loeb teavet ka andmebaasist.
Selle postituse jaoks kasutan kohandatud postituse tüübina acme-sündmust .
Postitage metaandmed
Ma määran kuupäevad pigem postituse metaandmetes kui postituses endas, sest kui midagi juhtub tulevikus ja andmed on määratud postituse kirjele endale, siis WordPress käsitleb seda ajastatud postitusena, mis on avaldamata .
Selle asemel tahaksin pigem postituse avaldada ja seejärel muuta seda, kuidas mallis metaandmeid kuvatakse.
Leheküljed
WordPress eristab oma koodibaasis peent lehekülge. Staatilise avaleheta saitide päringumuutuja kasutab paged ja vastupidisel juhul lehekülge.
See on oluline, kui koostate päringu argumente, milleni ma peagi jõuan.
Arhiivi ainult lehed
Pidage meeles, et iga kord, kui tutvustate lehekülgedele jagamist, soovite päringut muuta ainult siis, kui olete tegelikul arhiivi lehel.
See tähendab, et teid ei huvita juhtumid, kui olete WordPressi haldusalas ja te ei soovi mittekohandatud postitustüüpi arhiivide päringut muuta. Selleks peaksite veenduma, et seadistate päringumuutuja tagasihelistamisel pre_get_posts õigesti.
Pange tähele, et ma saan näidata funktsiooni, kuidas seda teha, kuid kuna me WordPressis koodi kirjutame – st mõned kirjutavad protseduurikoodi, teised objektorienteeritud koodi –, kuvan selle lihtsalt protseduurikoodis.
Selle kõige kokkuviimine
Esiteks koostan päringu:
<?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
]);Pange tähele, et ülalolevas koodis on argument paged jaoks. Ma räägin kohe selle koodist.
Seejärel sisaldab mall mis tahes teavet, mida soovite kuvada. Otsustan selles postituses oma malli koodi mitte jagada, kuna see pole käsiloleva suurema idee jaoks asjakohane.
Lisaks on teil kõik sisu kuvamiseks vajalik.
Järgmisena määran leheküljed. Esiteks pean ma seda tegema konksu pre_get_posts abil, et veenduda, et õige päringumuutuja on seatud :
<?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);
}
}Seejärel rakendan kohandatud päringu abil lehekülgede jagamise:
<?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 pärast seda lähtestan globaalse $post muutuja, kasutades wp_reset_postdata() igaks juhuks, kui on vaja kasutada mõnda asja algsest postitusest.
<?php wp_reset_postdata(); ?>Seda peetakse üldiselt heaks majapidamiseks alati, kui kasutate kohandatud päringut.
Kasulikud lingid
Allpool on loetelu funktsioonidest, lehtedest ja viidetest, mis võivad olla kasulikud, kuna need on seotud ülaltoodud koodi või mis tahes tulevase tööga, mida võite teha.
- WP_päring
- Leheküljed
- 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äielik kood selles postituses.
Kui olete WordPressiga pikka aega töötanud, võivad mõned neist tunduda üleliigsed. Muudel juhtudel võib see tunduda uus või see võib tuua valgust WordPressi API-de piirkondadele, mille olemasolust te ei teadnud (vähemalt minu puhul oli see nii).
Miks selle kõigega vaeva näha?
See võib näiliselt lihtsa ülesande jaoks välja tulla pika postitusena, kuid teave on veidi üle veebi laiali, kuna see on seotud millegi sellise tegemisega.
Seega tahtsin proovida seda kõike koondada selgituste, näidiskoodi ja linkidega lehtedele, mis võivad olenevalt juurutamise viisist huvi pakkuda.
Lõppude lõpuks kasutavad paljud meist praegu WordPressi põhilise sisuhalduse kõrval, kuid see ei tähenda, et me ei peaks võimalusel kasutama selle sisseehitatud funktsioone ja API-sid.