Vous le savez peut-être déjà, j’utilise WordPress et WordPress Mu sur mes divers blogs. Depuis quelques mois déjà, je crée en priorité des blogs à base de WordPress Mu dans le but de gagner du temps de maintenance. L’objectif est atteint, mais il y a des défauts qui ne me permettent pas de considérer cette solution comme pleinement satisfaisante et m’incitent au contraire à continuer à chercher.
WordPress Mu pour gérer plusieurs blogs
Tout d’abord, WordPress Mu est la version multi-utilisateurs et multi-blogs de WordPress. Alors que WordPress gère sans difficulté plusieurs utilisateurs sur un même blog, il ne peut gérer plusieurs blogs depuis une même installation. Pour pouvoir gérer plusieurs blogs à base de WordPress, de nombreuses solutions existent, dont WordPress Mu, donc, mais pas uniquement.
WordPress Mu en retard sur WordPress
WordPress Mu permet donc de gérer plusieurs utilisateurs et plusieurs blogs, mais avec certaines limites. La toute première limite concerne la mise-à-jour de WordPress Mu. En effet, WordPress Mu étant basé sur WordPress, les mises-à-jour de WordPress Mu suivent les mises-à-jour de WordPress. Or, certaines mises-à-jour de WordPress concernent la sécurité avec des failles aussitôt documentées, mais la mise-à-jour de WordPress Mu tarde à venir. On obtient alors la désagréable impression de jouer à la roulette russe avec ses blogs, espérant qu’aucun pirate ne piratera le réseau de blogs avant la correction officielle du défaut mis en évidence. Certes, on peut toujours envisager de reporter ces modifications soi-même, mais cela va à l’encontre de la productivité que WordPress Mu permet d’atteindre sur la maintenance de plusieurs blogs : autant revenir à plusieurs installations distinctes de WordPress.
WordPress Mu et les plugins
Autre limite gênante avec WordPress Mu : cette solution ne permet pas la gestion de blogs sur des noms de domaines distincts. Pour pouvoir utiliser des blogs sur des noms de domaines distincts, il faut nécessairement utiliser des plugins dédiés à WordPress Mu. Or, ces plugins sont plus ou moins bien supportés dans le temps, voire même plus ou moins compatibles entre eux. Plus gênant encore : WordPress Mu n’est pas compatible avec tous les plugins WordPress. En réalité, ce sont les plugins WordPress qui ne sont pas tous compatibles avec WordPress Mu. Peu importe ! Le résultat est le même : vous ne pourrez utiliser tous les plugins WordPress avec WordPress Mu. Les plugins étant plus rares, la qualité plus faible, tout comme les performances ou l’ergonomie. Bref, et je parle d’expérience, créer un nouveau blog WordPress Mu sur un nouveau nom de domaine devient, parfois, un véritable cauchemar.
Alternative à WordPress Mu à base de WordPress
Ces quelques défauts de WordPress Mu m’amènent à rechercher d’autres solutions. L’objectif initial reste le même : gagner du temps sur la gestion de blogs multiples à base de WordPress sur un même serveur web. L’objectif secondaire est de se rapprocher autant que possible de WordPress. De plus, si besoin, cette solution alternative peut s’affranchir de nombreuses contraintes. Ainsi, les utilisateurs des blogs sont des utilisateurs de confiance, il n’est pas nécessaire de gérer des droits d’accès spécifiques à chaque blog.
WordPress multi-blogs et liens symboliques
Si vous connaissez le monde UNIX, vous y avez peut-être pensé avant moi : les liens ! En effet, il est possible de créer des liens symboliques et des liens en dur au sein de la plupart des systèmes de fichiers utilisés sous UNIX. Un lien symbolique est un fichier indiquant où se trouvent le fichier d’origine. Un lien en dur est un pointeur vers les données du fichier, sachant que les données d’un même fichier se situent au même endroit sur le disque dur, alors qu’il y a plusieurs pointeurs de fichiers.
L’idée est donc la suivante : on installe les fichiers WordPress dans un dossier de partage. Pour chaque blog, on fait des liens symboliques vers les fichiers communs ainsi partagés et l’on copie chaque fichier qui doit être spécifique à un blog donné. Il s’agit essentiellement du fichier de configuration, ainsi que divers autres fichiers plus subtils que je ne détaillerai pas ici. Bref, on obtient donc autant de blogs que l’on souhaite avec une seule version de WordPress.
Notez qu’outre le fait que cette solution permette de gagner de la place sur le disque dur, elle améliore aussi les performances par rapport à plusieurs installations distinctes de WordPress. En effet, bien que la gestion des liens symboliques prenne du temps, les fichiers étant partagés entre tous les blogs, il y a plus de chances qu’ils soient déjà présents dans le cache disque. Dans le même ordre d’idées, l’utilisation d’un cache code PHP tel qu’Alternative PHP Cache (APC) permet de ne conserver qu’un exemplaire du code mis en cache (16 Mo tout compris contre 16 Mo par installation de WordPress)
WordPress et liens symboliques à améliorer
Actuellement, j’ai noté quelques incompatibilités avec certains plugins, parmi lesquels WP Super Cache qui apparaît être instable jusqu’à sa purge, ou bien encore Sociable qui gère mal le chemin d’accès aux fichiers. Cependant, cette solution étant par ailleurs aussi simple qu’efficace, je vais me plonger davantage dessus pour la distribuer à l’avenir en open source. Mais ce ne sera pas disponible de suite, je préfère faire toutes les vérifications de compatibilité nécessaires lors de la prochaine mise à jour vers WordPress 2.7 attendu pour les semaines à venir et — surtout — nettoyer les scripts shell pour les rendre plus présentables et robustes.
L’idée est de faire un unique script shell à lancer sur son serveur qui ramène la dernière version de WordPress, les dernières versions des plugins installés et met à jour l’ensemble des blogs du serveur par la même occasion. Intéressant, non ?
Mises à jour
21/10/2008 : Merci à Henri de m’avoir fait remarquer un bug empêchant de laisser des commentaires ! Voici qui devrait être corrigé et fonctionnel, désormais.
23/10/2008 : Il y a trois types de plugins WordPress : ceux qui se repèrent dans l’arborescence avec la macro ABSPATH définie par WordPress à son lancement, ceux qui lui préfèrent __FILE__ (j’avoue ne pas en avoir identifié pour l’instant, mais j’avoue surtout de ne pas avoir beaucoup cherché) et enfin ceux qui, à l’instar de WP Super Cache, utilisent tantôt ABSPATH, tantôt __FILE__. L’idéal — pour la gestion des liens symboliques — serait que tout le monde passe par ABSPATH, mais si le monde était parfait, ce serait autrement moins drôle !
24/10/2008 : Le plugin Sociable permettant d’ajouter des liens vers la promotion des articles sur les divers services communautaires (dont Scoopeo, Delicious, etc.) utilise lui aussi la macro __FILE__ rendant l’utilisation de liens symboliques impossible ici.
j’attends cette release avec impatience
@henri : Comme tu as pu le noter par toi-même (encore merci pour le rapport de bug !), il y a encore des défauts à ce système, d’où l’intérêt de faire un maximum de tests avant la publication du système. Toujours est-il qu’ayant près de 30 blogs à gérer moi-même, je vais en principe pouvoir tester l’essentiel des configurations sur un échantillon relativement large de situations. Mais des beta testeurs, lorsque le moment sera venu, seront évidemment les bienvenus ! ;-)
Nickel ayant moi aussi quelques blogs je suis curieux de voir comment cela fonctionne en live notamment sur les aspects pratiques mais il n’y a pas de raison que cela ne fonctionne pas!
@henri : WordPress utilise beaucoup des __FILE__ pour identifier le chemin du blog dans le système de fichiers, avec des points d’entrée quelque peu éparpillés. Même si une macro globale est définie dans l’un des fichiers, les divers include et require se font de manière relative par rapport au fichier et non par rapport au lien symbolique, ce qui implique d’identifier de manière exhaustive les fichiers devant être copiés tels quels plutôt que de faire des liens symboliques. Eventuellement, la voie des liens « en dur » peut être explorée…
Pour l’instant, suite à la correction des commentaires, je note que les habillages (thèmes) apparaissent en double dans l’interface d’administration de WordPress. Il va falloir que je comprenne pourquoi ! :-D
Work in progress, donc.
tres interessant tout ca. J’attends la suite avec impatience.
Ahhhhh, voilà une solution qui serait top nickel ! Je gère aussi pas mal de blog WP et cette solution me ferait gagner un temps énorme à chaque mise à jour. Bref, je reste à l’écoute et suis prêt à aider pour beta tester la chose ;)
Article très intéressant, hâte de voir ce que cela va donner. J’attends cela avec impatience
Vous parlez de ceci :
http://wordpress.org/extend/plugins/wp-oneinstall/
est-ce exact ?
De mon côté, je ne réussi pas à le faire fonctionner, tout comme wordpress mu :(
J’ai accès à Cpanel 11. J’ai bien une option de redirection avec case wildcat, mais je ne réussi pas à le faire tourner.
Toute la doc en francais n’en a que pour du blabla sans jamais expliquer la bonne procédure, et ne fais que parler d’OVH ou de free…
J’oubliais Lyceum
http://lyceum.ibiblio.org/
Qui n’est plus mis à jour depuis des lustres…
@Blablababa : Vous me faites découvrir l’extension WP One Install qui est très intéressante, car je ne pensais pas que quelqu’un se soit intéressé à une unique installation de WordPress partagée entre plusieurs blogs sous forme de plugin. Ce dont je parle dans le présent article est une solution personnelle faite à base de liens symboliques UNIX que j’ai mise de côté, car trop contraignante par rapport à mes espoirs initiaux.
Quoi qu’il en soit, si vous n’arrivez pas à installer de solution multi-blogs et multi-utilisateurs par vous-mêmes, faites appel à un prestataire externe qui le fera pour vous. Ce ne sont pas les prestataires qui manquent dans ce domaine !
Après 1 an de tests, quel retour en as-tu ? :)
@LinKuFF : Au bout de nombreux tests et développements, j’ai abandonné l’idée de mutualiser le code source de mes blogs. En effet, WordPress Mu reste difficile à gérer sur plusieurs domaines, et les liens symboliques mettent régulièrement des défauts en évidence du côté des plugins, pas tous écrits dans les règles de l’art.
Bref, je me suis orienté vers un script bash pour mettre à jour l’ensemble de mes blogs à jour automatiquement. Cette solution a l’avantage de mettre à jour mes blogs sur tous les supports, à savoir sur mon serveur dédié, mais aussi ceux hébergés sur des hébergements mutualisés divers, ou sur d’autres serveurs.
On verra ce qu’il advient d’une éventuelle et hypothétique fusion de WordPress avec WordPress Mu. Mais pour l’instant… ça reste très hypothétique.
Merci pour ta réponse ;)
Ping : Script Multiblogs WordPress | un blog by LinKuFF