Champs personnalisés dans WordPress : attention à la performance
- 2 - Article, page et catégories : organiser son contenu dans WordPress
- 2 - Champs personnalisés dans WordPress : attention à la performance
- 3 - La pire idée avec WordPress : “faire faire son SEO par Yoast”
- 4 - Réécrire les fonctions WordPress
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 ingredient, 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
Ou pour essayer ici, voici le lien direct vers tous les articles qui parlent de droits d’auteur et d’AFP est /sujets/droits-dauteur+afp tandis que le lien pour tous les articles qui parlent de droits d’auteur OU de l’AFP est /sujets/droits-dauteur,afp
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…
yop !!
Oui, c’est tout bon, mais là, y’a la moitié des blogueurs qui s’est pendue, et l’autre qui fait la queue à la pharmacie pour l’aspirine. Mais c’est logique…
Fondamentalement, c’est comme demander à chaque automobiliste de connaitre le moteur de son véhicule, tu vois le truc.
Alors, oui, sur le fond, tu as raison. Mais le succès de WordPress, c’est aussi cette possibilité donnée à tout le monde de pouvoir réinventer sa roue et d’avancer. C’est ça la démocratie ((:
J’avais pourtant essayé de faire simple :)
Dans ce cas précis, la solution WordPress est nettement plus simple et efficace que l’autre. Parce que paramétrer un query_post pour faire de la recherche sur des metas, c’est pas “biblique”
“Oui, c’est tout bon, mais là, y’a la moitié des blogueurs qui s’est pendue, et l’autre qui fait la queue à la pharmacie pour l’aspirine.”
Ou alors tu te plantes de cible. Je sais que les blogueurs c’est ton monde, mais il n’y a pas que ça, il y a des devs aussi.
“Fondamentalement, c’est comme demander à chaque automobiliste de connaitre le moteur de son véhicule, tu vois le truc.”
Encore, mauvaise cible, car c’est pas le “blogueur” qui va aller mettre les doigts dans le code ou la base de données.
“Fondamentalement, c’est comme demander à chaque mécano de connaitre le moteur de son véhicule, tu vois le truc.”
Ha oui, de suite ça colle beaucoup mieux là :)
Merci Marie-Aude pour l’article :)
@M.A : Na, c’est simple (:
Enfin, si tu es habitué à trifouiller.
Après, faut aussi que celui qui débute s’y mette, donc, c’est le type de billet qui peut (doit ?) être lu pour avancer et comprendre la mécanique.
Au passage, je vais allez voir ce plugin, je ne connaissais pas, et comme je suis en en phase over dose de code, très bien !
@ Greg : Oui, donc ? Y’a aussi des devs. Bien. Merci pour l’info ((:
Très bonne réflexion, tout le monde cherche la perf, mais personne ne veut faire l’effort de la trouver.
Il est clair qu’utiliser les meta pour trier/filtrer/rechercher c’est pas le top, les custom taxo remplissent bien ce travail et les APIs d’appels ne manquent pas, pour les queries il y a la tax_query qui est la (oui il y a meta_query mais comme expliqué dans le post … erf)
@ Stef : Ce n’est pas un article pour un blogueur final, on parle d’utiliser des champs perso pour faire des requêtes donc ça touche forcément les devs. La, un simple luser NE PEUT PAS faire ça, ça implique la création d’un plugin/astuce/thème (ou retouche) donc forcément PAS un blogueur (oui on peut aussi faire du WordPress PAS pour les blogueurs finaux) Comme dit Greg, tu te trompes de cible, mais comme a chaque post où on dit “touchez le code” tu interviens pour dire ça.
Merci lumière de nous l’avoir éclairée ;)
@Julio, si j’étais de mauvais de poil, je dirais que vous êtes sectaires les gars. Ça vous vient pas à l’esprit de penser qu’un blogueur peut aussi mettre les mains dedans.
Je suis blogueur, mais il m’arrive de faire du code, de me pencher dessus. Pourtant, je ne suis pas un dev’. Faut arrêter le sectarisme de la sorte.
Donc, je suis ne pas d’accord, ce type de billet peut s’adresser à tout le monde, du moins, tout ceux qui veulent mettre le nez dedans.
J’ai sans doute été maladroit sur mon premier com’, mais il est vrai que quand on rentre dans le code, bah on perd du monde. Mais c’est aussi comme cela que l’on apprend.
Vous avez bien débuter un jour, et parfois, vous êtes tombé sur des trucs qui vous sont apparus tordus, compliqués… Je ne vois pas où se trouve le problème dans mon intervention ?? oO
Bon, bah je ne dis rien de plus. Et pour finir julio, non, je n’interviens pas sur tout les articles de code… Ça va hein (:
Un blogueur qui met les mains dedans devient un dev, débutant, mais dev !
Tu fais donc aussi tu dev, cet article est fait pour toi :)
Donc si tu mets les mains dedans et que tu crées des meta pour ensuite filtrer/trier/rechercher, c’est mal ^^ Utiliser les taxo n’est juste pas plus compliqué, faut juste savoir que les meta c’est forcément moins bon à cause des index ;)
Ok, pas tous les posts, mais “la pensée WP” tu es la, “plugin or not plugin” tu as le même discours, chacun prêche pour sa paroisse surement.
Allez bisou ^^
Je trouve que c’est un très bon article pour montrer les yeux aux débutants et leur montrer la voie à suivre, même si elle est un peu obscure lors la première lecture :D J’aurais une question, s’il vous plaît: pourriez-vous me donner un exemple de “critère de recherche et de tri” qu’un utilisateur stockerait dans un champ personnalisé ? Merci d’avance pour la réponse … et pour ces informations détaillées.
Merci beaucoup Marie-Aude pour cet article.
Tu parles de critères de recherche. Mais considères tu que sur des boucles multiples la fonction new WP_Query meta_query sont aussi beaucoup moins performantes qu’avec tax_query?
OUlalala dès le matin la prise de tête, franchement c’est trop avancé pour moi, vous avez gagné la palme d’or de l’article le plus geekesque de l’année je crois :)
A mon avis celui qui utilise les champs personnalisés sait déjà comment ils fonctionnent non ? parceque pour le commun des mortels, on ne sait même pas a quoi ils servent :( .
@gregoire : C’est de ça qu’on parle. Que ce soi fait à la main (bouh !) avec $wpdb->query/->get_col/->get_row/->get_results ou avec une vrai meta_query, ça tape de toute façon dans cette table de meta qui ne contient pas d’indexes.
Moi la seule fois où j’ai utilisé les champs personnalisés, c’est pour insérer des thumbs à mes articles en sidebar. Mais maintenant, il existe plein de plugins qui le font :) du coup je lui trouve plus beaucoup d’utilité à ce champs…
@Julio
Merci Julio. Merci pour la précision. Par contre dans le cadre d’une requête du thème c’est mis en cache contrairement à une requête avec des champs (côté front, champ de recherche ou autre). Du coup, c’est moins grave.
J’espère car je suis un grand utilisateur d’ACF (comme tu sais :-) et ça tape que dans les metas
@grégoire : taper dans les métas c’est pas grave du tout, mais faire des filtres de recherches dans des metas selon une meta value, là c’est moins bien. Mais tu peux en lire 1000 par page, ça va, pas de soucis ;)
Tu les utilises comment toi ?
@Julio
Ouf, c’était d’ailleurs le sens de mon premier commentaire. Le distingo entre les requêtes de recherche et la construction de boucle multiples dans un template.
De mon côté, je m’en sers surtout comme des métas pour donner au client la possibilité de monter des page d’accueil modulable par exemple (avec ACF), comme ce qu’on a tous vu (pour ceux qui écoutaient :-) durant mon dernier lightning talk
@gregoire : Je m’en doutais bien, mais j’ai encore vérifié la emaine passée et tu peux faire 1000 get_post_meta() dans une page, ça reste la même perf, c’est en cache direct. Le soucis vient bien d’un get_posts (ou query_posts ou WP_Suery) qui fait une meta_query sur une meta_value, là c’est bad perf.
@Julio. Super. Je ferai gaffe en tout cas.
Moi qui pensait connaître WP et bien… j’ai sauté sur mon tube d’aspirine ^^ Je vais relire à tête reposée. Très bon article cela dit merci.
Ok et pour un custom field dans une custom taxonomie ? :D
Par exemple si j’ai une custom taxo Communes:
Region>Département>Commune et qu’en CF je mets le code postal par exemple sur Commune, c’est stocké sérialisé en base (me semble)…
C’est pas super de requêter dessus non ? (c’est une question, si vous avez mieux…)
On touche un peu les limites du modèle BDD de WP sur ce point je crois… (mais ceci dit coté intellectuel mis à part ça marche très bien)
Merci pour l’article. Perso j’aimerais en voir plus de post techniques en français de ce type et pas juste de copier-coller du Codex !
Bah c’est “simple” :D
“le truc à ne surtout pas faire“, c’est de dissocier le nom et le code postal, l’un en taxo, l’autre en custom field de l’article, parce que erreur de saisie, blabla
Option 1 : vous voulez pouvoir chercher / chercher sur les deux éléments (CP et nom), là la seule solution qui soit correcte pour la perf, c’est le code postal en nicename, éventuellement avec un préfixe, et la commune en valeur. Plus, dans l’admin, une meta-box faite maison pour un affichage des valeurs de taxonomies possibles avec un select
Option 2 : vous ne voulez chercher / sélectionner que sur l’un des deux éléments, vous le mettez en valeur, et vous passez l’autre en meta (custom field) puisqu’on peut effectivement utiliser le système des metas pour les taxonomies.
Cela dit, comme ce n’est pas du core wordpress, pour l’instant, mais une table à rajouter, vous pouvez la définir comme vous voulez, et rien ne nous empêche de définir tous les index nécesssaires.
C’est le principe d’un plugin comme taxonomy metadata
https://wordpress.org/plugins/taxonomy-metadata/
C’est aussi ce que font d’autres plugins, comme celui que j’utilise pour les séries d’articles, ou généralement les plugins qui permettent de lier des images à des termes.
Il faut simplement être prudent en nommant ses champs : car même si la table n’existe pas ( encore ) dans le core, elle a des chances d’arriver un jour ou l’autre, il vaut donc mieux que vos champs soient définis exactement selon la logique de WordPress (usermeta et postmeta)
En fait, il est très bien le modèle BDD ^^
(Et merci pour le commentaire ça encourage à continuer)
Très bonne réflexion, c’est vraiment bien de voir des articles qui vont dans le détails. Dans la logique globale je suis assez d’accord, par contre dans les faits on ne peut pas passer TOUT en taxo… il faut parfois utiliser des meta fields pour les recherches. J’ai fait il y a peu un plugin pour la gestion de biens immobiliers (je ne met pas le lien, mais ce qui connaissent mon travail le trouveront facilement). Et ce plugin possède exactement les contraintes évoquées dans cet article. Le moteur de recherche permet de filtrer par taxonomies: ville, CP, etat, statut, type de bien etc etc… mais comme chaque bien a plus de 40 meta fields, je suis bien obligé à un moment ou un autre d’inclure ces champs dans le système de recherche. Alors pour être précis, il faut là différencier: trier et filtrer, et le cumul des actions.
Bref tout ça pour dire que oui il faut privilégier les taxo dans les tris, mais aussi penser à utiliser à bon escient WP_Query qui depuis peu propose une API bien plus performante au niveau des requetes sur les meta fields: https://codex.wordpress.org/Class_Reference/WP_Query#Custom_Field_Parameters. De plus, l(utilisation de l’attribut, méconnu, “no_found_rows” => 1, permet d’alléger grandement les requetes ne nécessitant pas de pagination.
Je fais partie de la moitié des blogueurs en chemin vers la pharmacie… Je suis tombée sur cet article en suivant un lien dans mon Dashboard actualités WP, ce qui m’indique que c’est bon à lire et à comprendre Mais… c’est du chinois pour moi. Ce que je vais faire c’est imprimer cet article en pdf et essayer de le déchiffrer plus tard. Merci en tout cas
Alors pour info j’ai tenté un peut toutes les options…
Code postal en nicename ce n’est pas vraiment pertinent pour moi car en France une commune peut avoir plusieurs CP (et puis on peut perdre l’intérêt d’utiliser une URL sémantique à moins de la réécrire etc…) Ceci dit c’était une bonne piste pour les performances de filtre mais comme j’ai d’autres valeurs liées (le code insee etc.)…
Bref pour info j’ai créé un taxonomy hiérarchique : Region>Departement>Communes (uniquement les libellés). Ce qui représente à peu prés 37000 entrées.
Sans ajouter des custom fields (je l’ai fait ensuite mais c’est une autre histoire) je dois dire que je suis assez déçu des performances de WordPress vis-à-vis des temps de réponses pour afficher ne serait-ce que la liste en Back Office… (en local sur une grosse machine).
Bref, je conseillerais de faire une table dédiée et des requêtes SQL directe (et de l’AjAX) sans passer par des fonctions du Codex (sinon WP Query) pour traiter un tel volume de données (et 36000 je trouve que ce n’est pas énorme pour une BDD mais bon les taxonomies à la base étaient des catégories d’articles…)
Peut-être que quelqu’un a eu une meilleure expérience ?
Non, il n’y a pas théoriquement de “limite” au nombre d’élément dans une taxo, mais 36.000 (quelque soit la base) ça commence à être gros. Surtout à partir du moment où on est en hiérarchique.
WordPress.com fait tourner des millions de sites en multisite, je ne pense pas que 37000 soit une limite de WordPress mais plutôt du serveur et/ou de la BDD.
Faire des requêtes maisons ne ferait qu’empirer les choses car aucun cache ne serait géré, aucun hook ne passeait par là, bref les API sont meilleures.
Oui mais chaque site a ses propres tables de termes ^^
En reformulant :
“sur un serveur mutualisé normal ou un dédié de base, et sans un cache dans l’admin, le chargement de 37.000 valeurs de taxo hiérarchisées est un chouïa lourd” :) :)
Le problème – et je l’ai vu sur un site – c’est surtout dans tout ce qui est création de post, où normalement ta metabox te fait charger la totalité de la table en hiérarchique, et “en standard” ce n’est pas caché.
D’ailleurs je suis en train de bosser sur un site où j’ai remplacé la metabox standard par une maison qui charge par niveaux, et c’est nettement plus rapide (et lisible…)
Et on a ça où !? :p
“sans un cache dans l’admin, le chargement de 37.000 valeurs de taxo hiérarchisées est un chouïa lourd”
voilà… et c’est dommage (et j’ai fait tourner sur une “grosse” bécane dédiée pas un mutualisé…)
“Faire des requêtes maisons ne ferait qu’empirer les choses car aucun cache ne serait géré, aucun hook ne passait par là, bref les API sont meilleures.”
Est-ce que ça inclus WP_query, dans laquelle on peut faire du custom SQL ? :)
Les Apis sont les meilleures oui et non. Je suis d’accord sur la démarche qu’il faut utiliser au maximum les APi, pour pas dire tout le temps. Maintenant les API ramène *parfois* trop de choses ou pas assez donc c’est pas non plus super optimisé, surtout quand on a de très grand volume de données.
Je vais essayer pour le front du custom SQL avec WP_Query. (En Back c’est quand même acceptable et puis les communes ça ne changent pas tous les jours :))
Pour info j’ai testé des frameworks aussi du genre http://pods.io/ mais malheureusement ils sont souvent truffés de bugs (et puis on s’éloigne de l’esprit WP). Il vaut mieux coller à l’esprit WP avec les API en effet et jouer avec le cache/APC etc….
Mais j’espère qu’on aura quand même mieux avec les Taxo ou les liens entre post dans les prochaines versions (je parle du modèle de données).
@+ ! :)
Aleks, le problème n’est pas wp_query, et n’est pas wordpress, le problème est de construire une liste ordonnée indentée “récursive” avec 37.000 valeurs.
Quel que soit l’outil, ça sera lourd.
Regarde comment tous les systèmes travaillent : avec une recherche par paquets, par exemple tous les cp d’un département, puis tous les cp département + 1 chiffre, en chargeant à chaque fois des sous requêtes.
Ou alors, trouve moi sur le web un site qui affiche ça, sur une seule page, avec une seule requête ^^ (perso, je n’en connais pas)
Et oui, j’en ai fait l’amère expérience sur un site en particulier… Pour la prochaine fois, je repartirai sur de meilleures bases.
@4h18 : Je me permet de ce citer “La technique, c’est comme lire, écrire, ça s’apprend ! Pour maîtriser votre outil, vous allez devoir mettre le nez dans la technique.” ;)
Je suis pas très chaud a l’idée d’utilisé des taxonomies custom sur WP, je trouve qu’il y a asser déjà sur WordPress différente façon de classer les articles (par date, par catégorie, par tag, par auteur, …). Ça rajoute un autre niveau de structure qui ne remplace pas les custom field.
Je copmprend bien que les performance sont mieux et que c’est mieux géré a l’interne de WP par contre pour ce qui est d’optimisé la performance de WP j’opterais plutôt pour l’instalation du plugin WP Super Cache.
Dans un cas concrèt: j’ai ajouter une date de classement dans un champ personnalisé et j’ai eu quelque problème a en faire le tri. Pour l’ajout d’une date je n’ai pas trouver très utile de créé une taxonomie de date, j’ai plutôt personnalisé mes requêtes SQL pour mon classement perso.
Bonjour,
j’avoue que je ne comprends pas trop votre argumentaire ?
1. le “niveau de structure”… techniquement c’est quoi ? Il y a dans WordPress des terms, qui peuvent être des catégories, des tags, des media-tags (livrés par défaut), ou ce que vous voulez, ça ne change strictement rien à la définition des tables, aux fonctions, ou à quoi que ce soit du core de WordPress. Et comme il y a déjà deux termes standard (catégorie et tags) on ne peut même pas dire que ça rajoute une requête supplémentaire.
2. Les customs taxonomies ne sont pas faites pour remplacer les customs fields et vice-versa. En gros :
Donc votre besoin spécifique est effectivement à la marge entre 2 et 3. J’avoue que, quitte à hacker, j’aurais plutôt utilisé un des champs date de la table wp_posts, qui, eux, au moins ont le bon type, et sont indexables. Mais tout dépend du nombre de posts à trier.
SuperCache n’optimise pas la performance des recherches et de MySQl, il optimise la charge serveur en mettant en mémoire les recherches, c’est totalement différent.
Sinon, comme vous avez donné le lien vers votre méthode, je me permets de préciser, pour les autres, que la façon de personnaliser vos requêtes est une “horreur” d’un point de vue WordPress.
Au lieu de réécrire le SQL de base, vous devriez utiliser l’API , en incluant avec meta_query https://codex.wordpress.org/Class_Reference/WP_Query#Custom_Field_Parameters [l’exemple pour un order by avec un custom field est un peu plus haut dans la page) comme l’a indiqué Julio , c’est nettement plus solide sur le long terme.
@PHPascal : Ouch ouch et re ouch. Faire une custom requête via get_col() + plugin de cache en pensant gagner en perf contre une custom taxo est malheureusement le signe que WordPress n’est pas encore maitrisé. Je t’invite à faire des tests de performances entre le vrai fonctionnement de WordPress et ton hack qui saccage ce CMS.
Bons tests !
Et je plussoie Marie-Aude bien sûr.
Je viens de lire et ça ne fais que confirmer ce que je dis, WordPress n’est pas compris. Ton argument ici ne pèse pas lourd :/
Bonjour,
Bon j’avai noté cet article il y a un an
Je l’ai relu de manière plus approfondi car je souhaite faire des sites utilisant les taxonomies.
En ayant parcouru plusieurs sites, il y a pas mal de termes qui reviennent dès fois en anglais ou en français.
Si je comprends bien custom taxonomy est le terme générique qui regroupe la structuration des données de manière hiérarchique (catégorie) ou non (tags).
Les custom Post Type (équivalent des articles) devraient être dans des tables séparés pour favoriser l’indexage ?
J’utilises Pods (http://pods.io/features/) mais je ne retrouve ces tables justement.
Donc sans coder à la main, je voudrai avoir l’avis de ceux qui connaissent Pods !!
Autre question subsidiaire:
Est-ce que les plugins de type http://www.relevanssi.com/features/ n’améliorent t-ils pas de manière importante la recherche sur tous ces types de champs ?
Encore merci pour cet article de fond.
Bonjour
les custom post types sont dans la table wp_posts avec l’indication de leur post_type. Cela n’a rien à voir avec l’indexage. Au contraire, avoir une table par type de post alourdirait considérablement la structure, la performance, et poserait de gros problèmes de compatibilité. Pareil pour les customs taxonomies (qui sont bien des modes de classement des données), elles sont intégrées dans les trois tables standard de WordPress.
Je n’utilise pas Pods, qui avait amha du mérite au tout début, mais qui est une couche supplémentaire et inutile.
Des plugins comme relevanssi ne modifient pas la structure de la base de données, ne rajoutent pas des index aux tables, donc ils n’ont pas d’impact direct sur la performance de la recherche.
Re,
Effectivement j’ai bien retrouvé mes petits dans cette table ;-). Je pense avoir compris!
Pour les choix, nous n’avons pas le même profil. Je comprends que tu préfères coder pour mieux maîtriser.
Je pense qu’il y a des plugins comme Pods (qui m’a l’air le meilleur dans ce domaine) qui certes alourdisse la strcuture mais en facilite le développement.
Après si ce site doit avoir des milliers de termes et vus par des centaines de personnes par jour, il faut se poser la question de l’outil
Merci encore pour cette réponse rapide et complète
Disons que, de toute façons, Pods n’est pas mon préféré. Quitte à utiliser un plugin, je trouve que la suite GD est meilleure.
Bonne continuation, en tout cas !
Bonjour Marie-Aude,
Je me permets de revenir sur ta réponse du 1er avril 2013 (c’est pas une blague ^^) à PHPascal, au point 2 :
2. Les customs taxonomies ne sont pas faites pour remplacer les customs fields et vice-versa. En gros :
– valeurs se répétant pour de nombreux posts -> custom taxo
– valeurs uniques par post, et pas de recherche ou de tri -> custom fields
– valeurs uniques, et recherches ou tri, plutôt custom taxo, mais pas hiérarchiques, et tout dépend du nombre de “valeurs”, bref ça se discute
J’aide un ami à construire son site. Il y a plus de 100 articles à rentrer, avec à chaque fois des infos répétitives comme la situation géographique / l’année de construction / le type de logement, etc … J’ai donc mis des “custom fields”, en plus, c’est natif avec WP, il les affiche à la suite du contenu, c’est nickel.
MAIS (… il y a un mais) on voudrait aussi trier les articles par exemple selon la localisation ou selon l’année. J’ai donc pensé au Custom taxonomies.
Question : est-ce possible d’avoir les mêmes “dénominations” pour des Custom Fields et des Custom taxo ??
Et comment afficher ça en front-end, si les Custom Fields ne doivent pas être utilisés pour trier ?
Bonjour,
Déjà, un grand merci à toi Marie-Aude ! Je n’ai jamais eu l’occasion de te le dire car je commente très peu, mais voila des années que je lis tes articles (très pertinents!), ou que je te croise sur la toile avec des commentaires sur lesquels je suis très synchro avec toi ! Bref tu fais partie de mes gourous WordPress :)
Merci également pour cet article fort intéressant (ainsi que les commentaires qui ont suivi).
Je me permets de “réveiller” ce post, pour poser quelques questions sur le sujet, car je suis en train de devenir dingue. Et je pèse mes mots !! Je me permets donc de “résumer” mon petit projet ici, avec l’espoir d’être lu, et pourquoi pas d’être aidé ou conseillé. Je me permets également de faire un petit appel “caché” ici dans les commentaires de ce post, car j’ai conscience que M.A. et ses fans sont majoritairement des personnes calées en dev’ et plus particulièrement avec WordPress. Je suis prêt à essayer de débloquer une finance pour avoir un accompagnement et conseils de quelqu’un, ce qui me permettrait de développer mon projet sur de bonnes bases. Car j’en peux plus de fonctionner par tatillon, d’avancer, de faire marche arrière, de recommencer perpétuellement. Voila 8 ans que j’ai ce projet en tête sans jamais m’être véritablement lancé. C’est long ! J’ai démarré concrètement il y a 3 mois, et voila 4 fois que je recommence tout de zéro. J’avoue être trop perfectionniste, et cela me joue des tours. Notamment parce que j’ai l’intime conviction que certaines personnes commencent à prendre les devants et que mon propre projet va me passer sous le nez
Voici pour les plus courageux un résumé de mon fameux nouveau projet, que je trouve à mes yeux, de grande envergure. Ce projet est basé sur le WordPress pour le côté dynamique, mais surtout parce que que mes compétences en dév’ sont limités à ce CMS depuis quelques années, et dont je tombe de plus en plus amoureux !
J’ai une passion personnelle parmi un grand nombre de confrères : le sport. Un sport bien précis. Le hic c’est que voila bien 15 ans qu’en France, la communauté (de ce sport) se plaint d’un grand vide concernant ce sport sur la toile. Bref c’est la galère !
En effet, il est difficile de trouver : des événements auxquels participer (tournois/compétitions), des partenaires avec qui jouer, des entraîneurs qui proposent leurs services, et j’en passe. On peut retrouver ce type d’info, mais sur des blogs personnels par ici, une page ou un groupe Facebook par là, etc. L’idée de mon projet est donc de centraliser tout cela, de manière dynamique (avec des fiches, des profils/rôles différents, géolocalisation Google Maps, etc.), le tout en version web 2.0 si j’puis dire ! Je vois peut-être grand, mais le but est devenir LE site de référence francophone en la matière.
Le premier problème mais bon finalement ça me regarde, c’est que je suis à mon compte, que je m’en sors assez difficilement, et que ce projet va me prendre un temps fou. De plus, ce site a pour vocation de promouvoir ce sport dans l’hexagone, et sera donc complètement gratuit pour la communauté. Mais bon… je suis un passionné, autant de WordPress que de mon sport fétiche ! Et je me dis que peut-être, si le site plait, qu’il attire la communauté, comme je le souhaiterais, avec un bon travail de communication de ma part, peut-être que d’ici je sais pas.. 6, 12, 24 mois, je pourrais mettre en place certaines choses supplémentaires qui pourrait rentabiliser autant les frais serveur, que le temps de travail que j’aurais consacré. Mais évidemment en gardant toutes les idées de base gratuites et accessibles à tout le monde.
Heureusement pour moi, le côté positif de tous mes retours en arrière, et différents scénarios de dév’, est que je sais sur quelle base je souhaite partir. WordPress + plugins bien spécifiques dont surtout Calendarize It! un plugin événementiel qui m’a séduit. (Ce n’est pas très pro, mais à noter que c’est le 3ème que j’achète, modules compris, et que rien que cela m’a couté un bras – rire jaune – mais nécessaire afin de pouvoir valider LE plugin avec lequel travailler.)
J’arrête de tirer ce commentaire en longueur, et en vient au fait, et au sujet de cet article : voila une semaine que j’étudie le sujet des Custom Post Type. J’ai potassé le sujet, et appris certaines choses vitales dont le sujet ici (encore merci M.A.). Jusqu’à présent je ne connaissais que ACF, mais voila que je découvre des solutions telles que Types, Pods, ou encore la suite GD que Marie Aude plébiscite et que je ne connaissais pas il y a encore 15 minutes.
Le truc c’est que j’ai beau voir les tableaux comparatifs, les reviews ou tutoriels de chacun, au final.. je suis PERDU !
Pourquoi ? Car j’ai l’impression que la conclusion finale est : il n’y en a pas un mieux que d’autres, tout dépend du projet en question !
Mais je suis bord de l’overdose, je ne supporterais pas de tout recommencer une 5ème fois. Je pense pouvoir être autonome ensuite, mais j’ai besoin de savoir sur quelle base propre/optimisée travailler, par rapport aux Custom Post Types et les Taxonomies associées. C’est la raison pour laquelle je me permets de faire un appel à quelqu’un, le rêve étant d’avoir un retour de toi Marie-Aude (si tu as eu le courage de me lire jusqu’ici), afin de me dire si cela ne te dérangerait pas de me donner des conseils de base de travail, en fonction de certains critères liés à mon projet.
Evidemment je suis conscient que tu es une professionnelle, et que donc ton temps peut coûter. En quel cas je t’invite à me contacter si tu veux bien et de ne pas approuver ce commentaire en public. Sinon, si ce n’est pas le cas je suis vraiment preneur, si tu veux bien de laisser ce commentaire ici afin que peut-être des lecteurs spécialisés de ton blog me fassent un éventuel retour, si intéressés, soit par me proposer gentillement quelques conseils, soit pour me proposer une petite prestations “conseils pour démarrer ce projet sur de bonnes bases”.
Désolé d’avoir été aussi long et merci d’avance quoi qu’il arrive.
Ady
J’aide un ami à construire son site. Il y a plus de 100 articles à rentrer, avec à chaque fois des infos répétitives comme la situation géographique / l’année de construction / le type de logement, etc … J’ai donc mis des « custom fields », en plus, c’est natif avec WP, il les affiche à la suite du contenu, c’est nickel.
Bonjour Peter,
pour ce genre d’informations, il faut absolument se poser la question “custom field” ou “custom taxonomie” ? Quand elle est répétitive (type de logement, sans doute situation géographique), il faut absolument préférer une custom taxonomie.
J’ai l’impression que vous n’avez pas lu l’article, mais que vous vouliez juste lâcher un commentaire avec un lien vers un site vendant des produits pour les hommes qui ont des difficultés intimes ?