WP_Queryga töötamine, eriti kui teete kohandatud tööd väljaspool tavalist "hankige mõned postitused ja kuvage need mallil", võib olla võimas. See kehtib eriti mõnede täiustatud argumentide kohta (nt WP_Meta_Query kasutamine). .
Samuti on omamoodi tore, et protsessi seadistamisel on tavapärane toimimisviis. Nimelt:
- Määratlege argumendid,
- Käivitage WP_Query,
- Kontrollige, kas postitusi on,
- Pöörake neist läbi,
- Lõpeta need.
Kuid kui jõuate sinna, kus teete mis tahes täiustatud tööd, näiteks töötate kolmanda osapoole lahenduse kohandatud postituse tüübiga, peate meediumi külglaadima ja enne sellega töötamist kindlaks tegema, kas midagi on olemas, võib see olla natuke keerulisem töötada, kas pole?
Olen avastanud, et nagu iga programmeerimise puhul, võib selle jaotamine palju loetavamateks mooduliteks (või funktsioonideks või osadeks või kuidas iganes neid nimetada) muuta sellega töötamise palju lihtsamaks.
Siin on üks viis, kuidas ma töötan WP_Query loetavuse parandamiseks mitmesugustes hiljuti tehtud asjades.
WP_päringu loetavuse täiustused
Enne mis tahes näite läbimist tasub juhtida tähelepanu sellele, et WP_Query seadistamisel on mõningaid asju, mida me teha ei saa.
Näiteks kui päring on instantseeritud, ei pruugi me sellega enam palju täpsemaid asju teha (ma mõtlen, et mis tahes üksuse testimise seadistamine, mis ei vaja WordPressi tuuma, on võimatu).
See on inimese nägu, kes ei suuda teie koodi jälgida.
Seda arvestades on siin näide sellest, kuidas see võib alguses välja näha ja kuidas seda saab ümber kujundada väiksemateks funktsioonideks, millest igaüks on tahtlikum kui üks pikk meetod.
Näide
Oletame, et selle postituse jaoks pean andmebaasist päringu tegema kõigi avaldatud postituste ja postituste kohta ning soovin neid ID järgi järjestada.
Järgmisena tahan kindlaks teha, kas mõnele kolmanda osapoole tööriistale on määratud metaandmed, mis vastavad mallile, mille saan hiljem programmiliselt määrata, arvestades mul olevat teemat.
Võib-olla võib koodi esialgne versioon välja näha umbes selline :
See on palju koodi, et ühe funktsiooni jaoks palju tööd teha. Vähemalt on selles kirjas kõik, mis juhtuma peab, kas pole?
Enne edasise lugemist pange tähele, et vastendusmassiivi on vaid näide, kuid võtmed esindavad selle kaardistamise metavõtit ja see aitab meil kaardistada _wp_page_template väärtuse, kui on aeg vastendada see tegelikele WordPressi mallifailidele.
Niisiis, kuidas seda lahti teha?
1 Alustage kogu asjaga
Esimene asi, mida tahame teha, on luua funktsioon, mis paneb kogu asja liikuma. Saate seda teha mõnel viisil.
Olen selle valinud järgmiselt.
Lihtsamalt öeldes kasutab see mõnda abifunktsiooni – need kõik dokumenteerin allpool – ja määrab seejärel kõik mallid, mis meil ülalpool määratletud vastendusmassiivis on.
2 Laadige postitused ja lehed
Loomulikult on esimene asi, mida me teha tahame, seadistada helistamiseks funktsioon, mis tagastab päringu tulemusi:
See tagastab päringu tulemused. Nii saame kindlaks teha, kas peame tegema täiendavaid töid, mida me eelmises etapis põhisises ütleme:
Kui ei, siis oleme valmis. Muidu me loomulikult jätkame.
3 Hankige kolmanda osapoole malli ID
Järgmiseks näib mallide määramise idee – nagu on näidatud ülaltoodud koodis – piisavalt lihtne, kuid esmalt peame tegema mõned asjad:
- korrake postitusi,
- haarake malli kolmanda osapoole ID,
- haarake kolmanda osapoole malli nimi,
- määrata mall klassis varem määratletud vastenduskonstandist.
Funktsiooni esialgne iteratsioon võib välja näha järgmine :
Kuid nagu näete, on endiselt abifunktsioone, mis vajavad määratlusi. Näiteks võimalus hankida malli ID, malli nimi ja lõpuks mall määrata.
Pange tähele, et kui mõni abifunktsioonidest kasulikku väärtust ei tagasta, jätkame tsükliga. See on vajalik mitte muul põhjusel, kui selleks, et me ei püüaks kaardistada malle, mida pole olemas (kuid leian, et see muudab lugemise ka pisut lihtsamaks).
4 Otsige üles fail, millele malli ID kaardistab
Järgmisena saab väikese funktsiooni abil vaadata kolmanda osapoole malli ID-d ja teha kindlaks, kas saame selle väärtuse vastendada meie andmebaasis olevate lehtedega .
Kui see ei õnnestu, saame tagastada tühja stringi ja seejärel lasta funktsioonil, mis selle konkreetse välja kutsus, kontrollida, kas tasub defineeritud tsükliga jätkata.
5 Haara malli nimi
Eeldades, et meil on kehtiv postituse ID, peame nüüd laadima malli nime postituses varem määratletud vastendusmassiivist:
Siin on asi: me kas tagastame malli nime või tagastame nullväärtuse. Jällegi on see selleks, et saaksime kindlaks teha, kas peame jätkama mallide määramise tsükliga või mitte.
6 Määrake mall
Lõpuks saame haarata kolmanda osapoole pakutava malli ID ja kasutada seda failiga, mille oleme oma töösse lisanud, nagu postituses varem kirjeldatud:
Ja nii saate luua palju väiksemat, hõlpsamini loetavat ja hõlpsamini kasutatavat koodi ja funktsioone, kui töötate veidi keerulisemate päringutega.
Ja seega loetavuse täiustused
Neile, kes on harjunud kirjutama pikki meetodeid või tegema asju nii, nagu paljud veebis olevad õpetused näitavad, kuidas WordPressis asju teha, võib see tunduda palju mõttetu koodina.
Kuid mõelge sellele:
- Pikemaid meetodeid on raskem lugeda,
- Neid võib olla raskem siluda,
- Ja nad ei jaga probleemi paremini hallatavateks tükkideks.
Muidugi, mulle meeldiks jagada see veelgi rohkemateks klassideks koos nende kohustustega ja ma usun, et seda saab teha, kuid WP_Query olemust arvestades nõuaks see veidi rohkem tööd.
Seega olen püüdnud leida võimalikult palju keskteed.
Kui töötate WP_Query isegi veidi arenenumate kasutusviisidega, siis soovitan vähemalt kaaluda selle jagamist väiksemateks tükkideks.
See aitab hoolitseda loetavuse ja võimaliku hooldatavuse eest ning kirjutada puhtamat koodi, mitte ühte pikka meetodit, mis sisaldab liiga palju tingimustingimusi ja tugineb paljudele muudele andmetele.