Dans la première partie de cette série, j'ai montré comment installer WordPress localement et comment importer une base de données WordPress dans Vertabelo. Dans cet article, nous allons examiner de plus près les tableaux de la base de données WordPress.
Un aperçu rapide du modèle de base de données WordPress et du tableau de bord
Dans la partie précédente, j'ai importé la base de données WordPress dans notre outil de modélisation de base de données en ligne. Pour mémoire, la structure de la base de données est la suivante :
Il y a quelques faits importants sur le modèle de base de données WordPress que vous devez comprendre avant de commencer :
- Chaque site WordPress utilise exactement la même structure de base de données. Il contient 11 tableaux et chaque site WordPress les utilise en arrière-plan. La plupart des plugins WordPress utilisent également la base de données sans aucune modification du modèle de base de données. Le modèle doit être suffisamment flexible pour s'adapter à tous les différents plugins. Bien entendu, les créateurs de plugins peuvent ajouter des tableaux personnalisés pour des plugins spécifiques si la structure des données est très différente ou si leur plugin stocke de grandes quantités de données.
- La base de données WordPress manque de contraintes de clé étrangère . Cela est dû au fait que WordPress utilise le moteur de stockage MyISAM, qui ne prend pas en charge les clés étrangères. Les tables contournent ce problème en ayant des attributs qui stockent des valeurs de type "clé étrangère" non connectées, de sorte que la contrainte de clé étrangère ne sera pas vérifiée par la base de données. Par exemple, le
post_authorattribut dans lewp_poststable est une "référence" à l'attribut "ID" dans lewp_userstableau. - La plupart des tables utilisent une clé primaire à une seule colonne. Ils sont nommés soit simplement "ID" (dans le
wp_userset lewp_poststable), oumeta_id/umeta_id(dans les méta tables :wp_postmeta,wp_commentmetaetwp_usermeta), ou une combinaison du nom de la table et du suffixe "_id" (toutes les autres tables). La seule exception à ces règles est lewp_term_relationshipstable, où la clé primaire est constituée des deux attributs :object_idetterm_taxonomy_id. Les attributs qui sont une clé primaire ou qui font partie d'une clé primaire sont du type bigint(20). Les clés primaires à attribut unique ont également la propriété d'incrémentation automatique définie sur "Oui".
Messages et pages
La principale raison d'utiliser WordPress est de créer et de manipuler du contenu et de le présenter au public. À cette fin, WordPress nous propose deux types de contenu :Pages et Messages .
Pages sont utilisés pour afficher le contenu statique . Ils n'utilisent pas de balises ou de catégories et ne sont pas répertoriés par date. De plus, ils n'autorisent pas les commentaires ou le partage sur les réseaux sociaux. Les pages peuvent avoir des sous-pages. À propos de nous les pages sont de bons exemples de ce type.
D'autre part, les messages sont classés par date et peuvent être organisés à l'aide de catégories et balises . Les messages peuvent être utilisés dans les flux RSS, grâce à leur ordre chronologique. Les messages ne peuvent pas avoir de « sous-messages », mais les commentaires et les partages sur les réseaux sociaux sont possibles. Les articles sont essentiellement des articles de blog. C'est compréhensible, puisque WordPress a évolué à partir d'une plateforme de blogs.
La table principale derrière le contenu de n'importe quelle page WordPress s'appelle wp_posts :
WordPress utilise le wp_posts table pour stocker les pages, les publications et les pièces jointes. Nous pouvons considérer ce tableau comme le cœur de notre page, l'endroit où la plupart du contenu est stocké. Il est important de souligner que les pièces jointes sont en fait stockées sur le disque et l'enregistrement dans le wp_posts table conserve plus d'informations à son sujet (qui l'a téléchargé et quand, etc.).
Les champs dans le wp_posts le tableau sont :
post_author– une référence auwp_userstableau indiquant l'auteur du message.post_date– la date et l'heure auxquelles l'enregistrement a été inséré dans la table.post_date_gmt– la date et l'heure GMT/UTC auxquelles un enregistrement a été inséré dans la table.post_content– le contenu réel de la publication.post_title– le titre du message.post_excerpt– un résumé du contenu.post_status– le statut actuel du poste. WordPress utilise 8 statuts par défaut :« Publier », « Futur », « Brouillon », « En attente », « Privé », « Corbeille », « Brouillon automatique » et « Hériter ».comment_status– active et désactive les commentaires sur un seul article ou sur une page entière. Il existe deux valeurs possibles :"ouvert" et "fermé".ping_status– identifie si une publication autorise les pingbacks et les trackbacks. Commecomment_status, il ne peut contenir que les valeurs "ouvert" et "fermé".post_password– le mot de passe utilisé pour consulter la publication (facultatif).post_name– l'url lisible par l'homme d'unpost_title.to_ping– une liste d'URL auxquelles WordPress doit envoyer des pingbacks, délimitées par "\n".pinged– une liste d'URL auxquelles WordPress a envoyé des pingbacks, délimitées par "\n".post_modified– la date et l'heure les plus récentes auxquelles un message a été modifié.post_modified_gmt– la date GMT/UTC pourpost_modified.post_content_filtered- utilisé par les plugins pour mettre en cache les transformations coûteuses du contenu des publications.post_parent– fait référence au message parent.guid– Identifiant global unique pour un poste ; son URL permanente.menu_order– utilisé pour la commande de contenu.post_type– le type d'enregistrement. Il peut contenir les valeurs "post", "page", "attachment" ou des types personnalisés définis par l'utilisateur.post_mime_type– le type de fichiers téléchargés défini uniquement pour les publications avecpost_type = attachment. Il peut contenir des valeurs telles que "image", "application/pdf" et "application/msword".comment_count– le nombre de commentaires, pingbacks et trackbacks de la publication.
Voici un aperçu des wp_posts tableau après avoir ajouté la page "À propos de Nikola Tesla" :
Lorsque nous examinons les wp_posts tableau, nous pouvons voir quelques versions de notre page. L'enregistrement avec l'ID = 1 a post_status = publish , ce qui signifie que la publication est visible par tous. Le comment_status = closed et ping_status = closed indique que les commentaires et les pings sont désactivés pour ce message.
Toute information supplémentaire sur les publications et les pages est conservée dans le wp_postmeta tableau :
Les colonnes de ce tableau sont les suivantes :
meta_id– la clé primaire de la table.post_id– une référence auwp_poststableau.meta_key– une description d'unemeta_valueattribut.meta_value– la valeur réelle stockée.
Le wp_postmeta table est l'endroit où toutes les informations qui ne peuvent pas être enregistrées dans le wp_posts le tableau est stocké. Il est stocké sous forme de paires clé-valeur, une technique souvent appelée entity-attribute-value (EAV). Le tableau peut être utilisé par des plugins pour des besoins personnalisés.
Taxonomies WordPress
Taxonomie est un mot fantaisiste qui se réfère essentiellement au regroupement de choses ensemble. WordPress a quelques taxonomies intégrées pour regrouper les publications. Par exemple, catégories et balises sont des taxonomies WordPress intégrées. Vous pouvez également ajouter vos propres taxonomies personnalisées à WordPress.
Les taxonomies et leurs termes sont conservés dans des tables appelées wp_terms , wp_term_taxonomy , et wp_term_relationships .
Le wp_terms table stocke une liste de termes utilisés pour classer les objets dans votre site WordPress :
Ce tableau contient tous les noms de balises et de catégories, ainsi que les termes de nos taxonomies personnalisées. Les attributs sont les suivants :
term_id– la clé primaire de la table.name– le nom du terme.slug– l'URL dename.term_group– utilisé pour regrouper des termes.
Voici le contenu des wp_terms tableau :
Les termes sont affectés à des taxonomies à l'aide du wp_term_taxonomy tableau :
Les attributs du tableau sont :
term_taxonomy_id– la clé primaire de la table.term_id– la référence auwp_termstableau.taxonomy– le nom de la taxonomie.description– une description d'un terme dans cette taxonomie particulière.parent– une référence au terme parent dans lewp_termstableau.count– le nombre d'objets dans lewp_poststable qui utilise ce terme dans cette taxonomie.
Le wp_term_taxonomy table nous permet de réutiliser le même terme dans différentes taxonomies. Notez que l'enregistrement où term_id = 1 a taxonomy = category , tandis que les autres enregistrements ont taxonomy = post_tag .
Pour associer des objets enregistrés dans le wp_posts et le wp_term_taxonomy tables, WordPress utilise le wp_term_relationships tableau :
Notez qu'il s'agit de la seule table du modèle qui possède une clé composée de plusieurs attributs.
Les wp_term_relationships table a les attributs suivants :
object_id– une référence auwp_poststableau.term_taxonomy_id– une référence auwp_term_taxonomytableau.term_order– le terme ordre pour un objet spécifique.
Nous avons six enregistrements ici qui relient six enregistrements du wp_term_taxonomy table avec la publication (object_id = 6 ).
Commentaires et modélisation de données WordPress
Nous avons réussi à placer du contenu sur notre page WordPress. C'est bien, mais dans la plupart des cas, nous voulons obtenir des commentaires du public. Et c'est le rôle de la fonction de commentaire.
Pour afficher les commentaires sur les publications, nous pouvons simplement utiliser "Laisser un commentaire" ou cliquer sur "X Commentaire" (où X représente le nombre de commentaires pour la publication).
Notre premier post a déjà un commentaire. Lorsque nous cliquons dessus, nous verrons qu'il s'agit d'un commentaire automatique causé par le pingback. Nous ajouterons un autre commentaire à ce post :
Nous voyons maintenant deux commentaires pour notre article, mais qu'y a-t-il derrière tout cela dans la base de données ?
Vous pouvez deviner à partir du nom de la table que le wp_comments table est utilisé pour stocker les commentaires sur notre page WordPress :
Les attributs sont pour la plupart explicites, mais nous allons quand même en examiner de plus près certains.
Le comment_post_ID est une référence au wp_posts table; il indique quelle publication a reçu des commentaires. Pour le premier commentaire, on peut voir qu'il s'agissait en fait d'un pingback et que "l'auteur" est un autre post. Pour le deuxième commentaire, on voit que j'en suis l'auteur. Remarquez également le comment_agent contient des informations de base sur le système et l'ordinateur utilisés pour publier un commentaire.
L'idée principale derrière les trois méta-tables du modèle est de stocker les données que nous ne voulons pas stocker dans notre table principale. Le wp_commentmeta est lié au wp_comments table de la même manière que le wp_postmeta la table est liée au wp_posts tableau.
Voir les utilisateurs de WordPress
Une fois notre page en ligne, tout le monde peut la voir. Les utilisateurs de WordPress sont ceux qui, selon leur statut d'autorisation, peuvent apporter des modifications à notre site et à son contenu.
Nous allons maintenant jeter un coup d'œil sur les wp_users et le wp_usermeta tables dans la base de données MySQL.
Comme prévu, le wp_users Le tableau ci-dessus stocke les données de base de tous les utilisateurs enregistrés sur notre site WordPress. Notez que le user_pass est crypté et que NewUser a le user_activation_key attribut rempli alors que edrkusic a ce champ vide.
Alors que les attributs répertoriés dans le wp_users table sont ce que nous attendons de n'importe quel site WordPress, le wp_usermeta table est utilisée pour stocker des valeurs qui pourraient être spécifiques à un certain projet :
Par exemple, notez que l'enregistrement avec umeta_id = 25 contient la valeur "certaines informations biographiques" , le même texte que nous avons tapé dans le tableau de bord lors de la modification de NewUser. Le user_id l'attribut dans cet enregistrement a la valeur 2 , qui correspond à l'identifiant du NewUser dans le wp_users table. Évidemment, le user_id est une référence au wp_users tableau.
Liens et options dans WordPress
L'idée derrière les wp_links table est de stocker des liens vers d'autres sites :
Avoir des liens vers d'autres sites était très populaire au début de l'ère des blogs; de nos jours, il est de moins en moins utilisé. À partir de la version 3.5 de WordPress, l'administration des liens a même été supprimée de l'interface d'administration. Néanmoins, ce tableau est conservé pour assurer la compatibilité avec les anciennes versions.
Les wp_options table stocke des données sur l'installation de WordPress, la configuration du site, le thème, les plugins et les widgets :
Il est également utilisé pour stocker des données temporaires en cache. La logique EAV est également présente dans ce tableau, comme dans wp_usermeta , wp_postmeta et wp_commentmeta . L'attribut option_name joue le rôle de la clé, tandis que l'attribut option_value est sa valeur correspondante. Les deux autres attributs du tableau sont l'attribut de clé primaire option_id et autoload , qui contrôle si une option est automatiquement chargée à partir de la base de données.
Évaluer le modèle de base de données de WordPress
Le modèle de base de données derrière WordPress ne suit pas plusieurs bonnes règles et conventions de conception de base de données. Lorsque nous concevons une base de données dans un but précis, connaissant à l'avance toutes ses fonctionnalités souhaitées, nous pouvons suivre toutes ces règles. Mais WordPress doit couvrir tout ce que tout le monde pourrait avoir à l'esprit, donc sacrifier les clés étrangères et utiliser EAV est quelque chose qui doit être fait. Je nommerais l'attribut ID de la même manière dans toutes les tables et je ferais de même avec les "clés étrangères". Par exemple, je n'utiliserais pas post_author dans le wp_posts table, mais je m'en tiendrai à users_id . En dehors de cela, je dois convenir que la base de données WordPress est vraiment un excellent modèle pour son objectif.
Qu'en penses-tu? Faites-le nous savoir dans la section des commentaires.
