WP_Query läsbarhetsförbättringar (för underhåll)

Att arbeta med WP_Query, särskilt när du gör lite anpassat arbete utanför det vanliga "skaffa några inlägg och visa dem på en mall" kan vara kraftfullt. Detta gäller särskilt för några av de avancerade argumenten (som att använda WP_Meta_Query, till exempel) .

Det är också lite trevligt att sätta upp processen har ett standardsätt att göra saker på. Nämligen:

1. Definiera argumenten,
2. Instantera WP_Query,
3. Kolla om det finns inlägg,
4. Gå igenom dem,
5. Avsluta dem.

Men om du kommer dit du gör något avancerat arbete som att arbeta med en anpassad inläggstyp från en tredjepartslösning, behöva sidladda media, avgöra om något finns innan du faktiskt arbetar med det, så kan det vara en lite mer komplicerat att arbeta med, eller hur?

Jag har upptäckt att, precis som med allt inom programmering, att dela upp det i mycket mer läsbara moduler (eller funktioner eller delar eller vad du nu skulle vilja kalla dem) kan göra det mycket lättare att arbeta med.

Så här är ett sätt att arbeta för att göra WP_Query läsbarhetsförbättringar i en mängd av de saker jag har gjort på sistone.

WP_Query Läsbarhetsförbättringar

Innan du går igenom något exempel är det värt att påpeka att det finns vissa saker som vi inte kan göra på sättet som WP_Query är konfigurerat.

Till exempel, när frågan väl har instansierats kanske vi inte kan göra mycket mer avancerade saker med den (jag menar, att ställa in enhetstestning som inte kräver WordPress-kärna kommer att bli omöjligt).

Det här är ansiktet på en som inte kan följa din kod.

Med det sagt, här är ett exempel på hur det kan se ut när du börjar och sedan hur det kan omstruktureras för att ha mindre funktioner som var och en är mer avsiktlig än en lång metod.

Ett exempel

För det här inlägget, låt oss säga att jag behöver fråga databasen för alla publicerade inlägg och inlägg och jag vill beställa dem efter ID.

Därefter vill jag avgöra om något tredjepartsverktyg har tilldelats vissa metadata till det som motsvarar en mall som jag senare kan tilldela programmatiskt givet ett tema som jag har.

Kanske den ursprungliga versionen av koden kan se ut ungefär så här :

Det är mycket kod för att göra en hel del arbete för en funktion. Åtminstone lägger den ut allt som behöver hända, eller hur?

Innan du läser vidare, notera att mappningsarrayen bara är ett exempel, men nycklarna representerar meta-nyckeln för mappning av den, och det hjälper oss att kartlägga definiera  värdet _wp_page_template när det är dags att mappa det till faktiska WordPress-mallfiler.

Så hur kan detta brytas ner?

1 Sparka igång det hela

Det första vi vill göra är att skapa en funktion som sätter igång det hela. Det finns några sätt som du kan välja att göra detta på.

Så här har jag valt att göra det :

Enkelt uttryckt kommer den att använda några hjälpfunktioner – alla som jag kommer att dokumentera nedan – och sedan tilldela vilka mallar vi har i mappningsmatrisen som definieras ovan.

2 Ladda inlägg och sidor

Naturligtvis är det första vi vill göra att ställa in en funktion att anropa som kommer att returnera med hjälp av resultaten av frågan:

Detta returnerar resultatet av frågan. På så sätt kan vi avgöra om vi behöver göra något ytterligare arbete som vi säger i huvuddraget i föregående steg:

Om inte, då är vi klara. Annars fortsätter vi så klart.

3 Hämta mall-ID från tredje part

Därefter verkar idén att tilldela mallar – som visas i koden ovan – enkel nog men det finns några saker vi måste göra först:

1. gå igenom inläggen,
2. ta tag i mallens tredje parts ID,
3. ta tag i tredje parts mallnamn,
4. tilldela mallen från mappningskonstanten som definierats tidigare i klassen.

Den initiala iterationen av funktionen kan se ut så här :

Men som du kan se finns det fortfarande hjälpfunktioner som behöver definitioner. Saker som möjligheten att få mall-ID, mallnamn och slutligen tilldela mallen.

Observera dock att om någon av hjälpfunktionerna inte returnerar ett användbart värde, så fortsätter vi med loopen. Detta är nödvändigt om inte av någon annan anledning än för att se till att vi inte försöker kartlägga mallar som inte finns (men jag tycker att det också gör det lite lättare att läsa).

4 Hitta filen som mall-ID mappar till

Därefter kan en liten funktion användas för att titta på tredje parts mall-ID och avgöra om vi kan mappa detta värde till sidorna som finns i vår databas.

Om det inte kan, då kan vi returnera en tom sträng och sedan ha funktionen som anropade just denna kontroll för att se om det är värt att fortsätta med den loop vi har definierat.

5 Ta tag i mallens namn

Om vi ​​antar att vi har ett giltigt inläggs-ID, måste vi nu hämta mallens namn från mappningsmatrisen som definierats tidigare i inlägget:

Här är grejen: Antingen kommer vi att returnera namnet på mallen, eller så kommer vi att returnera ett nollvärde. Återigen, detta är så att vi kan avgöra om vi behöver fortsätta med slingan att tilldela mallar eller inte.

6 Tilldela mallen

Slutligen kan vi ta tag i mallens ID som tillhandahålls av tredje part och använda det för att mappa till filen vi har inkluderat i vårt arbete som beskrivits tidigare i inlägget:

Och det är i slutändan så du kan skapa mycket mindre, lättare att läsa och enklare att använda kod och funktioner när du arbetar med lite mer komplicerade frågor.

Och därmed läsbarhetsförbättringar

För de som är vana vid att skriva långa läsmetoder eller göra saker på det sätt som mycket av tutorials på webben visar hur man gör saker i WordPress, kan det här se ut som mycket meningslös kod.

Men tänk på detta:

1. Längre metoder är svårare att läsa,
2. De kan vara svårare att felsöka,
3. Och de bryter inte ner problemet i mer hanterbara bitar.

Visst, jag skulle älska att dela upp det här i ännu fler klasser med deras ansvar, och jag tror att det kan göras, men med tanke på WP_Querys natur skulle det kräva lite mer arbete.

Så jag har försökt slå så mycket mellanväg som möjligt.

Om du arbetar med ännu lite mer avancerad användning av WP_Query, rekommenderar jag att du åtminstone överväger att dela upp det i mindre bitar.

Detta hjälper till att ta hand om läsbarheten, eventuellt underhållsmöjligheter, och att skriva renare kod snarare än en lång metod med för många villkor och beroende av en mängd andra data.