La base de données WordPress

Lors de l'installation initiale d'un site WordPress, votre site utilise déjà une structure de base de données intéressante.

Il n'est pas nécessaire de manipuler cette base de données pour développer un site WordPress. Cependant, la connaissance de sa structure vous aidera à comprendre le fonctionnement de WordPress. De plus, si vous êtes des développeurs, vous devrez connaître la base de données pour tirer parti de son fonctionnement dans les thèmes et les extensions que vous développerez.

▼Publicité

Structure de la base de données WordPress

Évidemment, le nom de vos tables ne débutera pas par « wp_ » mais bien par le préfixe que vous aurez choisi lors de l'installation.

De nouvelles tables pourront être ajoutées à cette structure par le thème et les extensions utilisées.

Attention : vous remarquerez sans doute que la modélisation de cette base de données comporte plusieurs erreurs. Malheureusement, nous devons apprendre à vivre avec.

Saurez-vous trouver ces erreurs de modélisation ?

wp_posts

La table centrale de la base de données WordPress est certainement wp_posts.

À l'origine, cette table était destinée à l'enregistrement des articles d'un blogue. Avec la nouvelle vocation de WordPress (il n'est plus seulement utilisé pour les blogues), cette table est devenue une sorte de « fourre-tout ». On y stocke :

  • le texte de chacune des pages (post_type = page)
  • le texte de chacun des articles (post_type = post)
  • les informations sur les médias (images, fichiers PDF, etc.) (post_type = attachment)
  • les options de chacun des menus (post_type = nav_menu_item)
  • l'historique des modifications sur les pages et les articles (post_type = revision)
  • etc.

Voici un extrait des données de cette table :

table wp_posts

Ce qu'il faut savoir sur cette table :

  • WordPress conserve un historique des modifications. C'est pourquoi vous retrouverez plusieurs enregistrements pour une même page. La version qui sera affichée sur le site aura la valeur "publish" dans le champ post_status.
  • Il y a un système de hiérarchie entre les différentes informations de cette table. Le champ post_parent permet de gérer cette hiérarchie. Ainsi, une ancienne version d'une page aura dans son champ post_parent l'identifiant de la page publiée. Cette hiérarchie permet également de monter des menus à plusieurs niveaux.
  • WordPress est muni d'un système de commentaires. Il est possible de laisser ou non la possibilité aux internautes de commenter une page ou un article donné grâce à son champ comment_status.
  • Le champ guid est important : plusieurs pages, articles, flux RSS peuvent l'utiliser. Son contenu ne devrait jamais être modifié.

wp_postmeta

La table wp_postmeta permet d'ajouter de l'information sur différents enregistrements de la table wp_posts. C'est en fait une extension de cette table. On y stocke des paires clé-valeur pour répondre à tous les besoins qui n'ont pas été prévus initialement dans la table wp_posts. Chaque paire est associée à l'identifiant d'un enregistrement de la table wp_posts.

Par exemple, si un thème prévoit plusieurs modèles pour les pages et articles (ex : sur une colonne, sur deux colonnes, avec tel ou tel icône, etc.), on pourra stocker le modèle d'une page ou d'un article donné sous la forme suivante :

table wp_postmeta

La table wp_postmeta sera souvent utilisée par les thèmes ou extensions pour stocker des information en lien avec de nouvelles fonctionnalités qu'ils mettent en place.

wp_users

Le contenu de cette table est plutôt évident... quoi qu'il pourrait contenir des fonctionnalités que vous ne soupçonniez pas.

Ce qu'il faut savoir sur cette table :

  • Vous pouvez modifier le mot de passe d'un usager en lui appliquant l'algorithme d'encryption MD5 soit à l'aide des outils graphiques de phpMyAdmin, soit à l'aide d'une requête SQL.

    Ex : UPDATE wp_users SET user_pass=MD5('nouveaumotdepasse') WHERE user_login='...';

  • Les usagers peuvent avoir différents rôles. Les rôles sont cependant stockés dans la table wp_usermeta.
    • Super-administrateur (pour WordPress multi-sites)
    • Administrateur
    • Editeur
    • Auteur
    • Contributeur
    • Abonné
  • Le champ user_email doit contenir une valeur unique dans toute la table. Il n'est donc pas possible d'avoir un administrateur et un abonné qui utilisent le même courriel.

wp_usermeta

Cette table est un complément à la table wp_users avec des enregistrements sous la forme de paires clé-valeur. Toutes les configurations des utilisateurs y sont stockées. Pour chaque utilisateur, on y retrouvera plusieurs enregistrements :

  • quel thème de couleurs l'administrateur souhaite-t-il utiliser dans le tableau de bord ?
  • la barre noire indiquant que l'usager est authentifié doit-elle apparaître sur le site ?
  • quel rôle détient l'utilisateur ?
  • d'autres configurations pouvant être ajoutées par le thème et les extensions.

wp_options

Cette table, sous la forme de paires clé-valeur, contient une foule de configurations générales. Parmi les plus importantes :

  • Adresse Web de WordPress (option_name = siteurl). Il s'agit de l'endroit où les fichiers de WordPress sont installés. La valeur entrée ici doit débuter par http:// .
  • Adresse Web du site (option_name = home). Il s'agit de l'adresse que les internautes utiliseront pour afficher le site. Dans la majorité des cas, cette configuration contiendra les mêmes informations que le siteurl.
  • Dès l'installation d'un site WordPress, cette table contient plus de 150 enregistrements. Si vous y faites des recherches dans phpMyAdmin, les enregistrements de wp_options seront affichés sur plusieurs pages. N'oubliez pas de vérifier l'ensemble des pages de résultat pour y trouver ce que vous cherchez.

Pour plus d'information

« Database Description ». Codex WordPress. http://codex.wordpress.org/Database_Description

« WordPress Essentials: Interacting With The WordPress Database ». Smashing magazine. http://wp.smashingmagazine.com/2011/09/21/interacting-with-the-wordpress-database/

« Les tables personnalisées dans WordPress ». Nicolas Juen. http://blog.nicolas-juen.fr/2011/12/04/les-tables-personnalisees-dans-wordpress/

« 22 requêtes MySQL indispensables pour WordPress ». WordPress Channel. http://wpchannel.com/22-requetes-mysql-indispensables-wordpress/ 

Merci de partager ! Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInPin on PinterestShare on StumbleUponEmail this to someone
Catégories

7 commentaires

  1. Nebarha

    Alors là, je me dois de vous remercier, et même de faire des courbettes d’adoration (Sans abuser, non plus, non mais oh =D). En effet, dans l’optique de développer un nouvel éditeur de posts pour des mises en page complexes (en gros passer du pseudo Word du pauvre qu’est TinyMCE à quelque chose se rapprochant plus d’un Quark XPRess [du pauvre également XD]) , j’avais absolument besoin de savoir comment les enregistrer ces fichus posts, et voilà que vous m’apportez matière ! Merci =D

    PS: J’ai également trouvé un article détailler un peu plus les relations entre chaque table, histoire de prémâcher un peu plus l’analyse, donc je partage : http://blog.yvoz.net/2010/12/wordpress-modele-conceptuel-donnees/

    • Christiane Lagacé

      Je suis bien heureuse que cet article vous ait été utile.

      Concernant les relations entre les tables, il faut être prudent car WordPress n’applique aucune contrainte d’intégrité référentielle dans la base de données. Les relations existent bel et bien mais elles ne sont pas gérées côté serveur. Pourquoi ? Parce ce certains serveurs ne supportent que le moteur MyISAM, qui ne supporte pas les contraintes.

      Bonne chance dans votre développement !

      Christiane

  2. Bonjour,
    Un de mes sites a brutalement chuté, vu par les outils google webmaster.
    Je me suis rendu sur « outil de test des données structurée » qui ma trouvé deux erreurs ci-dessous;
    Erreur : Missing required field « updated ».
    Erreur : Missing required hCard « author ».
    Je ne sais pas si la chute viens de la mais bon !
    Je travaille avec wordpress, théme catch box
    Par contre je ne comprends le problème et comment y remédier.
    Voici le site en question
    http://perdredescuisses.net/
    Si vous avez une idée
    Merci d’avance
    Philippe

  3. Bonjour,

    Votre site est très intéressant, bravo pour votre travail !

    Je suis actuellement en bts sio en alternance et j’utilise WORDPRESS pour créer mon site.
    D’abord, j’ai installé WAMP et créé une base de donnée sous mySQL.
    Maintenant comme je ne suis pas assez avancé en matière de BDD, peut-on y ajouter des médias de gros volumes (et le lire depuis le site en créant un lien dans le backoffice de wordpress j’imagine) ?
    Puisque quand on ajoute un média dans un article, la taille de celui-ci ne doit pas dépasser 3MB.. Un peut ridicule puisque j’en suis à 26x plus ..

    Cordialement,
    Julien.

  4. Christiane Lagacé

    Bonjour Julien,

    Tout d’abord, il faut savoir que sous WordPress, les médias ne sont pas enregistrés dans la base de données. Seul leur nom est enregistré et les fichiers sont stockés directement sur le disque.

    La taille maximale pour les médias est généralement déterminée par PHP et non par WordPress. On retrouve dans le fichier php.ini une configuration nommée upload_max_filesize qui peut être configurée à la taille désirée (par défaut, 2M, je crois). Certains sites WordPress modifient cette valeur par programmation avec une instruction du genre @ini_set( ‘upload_max_size’ , ’10M’ ); Il est également possible de modifier la taille maximale dans le fichier .htaccess, présent à la racine du site Web, à l’aide de la configuration suivante : php_value upload_max_filesize 10M.

    Mais attention : tout ceci pourrait ne pas fonctionner selon les règles mises en place par votre hébergeur.

    J’espère que ceci vous sera utile !

    Christiane