Mieux comprendre le mode multisite quand on est développeur

(1747 mots)

Cela fait un certain nombre de fois que l’on me pose la question et encore ce week-end lors du #wceu, du coup je me suis dit qu’un billet serait succeptible d’y répondre : le multisite comment ça marche en vrai ?

Partons donc pour une petite exploration.

La partie facile

Le mode multisite c’est donc, comme son nom l’indique, plusieurs sites sur une seule et même installation WordPress.

On aura deux modes principaux :

Grâce à quelques constantes dans le fichiers wp-config.php et quelques règles dans le fichier .htaccess (réglages fournis pas WP lors de la création du réseau) on va pouvoir mettre en place l’un des deux modes et pouvoir générer des sites à la demande. Le passage au multisite doit donc être assuré par un profil technique, il faut éditer certains fichiers critiques de l’installation.

L’autre nom du multisite c’est « usine à sites », un fonctionnement qui n’est pas sans rappeler l’offre WordPress.com et qui est donc à disposition de chaque installation WordPress.

La partie zappée

Le cloisonnement

Ce qui est souvent zappé c’est le côté cloisonné de base du multisite. La plupart des débutants sur ce mode vont penser qu’il est extrêmement facile d’interconnecter absolument toutes les ressources du réseau de site ainsi créé. Autrement dit, on s’attend souvent à ce que les médias soient partagés d’un site à l’autre ce qui n’est pas du tout le cas nativement.

Pas d’inquiétude, il existe déjà pas mal de resources et des développements spécifiques permettent de relier des objets (~ contenus) entre les différents sites du réseau mais il faut bien être conscient que le mode multisite n’est pas conçu pour ça à la base. C’est un usage dérivé. Je n’ai pas dit « mauvais » usage ni impossible hun ^^, juste « dérivé ». Si ça se trouve, un jour, on se rendra compte que le « bon usage » c’était l’interconnexion en fait d’ailleurs wink

Source

L’idée de base était que chaque site ait sa propre instance, avec possibilité de partager des ressources commes les plugins, les thèmes, les utilisateurs du réseau.

Autre point de cloisonnement : le rôle super admin et les administrateurs. A l’heure où j’écris, en mode multisite, WP créé un nouveau rôle, le super admin qui gère le réseau entier, il a donc les super privilèges et peut donc tout faire sur l’ensemble des sites. Chaque site du réseau a ses propres administrateurs (rôle classique de WP) qui demeurent dans leur propre site chacun et n’ont pas accès autres autres sites, encore moins à l’interface réseau. C’est pyramidal !

Les cas à éviter

La liste ne se veut pas du tout exhaustive mais les quelques cas suivants semblent assez incompatibles avec le multisite :

Le fonctionnement

Mais techniquement, comment WordPress charge les bonnes informations sur chaque site du réseau ? C’est la question qui revient souvent, et pour cause, car ce n’est pas si évident que ça et on peut tout à fait mettre en place des réseaux sans vraiment piger ce qui passe dans la salle des machines. Que se passe-t-il en base déjà ?

Les tables SQL et leur structure

La table des users et usermetas est conserveé et reste unique en mode multisite, toutes les autres tables sont dupliquées pour chaque site du réseau au moment de leur création et un préfixe avec l’ID du site est ajouté.

WordPress rajoute les tables générales suivantes lors de l’installation ou du passage en mode multisite :

La table des users est commune à tous les sites.

wp_site

Elle contient notamment l’ID du réseau ainsi que les domaines des sous-sites. Cette table permet de passer en mode très avancé et d’activer **le multi-réseaux*** ! En effet chaque site est associé à un réseau, donc une ID réseau et un domaine pour chaque entrée dans la table.

Dans 99% des cas il s’agira d’une installation mono-réseau et donc l’ID réseau sera celle du 1er site et vaudra 1.

* Pour l’avoir déjà mis en place ce n’est pas très compliqué, le code est là mais rien n’est vraiment documenté en la matière et le besoin reste assez spécifique.

wp_sitemeta

WordPress y stocke les réglages du réseau commes les options mais aussi la liste des plugins activés niveau réseau par exemple.

wp_blogs

Tous les sous-sites du réseau y sont présents. Il faut faire attention aux confusions car WP utilise site_id pour l’ID du réseau, si vous souhaitez retrouver l’ID d’un des site du réseau, c’est bien la colonne blog_id qui est concernée.

wp_blog_versions

Utilisée principalement lors des mises à jour. D’une version majeur à l’autre, il n’est pas rare d’avoir des changements en base, or comme certaines tables sont dupliquées (ex: wp_posts, wp_postmetas), WordPress stocke un registre des versions pour chaque site du réseau ce qui va lui permettre de n’oublier aucune occurrence.

wp_signups

Utilisée si le super admin a autorisé la création de sites sur le réseau. À ce moment-là WordPress va tenir un registre avec chaque site inscrit mais pas encore activé, l’entrée est supprimée dès que le site est activé.

wp_registration_log

Ici sont stockés les IDs des utilisateurs administrateurs de chaque site (blog_id) du réseau lors de l’enregistrement.

Et donc que fait WordPress avec ça ?

Où chercher ?

Les constantes qu’on nous demande de rajouter dans le wp-config.php ne sont pas là pour décorer vous vous en doutez. Avec la ligne :

define('MULTISITE', true);

(utilisée dans la fonction wrapper is_multisite() ) WP active tout un tas de fonctions qui vont inclure des fichiers qui eux même vont définir des fonctions…etc. On appellera ça ici le bootstrap du multisite. Comme d’habitude WP va utiliser la requête principale, typiquement l’URL entrée par l’utilisateur mais cette fois-ci en complément il va s’appuyer sur les tables SQL globales évoquées plus haut dans le billet pour bien séparer les choses.

A chaque requête reçue, WP va bien devoir choisir quel ensemble de tables il va devoir utiliser. Je vous le disais tout à l’heure certaines tables sont dupliquées et un préfixe contenant l’ID du site (blog_id) est ajouté. Donc si j’ajoute un site pour la première fois dans le multisite on va se retrouver, en base, avec :

et WP va incrémenter à l’infini. WordPress.com ça représente des dizaines de millions de sites ! Cette ID de site (blog_id) est donc essentielle au fonctionnement du multisite. Si la base est pétée à ce niveau, les contenus s’envolent.

Le bootstrap du multisite

Il est inclus dans le bootstrap WP classique, jugez plutôt :

require( ABSPATH . WPINC . '/ms-settings.php' );

En fait pour trouver ce que l’on cherche ici il suffit juste de remonter les fichiers et on aboutira à ms_load_current_site_and_network(), cette fonction est majeure. C’est grâce à elle que WP sait quelles tables il va falloir utiliser pour tel domaine donc tel sous-site du réseau. Cette information est utilisée partout, y compris pour certains éléments du cache. L’élément important dans cette fonction c’est la globale $current_site.

Suivant la configuration (sous-domaines, sous-dossiers), WordPress va la remplir différemment, c’est visible nettement dans le code. Et enfin pour boucler la boucle, dans le cas où on ferait du SUNRISE (multidomaines), c’est cette fameuse globale que viennent écrire [AVANT] les plugins de mapping et WordPress sait alors qu’il ne faut pas prendre en compte ce qui se passe dans le fichier ms-load.php

Jetez un oeil au fichier sunrise.php de ce plugin pour mieux comprendre par exemple : WPMU Domain Mapping

Conclusion

Vous savez maintenant j’espère un peu mieux ce qui se passe derrière en mode multisite en plus des différentes règles de réécritures fournies par WordPress qu’on copie machinalement. Il y aurait tellement de choses à dire sur ce mode mais ici je voulais juste préciser ce fonctionnement qui n’est pas forcément clair même lorsqu’on développe pour WordPress depuis quelques temps.

Dans la même veine, tu peux aussi lire :

2 réponses à “Mieux comprendre le mode multisite quand on est développeur”

  1. Si je peux me permettre de compléter un peu ton article pour celles et ceux qui souhaites comprendre un peu plus la notion de multi-réseaux, comment y avoir facilement accès et la différence avec le multi-sites … la conférence de John James Jacoby (au WordCamp Chicago 2014) est plutôt bien pour cela : https://wordpress.tv/2014/07/26/john-james-jacoby-multisite-and-multi-network/

    NB Concernant le domain mapping : Avec une installation multi-réseaux il n’y a plus besoin d’extension pour cela 😉