Miglioramenti alla leggibilità di WP_Query (per manutenzione)

Lavorare con WP_Query, specialmente quando stai facendo un lavoro personalizzato al di fuori del solito "prendi alcuni post e mostrali su un modello" può essere potente. Ciò è particolarmente vero per alcuni degli argomenti avanzati (come l’utilizzo di WP_Meta_Query, per esempio) .

È anche bello che impostare il processo abbia un modo standard di fare le cose. Vale a dire:

1. Definisci gli argomenti,
2. Istanzia WP_Query,
3. Controlla se ci sono post,
4. Passa attraverso di loro,
5. Finiscili.

Ma se arrivi al punto in cui stai eseguendo un lavoro avanzato come lavorare con un tipo di post personalizzato da una soluzione di terze parti, dover caricare i file multimediali, determinare se esiste qualcosa prima di eseguire effettivamente qualsiasi lavoro con esso, allora può essere un un po’ più complicato da lavorare, no?

Ho scoperto che, come con qualsiasi cosa nella programmazione, scomporlo in moduli molto più leggibili (o funzioni o pezzi o come preferisci chiamarli) può rendere molto più facile lavorare con.

Quindi, ecco un modo in cui vado a lavorare per apportare miglioramenti alla leggibilità di WP_Query in una varietà di cose che ho fatto di recente.

Miglioramenti alla leggibilità di WP_Query

Prima di passare attraverso qualsiasi esempio, vale la pena sottolineare che ci sono alcune cose che il modo in cui WP_Query è impostato che non possiamo fare.

Ad esempio, una volta che la query è stata istanziata, potremmo non essere in grado di fare cose molto più avanzate con essa (voglio dire, impostare qualsiasi unit test che non richieda il core di WordPress sarà impossibile).

Questo è il volto di uno che non può seguire il tuo codice.

Detto questo, ecco un esempio di come può apparire quando inizi e quindi come può essere rifattorizzato per avere funzioni più piccole, ognuna delle quali è più intenzionale di un metodo lungo.

Un esempio

Per questo post, diciamo che devo interrogare il database per tutti i post e i post pubblicati e voglio ordinarli in base all’ID.

Successivamente, voglio determinare se alcuni strumenti di terze parti hanno assegnato alcuni metadati che corrispondono a un modello che posso assegnare in seguito a livello di codice dato un tema che ho.

Forse la versione iniziale del codice potrebbe assomigliare a questa :

È un sacco di codice per fare un bel po’ di lavoro per una funzione. Per lo meno, espone tutto ciò che deve accadere, non è vero?

Prima di continuare a leggere, nota che l’array di mappatura è solo un esempio, ma le chiavi rappresentano la meta chiave per  mapparlo e questo ci aiuta a mappare definendo il valore _wp_page_template quando arriva il momento di mapparlo su file template WordPress effettivi.

Quindi come può essere scomposto?

1 Calcia il tutto

La prima cosa che vogliamo fare è creare una funzione che metta in moto l’intera cosa. Ci sono alcuni modi in cui puoi scegliere di farlo.

Ecco come ho scelto di farlo :

In poche parole, utilizzerà alcune funzioni di supporto – tutte che documenterò di seguito – e quindi assegnerà qualsiasi modello che abbiamo nell’array di mappatura definito sopra.

2 Carica post e pagine

Naturalmente, la prima cosa che vogliamo fare è impostare una funzione da chiamare che restituirà use i risultati della query:

Ciò restituisce i risultati della query. In questo modo, possiamo determinare se abbiamo bisogno di fare del lavoro aggiuntivo che diciamo nel succo del passaggio precedente:

Se no, allora abbiamo finito. Altrimenti, ovviamente, andiamo avanti.

3 Recuperare l’ID modello di terze parti

Successivamente, l’idea di assegnare i modelli, come mostrato nel codice sopra, sembra abbastanza semplice, ma ci sono alcune cose che dobbiamo fare prima:

1. scorrere i post,
2. prendi l’ID di terze parti del modello,
3. prendi il nome del modello di terze parti,
4. assegnare il modello dalla costante di mappatura definita in precedenza nella classe.

L’iterazione iniziale della funzione potrebbe essere simile a questa :

Ma come puoi vedere, ci sono ancora funzioni di supporto che necessitano di definizioni. Cose come la possibilità di ottenere l’ID del modello, il nome del modello e, infine, assegnare il modello.

Si noti, tuttavia, che se una qualsiasi delle funzioni di supporto non restituisce un valore utile, si continua con il ciclo. Questo è necessario se non altro per assicurarci che non stiamo cercando di mappare modelli che non esistono (ma trovo che renda anche un po’ più facile la lettura).

4 Trovare il file su cui mappare l’ID modello

Successivamente, una piccola funzione può essere utilizzata per esaminare l’ID del modello di terze parti e determinare se possiamo mappare questo valore alle pagine che esistono nel nostro database.

In caso contrario, possiamo restituire una stringa vuota e quindi avere la funzione che ha invocato questo particolare controllo per vedere se vale la pena continuare con il ciclo che abbiamo definito.

5 Prendi il nome del modello

Supponendo di avere un ID post valido, ora dobbiamo recuperare il nome del modello dall’array di mappatura definito in precedenza nel post:

Ecco il problema: restituiremo il nome del modello o restituiremo un valore nullo. Ancora una volta, questo è così che possiamo determinare se è necessario continuare con il ciclo di assegnazione dei modelli o meno.

6 Assegna il modello

Infine, possiamo prendere l’ID del modello fornito dalla terza parte e usarlo per mappare il file che abbiamo incluso con il nostro lavoro come descritto in precedenza nel post:

E questo è in definitiva il modo in cui puoi creare codice e funzioni molto più piccoli, più facili da leggere e più facili da usare quando lavori con query leggermente più complicate.

E quindi, miglioramenti della leggibilità

Per coloro che sono abituati a scrivere leggendo metodi lunghi o facendo cose nel modo in cui gran parte dei tutorial sul Web mostrano come fare cose in WordPress, questo può sembrare un sacco di codice inutile.

Ma considera questo:

1. I metodi più lunghi sono più difficili da leggere,
2. Possono essere più difficili da eseguire il debug,
3. E non scompongono il problema in pezzi più gestibili.

Certo, mi piacerebbe suddividerlo in ancora più classi con le loro responsabilità, e credo che si possa fare, ma data la natura di WP_Query, richiederebbe un po’ più di lavoro.

Quindi ho cercato di trovare più vie di mezzo possibile.

Se stai lavorando con usi anche leggermente più avanzati di WP_Query, ti consiglio almeno di considerare di scomporlo in parti più piccole.

Questo aiuta a curare la leggibilità, potenzialmente qualsiasi manutenibilità, e a scrivere codice più pulito piuttosto che un metodo lungo con troppe condizionali e fare affidamento su una varietà di altri dati.