Technorati ne référence plus les blogs exploitant une version obsolète de WordPress afin de limiter l’impact du spam, certains pirates profitant des failles connues des anciennes versions de WordPress pour les transformer en usines à spam, publiant des millions de liens pour promouvoir des pages au contenu douteux. Pour être bien référencé et éviter de voir son blog tomber entre les mains d’autrui, il est par conséquent primordial de le mettre à jour.
Récemment, un ami qui gère lui aussi quelques dizaines de sites, dont quelques sites à base de WordPress, m’a demandé de lui faire un devis sur la base d’un abonnement lié à l’infogérance de ses sites, et plus précisément leur installation, mais surtout leur maintenance technique. En effet, maintenant déjà une trentaine de sites à base de WordPress éparpillés un peu partout dans le monde, sur des serveurs les plus divers, je commence à avoir l’habitude de ce type de mises à jour. Aussi, j’ai fait une estimation du temps que je passe à mettre à jour mes sites d’un point de vue de la maintenance WordPress et de ses extensions.
Or, contrairement à ce que j’aurais pu penser, il apparaît que ce temps de maintenance est loin d’être négligeable. En effet, il implique de :
- vérifier régulièrement la disponibilité d’une nouvelle version de WordPress ;
- faire une sauvegarde du site ;
- désactiver tous les plugins (en prenant soin de noter ceux qui étaient installés, mais non activés, afin de ne pas les réactiver à tort par la suite) ;
- télécharger la dernière version de WordPress (et dans la bonne langue !) ;
- mettre à jour WordPress ;
- réactiver les plugins (sauf ceux qui étaient désactivés précédemment) ;
- vérifier que tout fonctionne ;
- le cas échéant, restaurer le site précédemment sauvegardé ;
- faire un compte-rendu au responsable du site.
Et en plus de WordPress, il faut de même surveiller les extensions utilisées, dont les compatibilités sont très aléatoires du fait même de la grande dispersion des développeurs et de leurs disponibilités ou niveaux respectifs très hétérogènes.
Bien sûr, chacune des étapes susmentionnées présente ses imprévus :
- la fréquence des mises-à-jour est de fait imprévisible, allant de plusieurs mois d’accalmie à plusieurs mises à jour par semaine ;
- la sauvegarde du site peut être impossible sur l’espace d’hébergement lui-même, et la sauvegarde via FTP peut prendre un temps fou selon la quantité de données du site et le serveur, voire être impossible du fait de droits d’accès mal définis par le webmaster ;
- la désactivation de certains plugins peut empêcher le site de fonctionner selon la manière dont ceux-ci ont été intégrés au site et à son habillage ;
- on a déjà connu une archive officielle piratée ;
- des problèmes de droits ou l’indisponibilité de certains outils peuvent rendre la mise à jour de WordPress très fastidieuse (compter jusqu’à 20 minutes de téléchargement dans certains cas) ;
- la réactivation des plugins peut faire planter la nouvelle version de WordPress, voire la rendre inutilisable (plugins incompatibles avec la nouvelle version ; plugins réclamant trop de mémoire, entrainant parfois le plantage de la base de données, etc.) ;
- si le site semble fonctionner, encore faut-il le vérifier de manière approfondie, dont en étant connecté et en étant non connecté au panneau d’administration, et de parcourir l’ensemble des pages représentatives du site, dont les flux RSS, notamment (un plugin de mise en cache mal installé peut afficher le même contenu à toutes les pages du site dans certaines situations, mais pas dans d’autres, etc.) ;
- la restauration du site peut prendre un temps non négligeable suivant la configuration du serveur ;
- le responsable du site peut être injoignable pour une durée indéterminée, alors qu’il peut s’avérer au dernier moment qu’on ne peut effectuer une étape importante du fait d’informations manquantes que lui seul détient.
En somme, en moyenne, j’en suis arrivé à compter entre 30 et 60 minutes par mois et par site d’infogérance (maintenance technique) par site WordPress. Sans surprise, ce sont les sites que l’on gère soi-même sur son propre serveur qui nécessitent le moins de maintenance, alors que les sites tiers gérés sur des hébergements mutualisés originaux ou des serveurs dédiés aux logiciels obsolètes ou mal configurés qui nécessitent le plus de maintenance.
Aussi, depuis peu, j’installe mes nouveaux blogs non plus à base de WordPress, mais à base de WordPress Mu, avec l’extension Multi Site Manager. Alors que WordPress Mu permet de gérer des milliers de blogs sur un même domaine, que ce soit en tant que sous-domaine ou en tant que sous-dossier, Multi Site Manager permet de créer des blogs sur des noms de domaines distincts relativement aisément et rapidement.
Les mises à jour de WordPress Mu étant moins fréquentes, et suivant les mises à jour de WordPress classique, elles sont prévisibles et impliquent des coûts moindres. Cela est d’autant plus vrai qu’une même installation de WordPress Mu gérant plusieurs blogs, ce coût de maintenance s’amortit d’autant mieux. Les coûts de sauvegarde et de restauration sont eux aussi, bien entendu, sensiblement réduits, car amortis sur l’ensemble du réseau.
Il reste cependant de nombreux inconvénients à utiliser WordPress Mu à la place de WordPress.
Par exemple, les divers logs sont alors nécessairement gérés par le même serveur (à moins d’utiliser un cluster de serveurs ou un proxy), mais si l’hébergeur met à disposition plusieurs adresses IP par serveur ou par hébergement, il est en principe possible d’associer une adresse IP distincte par nom de domaine ou sous-domaine, et de jouer sur ce paramètre en vue d’améliorer le référencement des sites sur les moteurs de recherche (en associant par exemple un blog francophone à une adresse IP française et un blog anglophone à une adresse IP britannique).
Un autre défaut concerne les extensions : en effet, de nombreux plugins destinés à WordPress ne sont pas compatibles avec WordPress Mu, ce qui implique de se rabattre sur d’autres plugins, de les réécrire en conséquence, voire de s’en passer.
Par ailleurs, les mises à jour de WordPress Mu étant moins fréquentes, il convient de s’assurer que les failles découvertes dans WordPress ne touchent pas ses installations de WordPress Mu et d’agir en conséquence, ce qui implique éventuellement des coûts en sécurité cachés bien supérieurs.
Pour finir, je dirais que l’utilisation de WordPress Mu pour la maintenance d’un réseau de blogs existant semble une approche de rationalisation des coûts tout à fait cohérente et même s’il ne s’agit pas d’une solution miracle, c’est une voie qu’il est sage d’explorer quand son réseau de blogs atteint une certaine masse.
Très intéressant merci. Existe-t-il une version française de WordPress MU ?
@Olivier : Oui, WordPress Mu ne dispose pas d’une version française officielle. Cependant, pour s’en créer une, il suffit de :
Compte tenu du fait que le fichier langue n’est pas prévu pour WordPress Mu, certaines informations de l’interface d’administration seront affichées en anglais, mais l’essentiel est en français. Il en est de même pour les habillages par défaut que l’on peut mettre à jour en principe depuis la version WordPress (à vérifier).
Quelques rectifications:
-Pour la traduction en français :
http://codex.wordpress.org/WordPress_in_Your_Language#Version_MU_FR
-Pour le plugins « en effet, de nombreux plugins destinés à WordPress ne sont pas compatibles avec WordPress Mu, » Oui et non, c’est souvent une ligne ou deux dans le code à changer.les incompatibilités sont très rares.
et j’encourage forcément l’utilisation de WordPressMu..bon article !
@Tom : Je maintiens qu’il n’y a pas de version française officielle ou non de WordPress Mu. Le lien que tu indiques donne des liens vers des versions françaises de WordPress, en revanche, les versions françaises de WordPress Mu sont obsolètes et manifestement non maintenues depuis des lustres.
Je confirme : Il existe une version française pour WordPress Mu, plus ou moins officielle … Notamment pour la version 2.6 …. la dernière !
@Paris-saint-marseille : Tu as raison, WordPress Mu 2.6 dispose effectivement d’une version française via le portail WordPress francophone (pas très officiel, mais peu importe) WordPress-FR.net.
Un peu officiel quand même vu qu’elle est sur le SVN de Automattic hein…
@Amaury : Je faisais référence à WordPress-FR.net et non à la version française distribuée sur les serveurs de Automattic, la société la plus active en matière de développement WordPress et que l’on considère désormais comme développeur « officiel ».
Maintenant, on peut jouer sur les mots, mais dans un projet open source, ce qui est officiel ou ce qui ne l’est pas a relativement peu d’importance dans la mesure où le but est justement que chacun y contribue.
Ping : WordPress multi-blogs via des liens symboliques
Ping : Script bash de mise à jour automatisée de WordPress locaux et distants
Salut à tou, je fait un test avec WP Mu, j’ai suivi les instructions pour changer le langage mais cela ne fonctionnes pas :
je n’ai pas de dosssier language dans wp mu …
Une autre question si je place wp mu en sous domaine les nouveaux sous domaines crées ne fontionnent pas erreur 404.
Si quelqu’un pourrait m’aider cela serait pas du luxe :-)
Bien à vous.
@Pascal : Bon courage pour les langues : c’est une vraie galère. Quant aux sous-domaines, il faut configurer ton DNS, d’une part, et ton serveur web, d’autre part, pour accepter des « wildchars » en guise de sous-domaines.
@Martin : Pouvez vous m’indiquer comment configurer les sous domaines et le serveur web? si vous avez un tuto veuillez donner le lien.
Merci
@Francis : En plus de la configuration de WordPress Mu, il faut configurer les serveurs de noms de domaine (DNS) avec un wildchar (« * » en guise de sous-domaine), tout comme le serveur web (généralement Apache). Concernant les DNS, cela ne peut se faire n’importe où. En effet, OVH ne permet pas cette fonctionnalité, par exemple. En revanche, Gandi le permet. Autrement, avec un serveur dédié, cela ne pose aucun souci (mais votre question me laisse entendre que vous n’en avez pas, ou du moins que vos compétences en administration de serveur ne sont pas suffisantes pour le faire).
@Martin : je dispose d’un serveur de test avec Fedora comme système et le serveur DNS et apache parfaitement configuré. J’ai un client qui voudrais bien qu’on lui fournisse une plateforme multi-blog à base de wordpress-mu et il voudrait qu’on déploie la solution chez un hébergeur tiers.
Voulez-vous donc dire que la meilleure solution pour déployer est un serveur dédié?
@Francis : Pour avoir du multi-domaine, il faut impérativement pouvoir avoir un wildchar dans le DNS, ainsi que dans Apache. Or, très peu d’hébergeurs permettent d’avoir les deux. Aussi, avoir une solution d’hébergement mutualisé avec des sous-domaines WordPress Mu est compromis. En revanche, on peut utiliser WordPress mu non pas en sous-domaine, mais en sous-dossier. C’est moins « classe », mais c’est faisable et compatible avec de l’hébergement mutualisé classique.
Ceci dit, gérer une plateforme de blogs WordPress Mu n’est pas évident et il est impératif que l’administrateur ait des compétences techniques. L’expérience m’a montré que même s’il est moins intéressant d’un point de vue utilisateur final, b2evolution semble plus facile à administrer en tant que plateforme de blogs, que ce soit en sous-domaine (avec les mêmes contraintes que WordPress Mu) qu’en tant que sous-dossier. À tester, donc, pour comparer.
@Martin : Merci pour tout vos conseils.
J’essaie de faire fonctionner WPMU avec Multisite manager mais impossible d’y arriver.
J’ai lu la doc, j’ai suivi les instructions aussi, toutes idées, tous conseils sont les bienvenus.
Merci
@Nikko : WordPress Mu ne gère pas les domaines en propre. Il faut effectivement passer par un plugin adapté. Ceci étant, j’ai moi-même rencontré de grandes difficultés à gérer les blogs sur des domaines différents via une telle configuration. Au final, j’ai cherché d’autres solutions, et la plus intéressante, à l’heure actuelle, est une installation de WordPress distincte installée et mise-à-jour via un script bash de mon cru.
Salut Nikko: ton commentaire sur ce billet m’a convaincu d’achever un billet entammé il y a près d’un an, qui traite du sujet et de mes difficultés à mettre wordpress MU en place. Maintenant, c’est stable, et ca « rocks »!
A lire ici:
http://blog.code-promo.com/wordpress-sur-plusieurs-noms-de-domaine/#5etapes
Werner.
Bonjour à vous. Depuis 1 semaine, je cherche la procédure pour le wildcat du serveur, et pour celle d’Apache. Après 6 millions de site et blogue sur le sujet, je me heurte à ce problème : tous ne font que copier le blabla d’un autre blogue, mais aucun ne donne cette procédure (surement parce qu’il ne la connait pas et qu’il veut qu’on croit qu’il la connait).
Alors, je suis sous Cpanel. J’ai une base en informatique. Où puis-je trouver un tuto détaillé sur le sujet, sans qu’il ne parle de blabla ovh ou free que je me caliss car je suis québécois.
Vous, Martin, le savez-vous comment faire ?
Si oui, pouvez-vous nous dire cette procédure svp ?
PS : mon domaine pointe déjà vers l’adresse IP de mon hébergement
@Blablababa : La procédure Cpanel m’est totalement inconnue, n’utilisant pas cet outil. En revanche, la procédure bind est simple, puisqu’il suffit d’éditer le fichier /etc/bind/db.nomdedomaine.tld et d’ajouter une ligne de type * IN A 999.999.999.999 où les séries de neuf indiquent l’adresse IP du serveur devant accueillir tous les sous-domaines du site. Pour la procédure Cpanel, il faudrait chercher ici.
Bonjour et merci pour ces explications claires..Et pour une fois qu’il y a quelqu’un qui donne des réponses !
J’ai pour ma part essayé de mettre WordPressMu sur un site mutualisé chez OVH, (en sous dossier..je sais c’est moins classe !) mais bon j’ai fait des test ça à l’air de fonctionner.
Par contre j’ai voulu mettre BuddyPress et là ça été la cata !
Bref ou que j’aille dans les forums, ont me dis sur OVH mutualisé pas possible !!!
J’ai été voir Gandi que vous citez…En fouillant sur leur site il y a une discussion qui m’interpelle et qui m’intéresse beaucoup :
« Question « Site chez OVH et BLOG chez Gandi », par daniel v.
Site chez OVH et BLOG chez Gandi, j’ai vue cette meme question partout, et Gandi repond dans la FAQ d’une maniere que personne ne comprend. Quelqu’un peu il m’aider?? ou faut il tout acheter chez OVH? merci
Réponse, par Rudy g. (Gandi)
Bonjour,
Si vous utilisez un hébergement OVH, et que vous souhaitez utiliser votre blog Gandi pour votre domaine, il vous suffit de rajouter un enregistrement CNAME dans votre fichier de zone.
Ainsi, si votre domaine utilise les DNS de Gandi, vous pouvez enregistrer la ligne suivante dans votre fichier de zone :
blog IN CNAME blogs.vip.gandi.net.
Si votre domaine n’utilise pas les DNS gandi, demandez à votre prestataire de rajouter cette ligne dans votre fichier de zone.
En faisant ainsi, votre blog sera accessible à l’adresse suivante :
blog.mondomaine.com
Cordialement,
– Rudy »
Ma question Martin : En lisant ceci, j’ai l’impression que je peux garder mon site sur OVH et concernant la partie WordPress Mu+ Buddy Press la mettre chez Gandi ??? Comme si je crée un sous-domaine chez Gandhi…Anis lorsque je fais monnomdedomaine.com, je suis sur OVH mai si je fais :
blog.monnomdedomaine.com je suis sur mon site wordpressMu chez gandi ??? pardonnez moi cette question de beotien, mais c’est ce que je souhaite faire….merci
@Patrick : Bonjour ! Vous pouvez tout à fait mettre en place ce type de configurations, en utilisant simplement les fonctionnalités DNS.
En effet, quand vous possédez un domaine, vous pouvez créer autant de sous domaines que vous voulez. Et pour faire pointer chacun d’eux au bon emplacement IP, il faut utiliser les enregistrements adéquats.
Par exemple, pour votre configuration, il suffit que le fichier de zone DNS de votre domaine contienne les enregistrements suivants :
@ IN A Adresse_IP_OVH
www IN A Adresse_IP_OVH
blog IN CNAME blogs.vip.gandi.net.
Patientez quelques heures pour la propagation DNS, et le tour est joué !
Cordialement,
—
Rudy
@Rudy : Pour éviter d’attendre le temps de la propagation, il suffit d’utiliser un wildchar (le caractère « * » ou étoile) en guise de sous-domaine dans les enregistrements DNS. Ainsi, tous les sous-domaines sont dirrigés vers le même serveur.
je gère aussi des dizaines de blogs sous WordPress et pour un nouveau projet je suis amené à installer WP MU (avec buddypress), je constate qu’on est encore loin de l’installation en 5 minutes de WordPress, comme d’habitude je commence par une installation en locale, sur OS X / MAMP, et là je dois changer les ports que j’utilisais pas défaut car WP MU ne fonctionne qu’avec le port 80 (du coup je vais devoir modifier à la main les bases de données de tout mes autre blogs en local) ensuite une fois que l’installation a réussi je me log et… impossible, pas de message d’erreur, je reviens simplement sur la page de login, comme si le mot de passe qui m’a été indiqué ne fonctionne pas… bref c’est bien galère pour un 31 décembre.
Seul inconvénient de wpmu c’est que les templates sont pas facile a trouver mais autrement c’est super pratique moi j’adhère a 200% en meme temps je sais pas s’il y a mieux en ce moment faut voir !
Bonjour Martin, j’essaye depuis quelques mois de faire fonctionner wordpress mu sur un mutualisé chez 1 and 1 mais en vain. L’installation se déroule correctement mais tous les liens buddypress ne fonctionnent pas. je ne sais pas comment modifier les dns, est-ce que vous pourriez m’aider à l’installer?
je ne sais plus quoi faire !
merci d’avance
Navré, jenny, mais je ne connais pas l’interface d’administration de 1and1 et je n’ai encore jamais installé BuddyPress.