Cinq WordPress pour le prix d’un !

Depuis que j’ai migré tous mes sites sous WordPress, je me retrouve à devoir gérer cinq installations de WordPress, à devoir faire touts les mises à jour cinq fois… Pour simplifier les choses, ça serait donc bien d’avoir une seule installation de WordPress pour les cinq sites. C’est justement ce que permet la fonction « Networks » de WordPress…

Mais vous l’aurez compris, si je vous en parle ici dans la rubrique « bidouille », c’est que cette solution ne me convenait pas, et que j’ai bricolé un truc maison…

Du temps où j’étais sous Dotclear, j’utilisais la fonction multi-site, mais elle m’a posé des soucis plus d’une fois, notamment parce que tous les sites se retrouvent unis dans une seule et même base de données, compliquant la migration d’un site vers un autre serveur et rendant non trivial le retour à un mode « mono-site », par exemple pour garder une version antérieure de DotClear pour l’un des sites…

Le même problème se serait posé avec WordPress, avec un problème en prime : l’obligation de reconfigurer pas mal de choses lors de la migration des site indépendants vers une installation multi-site. Le contenu est en effet conservé, mais pas les paramètres d’apparence, les réglages des plug-ins, les menus, etc…

Bon alors du coup, comment faire ? À l’ancienne ! L’idée est de garder un dossier WordPress sur le serveur pour chaque site, mais en faisant pointer le gros de ce dossier vers une même installation de WordPress via des liens symboliques. Seul le dossier wp-content/uploads va rester réellement individualisé.

Pour ce faire, il suffit dans chaque répertoire WordPress de faire un lien vers chaque fichier/répertoire de WordPress, sauf wp-content puis d’y créer un dossier wp-content contenant un lien vers chaque sous-dossier de wp-content, sauf uploads.

Le script suivant permet de réaliser cette opération :

#!/bin/sh
REFERENCE_WP=/home/wordpress
DEST="wp"
if [ "$1" != "" ]; then
  DEST=$1
fi
echo "Création d'un WP dans le dossier ${DEST}"
if [ "$2" != "" ]; then
  UPLOADS=$(cd $2; pwd)
  echo "Redirection d'uploads vers ${UPLOADS}"
fi
mkdir -p ${DEST}
cd ${DEST}
find ${REFERENCE_WP} -maxdepth 1 -exec ln -s {} \;
rm wp-content
mkdir wp-content
cd wp-content
find ${REFERENCE_WP}/wp-content/ -maxdepth 1 -exec ln -s {} \;
rm -f uploads upgrade
if [ "${UPLOADS}" == "" ]; then
  mkdir uploads
else
  ln -s ${UPLOADS} uploads
fi

Il faut renseigner l’emplacement réel de l’installation de WordPress à la première ligne et passer en paramètre optionnels le dossier où créer une installation « virtuelle » (par défaut, un dossier wp dans le répertoire courant) et l’emplacement du répertoire uploads s’il doit être ailleurs que dans wp-content/uploads (un lien symbolique sera alors créé).

Reste à s’assurer que WordPress utilise bien les bons chemins, et surtout, la bonne base de données pour chaque site. Pour ce faire, il faut jouer sur le fichier de configuration en chargeant diverses configuration en fonction de l’URL.

Pour ce faire, remplacez les valeurs de configuration dans wp-config.php par des variables :

define('DB_NAME', $dbName);

/** Utilisateur de la base de données MySQL. */
define('DB_USER', $dbUser);

/** Mot de passe de la base de données MySQL. */
define('DB_PASSWORD', $dbPassword);

/** Adresse de l'hébergement MySQL. */
define('DB_HOST', $dbHost);

Vous pouvez également le faire pour d’autres variables, selon vos besoin (je le fait par exemple aussi pour WP_LANG, pour gérer un site en anglais et les autres en français).

Ajoutez également au début du fichier wp-config.php un include du fichier dans lequel seront définies ces nouvelles variables, fichier de préférence placé en dehors de l’installation de WordPress :

include(dirname(__FILE__)."/../multisite.php");

(Note : tout pourrait en fait être fait dans le fichier wp-config.php, mais je préfère passer par un fichier séparé pour limiter le risque d’écrasement en cas de mise à jour de WordPress…)

Il ne reste alors plus qu’à remplir ce fichier avec les configuration des différents sites. Voici un exemple avec deux sites :

$host = $_SERVER["HTTP_HOST"];

$dbSuffixe = "";
$dbHost = "localhost";

if ($host == "www.infobidouille.com") {
  $dbName = "db_ibd";
  $dbUser = "sql_ibd";
  $dbPassword = "pswd_ibd";
}
else if ($host == "www.isac-informatique.fr") {
  $dbName = "db_isac";
  $dbUser = "sql_isac";
  $dbPassword = "pswd_isac";
}

define("WP_CONTENT_DIR", "/home/www/$host/wp/wp-content");
define("WP_CONTENT_URL", "http://$host/wp/wp-content");
define("WP_LANG_DIR", "/home/wordpress/wp-content/languages");
define("WP_PLUGIN_DIR", "/home/wordpress/wp-content/plugins");
define("WP_PLUGIN_URL", "http://$host/wp/wp-content/plugins");
define("WPMU_PLUGIN_DIR" , "/home/wordpress/wp-content/mu-plugins");

WP_CONTENT_DIR doit pointer vers le répertoire wp_content individualisé, WP_PLUGIN_DIR doit pointer vers le répertoire wp-content/plugins de l’installation commune.

Attention, si vous avez une configuration DNS un peu souple, autorisant l’accès à votre site via plusieurs sous-domaine sans redirection forcée, pensez à utiliser des comparaisons par expression régulière plutôt que des simples égalités de chaînes…

Et voilà, vous avez un beau WordPress multi-site prêt à prendre du service. Désormais, les mises à jour faites sur un site s’appliqueront aussi à tous les autres, et les extensions ou thèmes installés sur un site seront aussi accessibles (mais pas activés par défaut bien sûr) sur les autres.

Attention tout de même, cette solution reste un bricolage qui n’a rien d’officiel, et qui pourrait donc être cassé lors d’une mise à jour… Mais au pire, un simple cp -r permet de revenir à de vraies installations individualisées… Des problèmes peuvent également survenir avec certaines extensions. Par exemple, pour l’extension Fourteen Extended, j’ai dû rajouter ça dans le fichier de configuration pour que l’extension retrouve ses petits :

define("CMB_META_BOX_URL", WP_CONTENT_URL."/plugins/fourteen-extended/functions/cmb/");

Il peut également y avoir quelques problèmes de sécurité si les sites gérés ainsi n’appartiennent pas aux mêmes utilisateurs… Pour les simples rédacteurs, pas de problème, chacun ne pourra impacter que le site sur lequel il a des droits, mais par contre, les administrateurs ont la possibilité via l’interface de Dotclear de modifier les fichiers des extensions et des thèmes, ce qui peut affecter les autres sites. Pour les thèmes, il faudra donc recourir à des thèmes enfants s’il faut apporter des modifications spécifiques pour un site.

De même, l’administrateur d’un site peut désinstaller un thème ou une extension utilisée par un autre site…

Dans le cas de site réellement indépendants, il est donc préférable de ne garder que des profils Éditeur au maximum et de réserver le profil Administrateur au responsable du serveur, qui pourra installer des thèmes et des extensions à la demande des autres utilisateurs. Il manque malheureusement un rôle intermédiaire qui aurait le droit d’activer/désactiver des thèmes ou des extensions et d’en modifier les réglages, mais sans le droit d’installer/supprimer.

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.