WordPress MU: la base de données

La fusion entre WordPress et WordPress MU sera effective avec la version 3.0 de WordPress, dont la publication est prévue pour avril prochain. Je continue donc la visite de WordPress MU, en me plaçant cette fois d’un point de vue développeur. Nous allons étudier les différences entre la base WPMU et celle de la version « standard » de WordPress.

WordPress

Je vous ai déjà présenté la base de données de WordPress.
Globalement, nous avons

  • Une table par objet:
    • wp_posts contient les articles et les pages,
    • wp_links contient les liens (bookmarks),
    • wp_users stocke tous les utilisateurs du blog,
    • wp_comments conserve tous les commentaires de tous les articles et/ou les pages.
    • wp_terms contient les tags et les catégories
  • Des tables pour les propriétés des objets précédents
    • wp_postmeta,
    • wp_usermeta,
    • wp_commentmeta,
  • Des tables de liaisons
    • wp_terms_taxonomy,
    • wp_terms_relationship,
  • Des tables de « fonctionnement »
    • wp_options

Vue globale de la base de données de WordPress

WordPres MU

WordPress MU doit gérer un ensemble de blogs. Les concepteurs avaient le choix entre deux solutions:

  • Ajouter un champ dans chacune des tables pour indiquer à quel blog appartient la donnée manipulée,
  • Créer « un schéma » pour chacun des blogs

La première solution est la plus propre. Le schéma de la base est fixé une bonne fois pour toute lors de la création de la plateforme. Mais en pratique elle pose deux problèmes principaux:

  • elle n’est pas « scalable ». Si la plateforme doit gérer des plusieurs centaines de blogs, très actifs, les tables deviendront imposantes, et la base demandera donc des moyens importants pour fonctionner correctement,
  • elle rend difficile le partage de code avec WordPress standard. En effet, toutes les requêtes doivent être réécrites.

La seconde solution corrige les deux inconvénients précédents: mais le principe n’est pas élégant, puisque la base évolue en fonction du nombre de blogs crées.

Malgré tout, il s’agit de la solution retenue. Nous avons donc, dans une base WPMU, un jeu de table, dupliqué autant de fois qu’il y a de blogs:

  • wp_x_posts,
  • wp_x_postmeta,
  • wp_x_links,
  • wp_x_users,
  • wp_x_commentmeta,
  • wp_x_comments,
  • wp_x_terms,
  • wp_x_usermeta.

Avec x, l’identifiant de chaque blog.

Deux mêmes tables ne pouvant pas porter le même nom, les tables se différencient en portant l’identifiant du blog auquel elles appartiennent: pour le blog dont l’identifiant est 2, les tables porteront les noms wp_2_posts, wp_2_links, wp_2_options …

Les tables wp_users et wp_usermeta ne font plus partie de ces schémas, puisque la table des utilisateurs est commune à tous les blogs

De même, WordPress MU intègre un certain nombre de tables, lui permettant de stocker les données communes à tous les blogs, et/ou nécessaires à son fonctionnement:

  • wp_sites gère les sites. Un site peut être assimilé à un domaine. Cette notion de site, présente dans la base de données, n’est pas encore gérée au niveau de WPMU. Même si les fonctionnalités ne sont pas encore disponibles, la notion de site existe déjà dans la base de données. Certains plugins ICI ou LA, permettent de gérer les sites,
  • wp_sitemeta contient un certain nombre de paramètres liés à chaque site. Parmi ces paramètres, un grand nombre servirons de valeur par défaut pour les options des blogs crées,
  • wp_sitecategories contient la liste des catégories de l’ensemble des blogs d’un site donné,
  • w_registration_log et w_registration_log: le rôle de ces tables n’est pas encore très clair pour moi. Je pense que ces tables accompagnent la table wp_users, en enregistrant l’activité des utilisateurs, qu’ils soient enregistrés ou pas.

Donc le schéma global de cette base de données est le suivant:

Vue globale de la base de WordPress MU

Règles de développement

Il s’agit d’un rappel, mais les rappels ne font jamais de mal: Pour être compatible avec les deux versions de WordPress, et avec la future version commune 3.0, un plugin ou un thème ne doit en aucun cas utiliser le préfixe wp_ directement. Il faut

  • Soit éviter les requêtes SQL, en utilisant des fonctions existantes,
  • Soit utiliser les fonctionnalités de la classe WP

Exemple: Si nous voulons récupérer tous les articles à partir d’un champ personnalisé spécifique, le code pourrait être:

global $wpdb;
$sql = 'SELECT ID, post_title,meta_value FROM wp_posts, wp_postmeta WHERE meta_key="serie" and ID=post_id';
$results = $wpdb->get_results($sql);
...

Le code correct est

global $wpdb;
$sql = 'SELECT ID, post_title,meta_value FROM '.$wpdb->posts.', '.$wpdb->postmeta WHERE meta_key="serie" and ID=post_id';
$results = $wpdb->get_results($sql);
...

De cette façon ce code fonctionnera:

  • aussi bien avec WordPress, qu’avec WordPress MU,
  • si l’utilisateur a choisi d’utiliser un préfixe différent du préfixe standard (conseillé pour la sécurité).

Conclusion

Le choix stratégique de créer un schéma par blog, donne quelque chose d’assez lourd d’un point de vue base de données, mais finalement extrêmement pratique d’un point de vue développeur. En effet, nous n’avons pas à modifier les requêtes pour passer de WordPress à WordPress MU, ce qui pérennise les plugins et les thèmes (lorsqu’ils sont bien développés), et facilitera la fusion entre les deux branches.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *