Non inquinare la tabella delle opzioni di WordPress

Sono un fan dei cicli di rilascio brevi. A seconda del progetto, la durata del ciclo varierà, ma per molti dei tipi di progetti su cui lavoro, miro ad avere cicli di rilascio di due settimane.

Inoltre, ci sono momenti in cui sto lavorando a un progetto per qualcuno in cui sono necessarie variabili ambientali in modo che il codice sappia se è in esecuzione in fase di sviluppo, staging o produzione.

E questo può essere ottenuto in modo diverso a seconda delle esigenze del progetto. A volte, un file di configurazione funzionerà, a volte le variabili della stringa di query possono funzionare e altre volte penso che sia ragionevole memorizzare un’impostazione nel database.

Ma, per quanto riguarda WordPress, penso che scorriamo decisioni di progettazione migliori e gettiamo informazioni nel database, in particolare la tabella delle opzioni, quando le alternative potrebbero essere più adatte.

La tabella delle opzioni di WordPress

Voglio essere chiaro: non credo che la tabella delle opzioni dovrebbe fungere da discarica per le impostazioni quando non si ha nessun altro posto dove inserire informazioni. E questo è il succo di questo intero post.

Puoi invece utilizzare:

• un file di configurazione,
• dati della sessione (se del caso),
• una tabella di database personalizzata,
• o qualcos’altro.

Allora perché vediamo che questo accade così frequentemente? Non è che non ci siano momenti in cui ha senso usarlo. Penso solo che ne abusiamo. Ma ci sono ragioni per cui.

Il codice di WordPress definisce opzioni come questa:

Le opzioni sono dati che WordPress utilizza per memorizzare varie preferenze e impostazioni di configurazione.

Con una definizione come questa, è facile capire perché così tanti lo useranno come un posto dove riporre tutto ciò che non sta bene da nessun’altra parte.

Invece, penso che sia importante porsi la domanda:

Per quale tipo di archiviazione [questi dati] sono più rilevanti?

Cioè, se è correlato ai post, perché non memorizzarlo nella meta tabella dei post? Lo stesso per i metadati dei termini, i commenti o qualsiasi altra cosa.

Il punto è questo:

Trova il posto più logico in cui archiviare i dati e inserirli lì.

In altre parole, non gettare dati nella tabella delle opzioni di WordPress perché non si adattano da nessun’altra parte. Quello lo inquina. Invece, trova – o crea – il posto più logico per esso. Questa è probabilmente la prova di un odore di codice e sarebbe una buona ragione per rivalutare l’architettura del codice e il modo in cui le informazioni vengono rappresentate.

Ma come potrebbe essere? Cioè, come potremmo prendere un dato pezzo di codice e cambiare il modo in cui è rappresentato nel database.

Sfortunatamente, è difficile fornire una soluzione prescrittiva a questa domanda ogni volta che esistono così tante varianti nell’implementazione di un problema. Quindi forse una semplice linea guida è in ordine:

Se i dati sono correlati a tipi di dati (o tabelle) preesistenti, utilizzarli; in caso contrario, considera un file di configurazione o una tabella di database personalizzata che si associa al tuo lavoro.

Sono sicuro che ci sono altri fattori guida, ma questo è un punto di partenza migliore rispetto al semplice inquinamento della tabella delle opzioni di WordPress.