La Base de Données est l’autre composant technique de WordPress, avec les fichiers du noyau que nous avons vu précédemment.
Dans cet article et le suivant, nous regardons les tables de la Base de Données, leur organisation, leur contenu et leur utilité. Nous rapprochons aussi les informations saisies dans l’administration WordPress et le contenu de la Base de Données.
Si vous ne savez pas comment accéder à la gestion de la Base de Données, l’article ci-dessous vous aidera :
Les tables de la Base de données WordPress
Pour une installation mono-site, la Base de Données WordPress est constituée de 12 tables, que nous pouvons visualiser dans phpMyAdmin :
Toutes les tables ont le même préfixe (dans notre exemple demo_ ). Ce préfixe doit être indiqué dans le fichier de configuration de WordPress : wp-config.php . Il est possible de modifier le préfixe utilisé dans une installation existante.
Dans les installations multi-sites, les tables présentent les différences suivantes :
- 6 tables spécifiques au multi-site sont ajoutées : wp_blogs, wp_blog_versions, wp_registration_log, wp_signups, wp_site, wp_sitemeta,
- une table a une structure différente par rapport au mono-site : wp_users,
- une table a une structure identique au mono-site : wp_usermeta,
- 9 tables sont créées pour chaque site : wp_2_commentmeta, wp_2_comments, wp_2_links, wp_2_options, wp_2_postmeta, wp_2_posts, wp_2_terms, wp_2_term_relationships, wp_2_term_taxonomy.
Voici un exemple de tables créées pour une installation multi-site :
- Les 6 tables spécifiques du multi-site sont en jaune,
- les 2 tables générales communes au mono et au multi sites sont en bleu,
- les 9 tables du premier site sont en mauve,
- des tables du site n°4 sont en vert (6 visibles sur 9)
- une table spécifique à un plugin est en rouge.
Vous noterez que les tables du diagramme sont préfixées par ‘wp_’ qui est le préfixe de table par défaut. Rappelons que pour des raisons de sécurité, il vaut mieux utiliser un autre préfixe lors de l’installation, voire de changer de préfixe après l’installation.
Note : pour faciliter la compréhension, dans la suite de cet article nous désignerons les tables avec le préfixe par défaut ‘wp_’.
N’hésitez pas à créer une installation WordPress locale, avec accès à phpMyAdmin pour tester vous même les interactions entre l’administration et le contenu des tables.
Haut de pageLes tables des utilisateurs (wp_users et wp_usermeta)
La liste des utilisateurs avec leurs principales informations se trouve dans la table des utilisateurs wp_users :
Certaines informations contenues dans la Base de Données correspondent à celles saisies dans l’option Utilisateurs de l’administration WordPress :
On remarque que certaines données saisies dans l’administration de WordPress ne se trouvent pas dans la table wp_users :
En fait, ces données se trouvent dans une table complémentaire à la table wp_users , la table wp_usermeta :
On remarque, encadré en rouge, un type de données particulier. En fait, il s’agit d’un tableau codé par la fonction serialize de php. On peut décoder ainsi :
- ‘a:1’ => il s’agit d’un tableau (array) à une dimension,
- ‘s:13:”administrator”’ => le premier élément est une chaîne (string) de 13 caractères = ”administrator”
- ‘b:1’ => le deuxième élément est un booléen à la valeur ‘1’ (donc VRAI)
Il s’agit en fait du ‘rôle’ WordPress attribué à cet utilisateur : il est administrateur.
Voici la description des tables wp_users et wp_usermeta dans le diagramme de tables :
À noter : la méthode pour modifier le mot de passe d’un utilisateur directement dans la Base de Données est décrite dans l’article WordPress et MySQL.
Haut de pageLes tables des articles (wp_posts et wp_postmeta)
WordPress a un sens très extensif du terme ”post (article)”. Il faut comprendre que ‘post’ désigne non seulement les articles qu’on publie (post_type=’post’), mais aussi les révisions (post_type=’revision’), les pages (post_type=’page’), les médias (post_type=’attachment’), les éléments de menu (post_type=’nav_menu_item’) et les types d’articles personnalisés que vous avez créé (post type=l’identifiant de votre article personnalisé).
Extrait d’une table wp_posts :
Les articles (posts)
Nous allons tout d’abord sélectionner des articles dans la table wp_posts :
Résultat de la recherche par type de post :
Si on sélectionne un article, on retrouve les informations saisies dans l’administration de WordPress.
Exemple d’article saisi dans l’administration (le contenu est affiché en mode texte qui correspond au html) :
Le même article stocké dans la base de données (on retrouve le texte de l’article dans le champ ‘post-content’) :
On remarquera que si le titre et le contenu de l’article (sous forme de html) sont directement lisibles à la fois dans la Base de Données et dans l’administration, l’auteur n’apparaît que par son identifiant (‘4’) dans la Base de Données et non par son nom (‘Admin WP1’) :
En fait, WordPress utilise l’identifiant de l’utilisateur pour récupérer son nom dans la table wp_users. Ceci est représenté dans le diagramme de tables par une flèche entre les tables wp_posts et wp_users :
L’intérêt de procéder ainsi plutôt que de mettre le nom à afficher directement dans les articles, c’est que si on veut modifier le nom à afficher pour un utilisateur, on modifie (via l’administration) la description de l’utilisateur, et automatiquement le nom sera changé pour tous les articles.
De l’intérêt (parfois) de modifier directement dans la Base de Données
Afin d’utiliser certaines fonctionnalités d’un thème, il peut arriver qu’on ait besoin d’un article publié mais qu’on ne souhaite pas le publier depuis l’administration (par exemple, pour éviter qu’il soit automatiquement publié sur les réseaux sociaux et/ou que des courriels soient envoyés pour signaler sa publication…). Dans ce cas, on peut changer le statut de l’article directement dans l’administration, ce qui fait qu’il sera considéré comme publié, mais sans que soient déclenchés les traitements qui vont avec la publication via l’administration :
Les révisions
Quand on rédige un article, qu’on le met à jour sans le publier ou que WordPress le sauvegarde automatiquement, des ‘posts’ avec le type de post ‘revision’ sont créés.
Les révisions vues de l’administration :
Les enregistrements de révisions dans la Base de Données :
Dans l’administration, il est possible de cliquer sur une révision pour faire apparaître l’article tel qu’il a été sauvegardé et comparer avec ce qu’il est dans la version de travail courante. Il est alors possible de remplacer la version de travail courante par une version précédemment sauvegardée :
Les pages
Les enregistrements de pages sont très proches des enregistrements d’articles :
Il existe néanmoins une différence importante : une page peut être la fille d’une autre page (on dit que les pages sont hiérarchisées) :
Les médias (attachment)
Lorsqu’on télécharge un média (image, photo, vidéo, audio, pdf…) depuis l’administration, un enregistrement est créé dans la Base de Données. Cet enregistrement ne contient pas directement le fichier média proprement dit, mais toutes les informations qui permettront de gérer le média au travers de la bibliothèque de média ou dans un article où il a été inséré.
Un média dans l’administration :
Un enregistrement pour gérer un média dans la Base de Données :
Les éléments de menu
WordPress permet de créer des menus pointant sur diverses cibles : articles, pages, catégories, liens… A chaque élément de menu correspond un enregistrement dans la Base de Données.
Description d’un menu dans l’administration :
Un enregistrement d’élément de menu dans la Base de Données :
Dans le diagramme de tables, la table wp_posts est liée à toutes les tables, hormis la table wp_options. Elle a aussi sa table complémentaire .
Il est possible d’ajouter un ou plusieurs champs personnalisés à un article. Un champ personnalisé est en fait un couple nom (qui permet d’identifier un champ personnalisé) et une valeur associée :
Les enregistrements de champ personnalisé ont une structure très simple :
- l’identifiant de l’article auquel appartient le champ personnalisé,
- le nom du champ personnalisé,
- la valeur du champ personnalisé.
Remarque : par programme, il est possible d’ajouter des champs personnalisés qui n’apparaissent pas dans l’administration. Ces champs ont pour seule particularité d’avoir un nom préfixé par le caractère de soulignement :
Haut de pageSuite de la présentation de la Base de Données WordPress
Article très complet et détaillé sur un sujet complexe. Merci pour ce partage et
toutes les explications. J’ai lu cet article avec beaucoup d’intérêt.