La mauvaise idée du siècle : utiliser les champs personnalisés pour y stocker des critères de recherche et de tri. Dès que votre site va un peu grandir, la performance va souffrir. Je vous recommande d’utiliser plutôt des customs taxonomies, hiérarchiques ou pas.

Si cela fait un petit peu plus de travail dans la construction du site, et notamment des templates, c’est bien plus sûr sur la durée.

Pourquoi ? A cause tout simplement des index…

Les champs personnalisés sont gérés dans la table wp_​postmeta

En voici la description :

wp_​postmeta : pas d’index sur les valeurs

Le nom du champs personnalisé est stocké dans meta_​key, le contenu dans meta_​value.

Les index, pour les non techniciens, sont des sortes de « table des matières » qui permettent, dans une grosse table, de trouver plus rapidement l’enregistrement qu’on cherche.

Or le contenu du champs personnalisé n’a pas d’index. (Et c’est un peu normal, car indexer un « longtext » n’est techniquement pas possible dans MySQL. Et on est bien obligé d’avoir un « longtext », puisque certains stockent des paragraphes entiers dans leurs champs personnalisés.

Toute recherche sur cette valeur va donc est gourmande en performances.

Par ailleurs, il n’y a aucun mécanisme dans WordPress pour vérifier que la valeur saisie est unique (même pas une suggestion, comme pour les mots clés). Sur la durée, les risques de fautes de frappe sont grands… et la recherche va devenir inefficace.

Champs personnalisés : les bonnes pratiques d’un point de vue « performance »

Dernier point (technique) : il est possible, ou pas, de « sérialiser » les champs personnalisés pour un post. Sérialiser, cela veut dire stocker tous les champs personnalisés dans un seul enregistrement de la base, sous forme de tableau.

L’avantage est de pouvoir faire une seule requête, stocker l’ensemble des valeurs des champs personnalisés dans un tableau, et appeler ce tableau au fur et à mesure des besoins, sans faire d’autres requêtes sur la base de données.

Si on considère qu’on a un besoin impérieux de séparer les valeurs des champs (après tout pourquoi pas…) alors il faut utiliser get_​post_​custom() au début du traitement du post, et stocker le tableau retourné dans une valeur.

Et éviter de faire comme WordPress SEO de Yoast, qui explose la taille de la table en créant des enregistrements des champs, même si ils sont vides (par exemple, il y a un champ pour stocker la valeur d’une redirection, qui est créé systématiquement… )

Les custom taxonomies sont gérées de façon plus complexes

Trois tables interviennent :

La table wp_​terms stocke les « valeurs » des termes et s’intéresse donc au contenu textuel. Le « term » a une ID unique, un contenu et un slug (nicename) qui est utilisé pour l’url.

La table wp_​term_​taxonomy stocke, pour chaque terme, le type de taxonomie auquel il appartient (catégorie, tag, ou taxonomie personnalisée). C’est dans cette table que se trouve la description (qu’on peut afficher dans le thème). Et pour chaque « couple » terme-​​taxonomie, il y a un identifiant unique.

C’est le mécanisme qui vous permet d’avoir, par exemple une catégorie qui s’appelle WordPress et un tag qui s’appelle WordPress.

Enfin la table wp_​term_​relationships stocke des enregistrement très simples, avec l’id du post et l’id du terme.

Les trois tables utilisées pour les taxonomies

Côté index, ça se passe comment ?

Beaucoup mieux… l’essentiel est dans wp_​terms, là où on stocke le « contenu » du terme :

Structure de la table wp_​terms : index sur le « nom »

Et là, dans les indexes, on a bien le « nom » et le « slug » c’est à dire ce qui aurait servi à faire une recherche si on avait utilisé un champs personnalisé.

Pour wp_​term_​taxonomy, c’est optimisé aussi :

Structure de wp_​term_​taxonomy

Le type de taxonomie est un index :  on ne cherchera pas dans toute la table des termes pour un tag ou un mot clé.

Quand à wp_​term_​relationships, c’est purement du numérique, du bonheur !

Structure de wp_​term_​relationships

D’un point de vue performance pure, il est donc bien meilleur d’utiliser les taxonomies que les champs personnalisés.

De plus ça évite de réinventer le fil à couper le beurre de refaire des templates et des fonctions qui existent déjà en standard dans WordPress.

Si vous avez lu le premier article de cette série « les 10 erreurs à ne pas commettre dans WordPress » vous savez déjà que rien ne m’énerve plus que les gens qui font « une page » pour regrouper des articles, au lieu d’utiliser des catégories ou des custom taxonomies.

Là c’est pareil

Les fonctions de recherche existent déjà pour les custom taxonomies

Eh oui… « recherche tous les articles qui ont telle valeur », c’est tout simplement afficher les archives de ce terme. « Archives » qui sont accessibles par une url toute simple.

Et rechercher « tous les articles qui ont telle ou telle valeur », c’est aussi afficher les archives de ce terme, avec une url un peu plus complexe, certes, mais toujours standard.

Imaginons que vous ayez une catégorie « ingrédients de la recette » dont le préfixe est ingrédient, et dans laquelle on trouve :

  • sel
  • safran
  • poulet

l’url de tous les articles contenant du safran sera example.com/ingredient/safran , l’url de tous les articles contenant du poulet sera example.com/ingredient/poulet et l’url de tous les articles parlant de poulet au safran (un petit délice que je vous recommande, quand même) sera example.com/ingredient/safran+poulet

Si vous voulez aller plus loin, vous pouvez utiliser Posttypes taxonomies intersections permet d’écrire des urls qui ont correspondent à une valeur donnée d’une taxonomie, limitée à un posttype.

Au lieu de peiner à réécrire des query_​posts complets, il suffit d’utiliser les fonctions standard de WordPress, et il n’y a même pas besoin de faire des templates spécifiques ! (Templates qui auraient de fortes chances d’être des …. pages 🙂 )

Et cerise sur le gâteau, vous avez une page de gestion de vos « critères » dans l’admin, qui vous permet de gérer vos valeurs, vérifier les fautes d’orthographe, etc…

Que pensez-vous de cet article ?
Super0
Bien0
Bof0
Nul0
Poster un commentaire