WordPress 2.3 : Schéma de la taxinomie !
Avant de commencer, je fais une petite précision sur le mot « taxinomie» .
La taxinomie désigne une méthode de classification des informations dans une architecture structurée de manière évolutive, autrement dit les catégories, les tags, etc. (Plus d’informations sur Wikipedia)
WordPress 2.3 introduit un nouveau schéma pour la taxinomie. Il remplace les tables « categories« , « post2cat» et « link2cat» par 3 nouvelles tables bien plus flexibles.
La première table est « terms« , elle ne comprend que les informations de base relatives à chaque terme.
term_id bigint(20) NOT NULL auto_increment, name varchar(55) NOT NULL default '', slug varchar(200) NOT NULL default '', term_group bigint(10) NOT NULL default 0, PRIMARY KEY (term_id), UNIQUE KEY slug (slug)
- « name» est le nom du terme
- « slug» est le nom optimisé pour l’URL
- « term_group» permet de grouper plusieurs termes ensemble
- « term_id» est un ID unique.
Un terme n’est ni une catégorie, ni un tag, cela dépend du contexte donné dans la table « term_taxonomy« .
term_taxonomy_id bigint(20) NOT NULL auto_increment, term_id bigint(20) NOT NULL default 0, taxonomy varchar(32) NOT NULL default '', description longtext NOT NULL, parent bigint(20) NOT NULL default 0, count bigint(20) NOT NULL default 0, PRIMARY KEY (term_taxonomy_id), UNIQUE KEY term_id_taxonomy (term_id,taxonomy)
La table « term_taxonomy» spécifie un terme dans une taxinomie. Il peut en faire une catégorie ou un tag (ou les 2).
- « term_id» est l’ID du terme dans la table de termes (expliqué ci-dessous)
- « taxonomy» désigne la taxinomie qu’on emploie. Les taxinomies par défaut sont « category» , « post_tag» , ou encore « link_category» .
- « term_taxonomy_id» est l’ID unique pour la paire terme/taxinomie.
Le reste des champs fournit des informations à propos du terme dans le contexte de taxinomie.
- « parent» permet une relation de hiérarchie entre plusieurs termes d’une taxinomie.
- « description» propose de spécifier une description pour un terme dans une taxinomie donnée.
- « count» permet de compter le nombre d’objets associé à une paire terme/taxinomie
Par exemple, pour la taxinomie « category» , le champ « count» permet de savoir le nombre d’articles que contient chaque catégorie.
La dernière table, « term_relationships« , met en relation les objets comme les liens ou les articles avec le champ « term_taxonomy_id» de la table « term_taxonomy« .
object_id bigint(20) NOT NULL default 0, term_taxonomy_id bigint(20) NOT NULL default 0, PRIMARY KEY (object_id,term_taxonomy_id), KEY term_taxonomy_id (term_taxonomy_id)
- « object_id» est l’ID d’un article ou d’un lien
- « term_taxonomy_id» est l’ID de la table « term_taxonomy» désignant une paire terme/taxinomie
La flexibilité de ce schéma et de l’API plugins permet d’ajouter de taxinomies et des objets très facilement. C’était l’un des points important du projet « Summer of Code« . Parallèlement, ce schéma nous autorise à récupérer facilement tous les objets associés à un terme donnés, sans préciser la taxinomie, récupérer tous les termes de toutes les taxinomies pour un objet donné, et aussi de convertir toutes les catégories en tags avec une requête.
Vous en apprendrez un peu plus sur le schéma de la taxinomie en consultant l’API des développeurs.
L’API des catégories assure une rétro compatibilité avec les versions précédentes. Les plugins effectuant des modifications directement sur les tables categories, link2cat ou post2cat seront buggés et non fonctionnels.
Voilà pour le schéma de taxinomie de la version 2.3. Il va causer quelques problèmes avec certains plugins dans un premier temps, mais à long terme il autorisera l’ajout de taxinomies sans modification du schéma de la base de données et c’est une excellente chose !
Source: Boren.nu
Loading ...
Merci pour ces petites explications qui ne me sont pas utiles en tant que telles pour le moment (je n’utilise que des tags sur mon blog
, mais qui me permettent de voir que WordPress évolue toujours dans le bon sens 
.
Doit on comprendre que la transition de la 2.2 vers la 2.3 risque d’être plus difficile qu’on pourrait le croire ?
Bah, ca sera toujours le même concept
(en théorie)
Merci de donner ce genre d’info sur les fonctionnalités à venir pour wp 2.3 : ça permet d’anticiper un peu sur les éventuels bugs qu’on va rencontrer
ils ont même pas implémenté les sous-tags…
genre on ne peut pas filtré les articles qui ont le tag tag1 et le tag tag2, à la façon del.icio.us, c’est à ça que ça sert à la base les tags sinon c’est complètement inutile.
De plus si vous nommé un tag « securité» (vous faite donc une faute d’accents), bonjour la galère pour le renommé en « sécurité» …
autant ils ont qu’a intégrer des plugins qui eux sont fonctionnels au lieu de faire des codes inutiles.
En voila de le remarque de néophytes
Alors oui l’intégration des tags vues par les utilisateurs peut paraitre light, mais c’est voulu…
WP.org laisse 3 mois à la communauté pour développer des plugins pour agrémenter les tags donc tout ce qu’on veut.
Quand la 2.4 viendra, on prendra les plugins les plus aboutis et plus utilisés et on les intègrera
D’un point de vue technique, le schéma est remarquable et n’a vraiment rien à envier aux anciens plugins…
Désolé pour le ton un peu rustre de mon dernier commentaire. Mais quand on vous dit, je site « a really kickass taxonomy system» , ben moi je m’attend à une meilleur intégration que ça…
Je n’arrive pas à voir non-plus en quoi le shéma de la bdd est si remarquable… pourquoi ne pas avoir grouper wp_terms et wp_term_taxonomy ? Je n’arrive pas à trouver des exemples qui pourrait favoriser cette solutions.
Etant donnés qu’il y aura relativement peu de lignes à écrire dans wp_terms, on aurait pu mettre les colonnes de wp_terms dans wp_term_taxonomies et rajouté un index non primaire sur slug ? à moins de se retrouver avec 10 nuages de tags…?
xorax > J’avais zapper ton commentaire
» ils ont même pas implémenté les sous-tags…
genre on ne peut pas filtré les articles qui ont le tag tag1 et le tag tag2, à la façon del.icio.us, c’est à ça que ça sert à la base les tags sinon c’est complètement inutile.»
Tout cela est gerer
» Etant donnés qu’il y aura relativement peu de lignes à écrire dans wp_terms, on aurait pu mettre les colonnes de wp_terms dans wp_term_taxonomies et rajouté un index non primaire sur slug ?»
Pour eviter de dupliquer les noms de termes selon leur utilisation (categories de liems, d’articles ou tags)
c’est la 1 foie que je connais ce taxinomie
merci mon ami
Your comment contains very useful information about all thank you farsça tercüman