Advanced Custom Fields è un plugin fantastico utilizzato da milioni di persone che trasforma WordPress in un CMS a stack completo, permettendoti di creare gruppi e tipi di campi personalizzati illimitati e di aggiungerli a qualsiasi tipo di post personalizzato.
Tuttavia, in pochi conoscono i limiti di scalabilità di Advanced Custom Fields.
Spesso ci viene chiesto se GeoDirectory utilizzi Advanced Custom Fields per gestire i campi personalizzati delle inserzioni.
Quando rispondiamo che GeoDirectory dispone di un proprio sistema di campi personalizzati integrato, molti si chiedono perché abbiamo deciso di "reinventare la ruota".
Per noi la risposta è chiarissima: la scalabilità di Advanced Custom Fields è piuttosto limitata quando si tratta di creare directory.
Abbiamo pensato che forse, essendo utenti, non sono consapevoli di ciò che avviene dietro le quinte e delle sfide di scalabilità che una web directory può presentare.
Tuttavia, non molto tempo fa, ci siamo imbattuti in un sondaggio su un popolare gruppo WordPress su Facebook, dove le opzioni per votare la "Migliore Directory" erano: GeoDirectory, alcuni altri temi per directory disponibili sui marketplace più popolari e c'era anche l'opzione ACF + FacetWP.
Quando abbiamo visto i risultati, siamo rimasti perplessi, per usare un eufemismo: ACF + FacetWP aveva ricevuto molti più voti di quanti ne avremmo immaginati.
Le persone che avevano votato non erano semplici utenti, ma sviluppatori web ed esperti di WordPress.
Per questo motivo, abbiamo deciso che era giunto il momento di spiegare perché usare Advanced Custom Fields per una directory NON è una buona idea.
E perché gli sviluppatori web non dovrebbero offrire quella soluzione a nessuno, a meno che non si preoccupino di fornire ai propri clienti soluzioni veloci e scalabili, in grado di crescere in modo sostenibile.
Limiti di scalabilità dei campi personalizzati di WordPress
WordPress utilizza per impostazione predefinita la tabella del database wp_postmeta per memorizzare i dati dei campi personalizzati, creando 1 riga per ogni campo personalizzato utilizzato in un post.
Oltre a questo, WordPress aggiunge molti dati extra in questa tabella per ogni post, ognuno dei quali occuperà 1 riga della tabella.
Se hai trascorso del tempo a ottimizzare le query SQL, saprai che non è uno scenario ideale per cose come directory e filtri.
In effetti, la struttura predefinita del database è potenzialmente un enorme collo di bottiglia per i siti web con molti post e campi personalizzati.
È considerato uno dei punti deboli di WordPress.
Questo perché per filtrare i post in base ai campi personalizzati, dovrai unire la tabella wp_post con la tabella wp_postmeta nella tua query.
Più le tabelle cresceranno, più le query diventeranno lente.
Peggio ancora, se vuoi filtrare per due valori meta, dovresti unire la tabella post_meta due volte per farlo in una singola query.
Questo può consumare la memoria di sistema e rallentare tutto, tranne che per una directory di piccole dimensioni.
Limiti di scalabilità di Advanced Custom Fields
Il plugin Advanced Custom Fields è perfetto per qualsiasi sito web con un numero basso o moderato di post, pagine e campi personalizzati in generale.
Tuttavia, salvo rare eccezioni, le directory sono esattamente il contrario.
Hanno un numero molto elevato di post e potenzialmente anche un numero molto elevato di campi personalizzati.
Il principale problema di scalabilità di Advanced Custom Fields è che crea 2 righe nella tabella wp_postmeta del tuo database per ogni campo personalizzato aggiunto a un'inserzione.
Aggiungerà inoltre diverse righe postmeta relative alle proprie impostazioni.
Ciò significa che aggiungerà più del doppio delle righe nella tabella wp_postmeta del tuo database rispetto all'utilizzo del sistema di campi personalizzati predefinito di WordPress.
Abbiamo effettuato un rapido test che dovrebbe aiutarci a spiegare meglio questa questione.
Abbiamo creato un nuovo sito WordPress, eliminato il post "hello world" e la pagina di esempio, e installato Advanced Custom Fields.
Abbiamo creato 1 gruppo e 5 campi personalizzati, e pubblicato 3 post utilizzando ciascuno i 5 campi personalizzati.
Dopo questo, la nostra tabella wp_postmeta contava già 83 righe.
È assurdo.
Immagina il numero di righe per una directory con 300.000 inserzioni e cinque campi personalizzati.
Con ACF, la tua tabella wp_postmeta conterebbe un minimo di 3.000.000 di righe
Come scala GeoDirectory?
È molto semplice: creiamo una tabella personalizzata per ciascuno dei nostri tipi di post personalizzati.
Esempio: wp_gd_gd_place_detail
In questa tabella salviamo tutti i campi personalizzati e i loro dati, in una riga per ogni post.
Abbiamo anche sviluppato una nostra API PHP per interrogare le nostre tabelle personalizzate, proprio come WordPress dispone di una propria API PHP per interrogare le tabelle predefinite del database wp.
Ciò significa che GD, nella maggior parte dei casi, deve solo unire la tabella dei post alla nostra tabella.
Possiamo quindi filtrare quei risultati per QUALSIASI campo personalizzato.
Potremmo filtrare per 20 campi personalizzati, mentre ACF, anche con facetWP (che velocizza le cose ma ha comunque la limitazione di base), dovrebbe unire più tabelle più e più volte per svolgere lo stesso lavoro in un'unica query, utilizzando molte volte la memoria del server per la stessa query.
Conclusioni
Se confrontiamo GeoDirectory con WordPress o WP + Advanced Custom Fields, vediamo che:
WordPress
1) Richiede un JOIN aggiuntivo della tabella per ogni campo personalizzato per cui si vuole filtrare.
2) wp_postmeta diventa rapidamente molto grande, rallentando le query
WP + ACF
1) Richiede un JOIN aggiuntivo della tabella per ogni campo personalizzato per cui si vuole filtrare.
2) wp_postmeta diventa il doppio rispetto all'utilizzo di WordPress da solo
GeoDirectory
1) Non è richiesto alcun join
2) GD non aggiunge informazioni a wp_postmeta, quindi non crea inutile appesantimento.
3) Il database che archivia i dati delle inserzioni conta 1 riga per post
WordPress è noto per questa limitazione nel modo in cui memorizza i dati. Nella maggior parte dei casi questo sistema funziona bene, ma quando si tratta di directory di grandi dimensioni, non è semplicemente la soluzione giusta.
Ecco perché con GeoDirectory puoi creare una directory con milioni di inserzioni, mentre con WP + Advanced Custom Fields sei fortunato se riesci a costruire una directory con qualche centinaio di inserzioni prima di iniziare a riscontrare seri problemi di prestazioni.
Questi sono i limiti di scalabilità di Advanced Custom Fields che ci hanno spinto a decidere di non utilizzarlo per GeoDirectory, ed è per questo che non dovresti usarlo nemmeno tu.
Se hai domande, sentiti libero di farle nel commento qui sotto.