Advanced Custom Fields est un plugin fantastique utilisé par des millions de personnes qui transforme WordPress en un CMS full-stack, vous permettant de créer des groupes de champs personnalisés et des types illimités, et de les ajouter à n'importe quel type de contenu personnalisé.
Cependant, peu de personnes connaissent les limites de scalabilité d'Advanced Custom Fields.
Il nous est souvent demandé si GeoDirectory utilise Advanced Custom Fields pour gérer les champs personnalisés des annonces.
Lorsque nous répondons que GeoDirectory dispose de son propre système de champs personnalisés intégré, ils se demandent pourquoi nous avons décidé de « réinventer la roue ».
Si la réponse nous semble évidente, la scalabilité d'Advanced Custom Fields est assez limitée pour la création d'annuaires.
Nous avons pensé que peut-être, en tant qu'utilisateurs, ils n'ont pas conscience de ce qui se passe sous le capot ni des défis de scalabilité qu'un annuaire web peut poser.
Cependant, il n'y a pas si longtemps, nous sommes tombés sur un sondage dans un groupe WordPress populaire sur Facebook, où les options pour voter pour le « Meilleur Annuaire » étaient : GeoDirectory, quelques autres thèmes d'annuaire disponibles sur des marketplaces populaires, et il y avait également l'option ACF + FacetWP.
Quand nous avons vu les résultats, nous étions pour le moins perplexes : ACF + FacetWP avait recueilli bien plus de votes que nous ne l'aurions imaginé.
Les personnes ayant voté n'étaient pas censées être de simples utilisateurs, mais des développeurs web et des experts WordPress.
Pour cette raison, nous avons décidé qu'il était temps d'expliquer pourquoi ce n'est PAS une bonne idée d'utiliser Advanced Custom Fields pour un annuaire.
Et pourquoi les développeurs web ne devraient pas proposer cette solution à quiconque, à moins qu'ils ne se soucient pas de fournir des solutions rapides et scalables à leurs clients, capables de croître de manière durable.
Limites de scalabilité des champs personnalisés WordPress
WordPress utilise par défaut la table de base de données wp_postmeta pour stocker les données des champs personnalisés, et crée 1 ligne pour chaque champ personnalisé utilisé dans un article.
Par ailleurs, WordPress ajoute de nombreuses données supplémentaires dans cette table pour chaque article, chacune d'entre elles occupant 1 ligne de la table.
Si vous avez déjà passé du temps à optimiser des requêtes SQL, vous savez que ce n'est pas une situation idéale pour des fonctionnalités comme les annuaires et le filtrage.
En réalité, la structure de base de données par défaut représente potentiellement un énorme goulot d'étranglement pour les sites web comportant de nombreux articles et champs personnalisés.
C'est considéré comme l'un des points faibles de WordPress.
En effet, pour filtrer des articles par champs personnalisés, vous devez joindre la table wp_post à la table wp_postmeta dans votre requête.
Plus les tables grossissent, plus les requêtes deviennent lentes.
Pire encore, si vous souhaitez filtrer par deux valeurs méta, vous devrez joindre la table post_meta deux fois pour effectuer cela en une seule requête.
Cela peut consommer la mémoire système et ralentir considérablement tout ce qui dépasse un petit annuaire.
Limites de scalabilité d'Advanced Custom Fields
Le plugin Advanced Custom Fields est parfait pour tout site web avec un nombre faible ou modéré d'articles, de pages et de champs personnalisés en général.
Cependant, à quelques rares exceptions près, les annuaires sont exactement le contraire.
Ils comportent un très grand nombre d'articles avec potentiellement un très grand nombre de champs personnalisés également.
Le principal problème de scalabilité d'Advanced Custom Fields est qu'il crée 2 lignes dans la table wp_postmeta de votre base de données pour chaque champ personnalisé ajouté à une annonce.
Il ajoutera également plusieurs lignes postmeta appartenant à ses propres paramètres.
Cela signifie qu'il ajoutera plus du double des lignes dans la table wp_postmeta de votre base de données par rapport à l'utilisation du système de champs personnalisés WordPress par défaut.
Nous avons effectué un test rapide qui devrait nous aider à mieux expliquer ce point.
Nous avons créé un nouveau site WordPress, supprimé l'article « hello world » et la page exemple, puis installé Advanced Custom Fields.
Nous avons créé 1 groupe et 5 champs personnalisés, et publié 3 articles utilisant chacun les 5 champs personnalisés.
Après cela, notre table wp_postmeta comptait déjà 83 lignes.
C'est incroyable.
Imaginez le nombre de lignes pour un annuaire avec 300 000 annonces et cinq champs personnalisés.
Avec ACF, votre table wp_postmeta compterait un minimum de 3 000 000 de lignes
Comment GeoDirectory passe-t-il à l'échelle ?
C'est très simple : nous créons une table personnalisée pour chacun de nos types de publications personnalisés.
Exemple : wp_gd_gd_place_detail
Dans cette table, nous enregistrons tous les champs personnalisés et leurs données, dans une ligne par publication.
Nous avons également développé notre propre API PHP pour interroger nos tables personnalisées, tout comme WordPress dispose de sa propre API PHP pour interroger les tables par défaut de la base de données wp.
Cela signifie que GD, dans la plupart des cas, n'a qu'à faire une jointure entre la table des publications et notre table.
Nous pouvons ensuite filtrer ces résultats par N'IMPORTE QUEL champ personnalisé.
Nous pouvons filtrer par 20 champs personnalisés, tandis qu'ACF, même avec facetWP (qui accélère les choses mais conserve tout de même la limitation fondamentale), devrait effectuer des jointures sur plusieurs tables encore et encore pour accomplir le même travail en une seule requête, en utilisant plusieurs fois plus de mémoire serveur pour cette même requête.
Conclusions
Ainsi, si nous comparons GeoDirectory avec WordPress ou WP + Advanced Custom Fields, nous constatons que :
WordPress
1) Nécessite une JOIN de table supplémentaire pour chaque champ personnalisé par lequel vous souhaitez filtrer.
2) wp_postmeta grossit rapidement, ce qui ralentit les requêtes
WP + ACF
1) Nécessite une JOIN de table supplémentaire pour chaque champ personnalisé par lequel vous souhaitez filtrer.
2) wp_postmeta devient deux fois plus volumineux comparé à l'utilisation de WordPress seul
GeoDirectory
1) Aucune jointure n'est requise
2) GD n'ajoute rien à wp_postmeta, et n'y crée donc pas de données inutiles.
3) La base de données stockant les données des annonces compte 1 ligne par publication
WordPress est connu pour cette limitation dans la façon dont il stocke les données. Dans la plupart des cas, ce système fonctionne bien, mais lorsqu'il s'agit de grands annuaires, ce n'est tout simplement pas la bonne solution.
C'est pourquoi avec GeoDirectory, vous pouvez créer un annuaire avec des millions d'annonces, alors qu'avec WP + Advanced Custom Fields, vous avez de la chance si vous pouvez créer un annuaire avec quelques centaines d'annonces avant de commencer à constater de sérieux problèmes de performances.
Voici les limites de scalabilité d'Advanced Custom Fields qui nous ont poussés à ne pas l'utiliser pour GeoDirectory, et pourquoi vous ne devriez pas l'utiliser non plus.
Si vous avez des questions, n'hésitez pas à les poser dans les commentaires ci-dessous.