D.VDA

Ici, non pas 10 ni 15 extensions WordPress… mais une seule,  que j’ai testée, pour créer des sauvegardes automatiques de vos fichiers et de votre base de données.

Le plugin BackWPup est complet, simple d’utilisation, rapide de prise en main.

Bref, la qualité allemande. Pré-requis : WordPress 3.1 et PHP 5 minimum.

Démarrage rapide : vous pouvez configurer une seule sauvegarde qui va regrouper un dump de la base ainsi que tous vos fichiers ou ceux que vous aurez choisi (par exemple juste les fichiers à la racine + le répertoire wp-content). Vous configurez la périodicité de la sauvegarde automatique et choisissez où seront stockées ces backups. Au choix : sur le serveur, par email, sur un autre serveur via FTP, sur DropBox, SugarSync, Amazon S3, Google Storage, Microsoft Azure, RackSpace Cloud.

Je vous recommande simplement de tester un première sauvegarde pour vérifier que l’archive générée correspond bien à ce que vous attendez. Par exemple, dans le cas d’une sauvegarde sur le serveur et sur DropBox, l’archive sur le serveur sera synchronisée sur votre compte DropBox. Récupérez cette dernière et vérifiez son intégrité. J’ai eu des fichiers Zip corrompus sans en connaître la cause (côté PHP serveur, pendant le transfert ?..) mais aucun problème avec une archive tar.gz (utilisez 7Zip pour l’ouvrir, gratuit, sous Windows).

Une sauvegarde sur le serveur ainsi qu’une seconde via FTP ou sur un service d’hébergement dans le nuage sont un minimum. Si vous n’avez pas d’autre choix, une archive en pièce jointe envoyée sur votre compte Gmail peut aussi faire l’affaire quelques temps.

Ensuite il est possible d’affiner les réglages, fichiers à inclure et exclure, type de compression, tâches complémentaires d’export WP XML, d’optimisation ou de vérification des tables. Il est possible de sauvegarder sa base seulement chaque jour et ses fichiers juste le lundi par exemple… Un gestionnaire de sauvegardes récapitule vos backups sur les différents supports (local, DropBox, etc.) Il est aussi possible de recevoir le fichier de log par email, automatiquement, ou encore seulement en cas d’erreur.

Liste des fonctionnalités :

• Sauvegarde de la base de données
• WordPress XML Export
• Vérification/réparation/optimisation de la base de donnéese Database
• auvegarde des fichiers
• Compression aux formats : zip, tar, tar.gz, tar.bz2
• Stockage des sauvegardes sur le serveur
• Stockage des sauvegardes sur un serveur FTP distant
• Stockage des sauvegardes sur Amazon S3
• Stockage des sauvegardes sur Google Storage
• Stockage des sauvegardes sur Microsoft Azure (Blob)
• Stockage des sauvegardes sur RackSpaceCloud
• Stockage des sauvegardes sur DropBox
• Stockage des sauvegardes sur SugarSync
• Envoi des sauvegardes par email
• Envoi du fichier de logs (journal des opérations) par email

Hébergement OVH mutualisé

Vous pouvez être confronté à un problème de ressources en offre mutualisée. Si vous tentez de sauvegarder tous les fichiers de votre blog, cela peut rapidement s’avérer très lourd, bref, le script risque de s’arrêter en route. Créez plusieurs tâches à différentes périodes si besoin est.

Côté sauvegarde sur le serveur, sur les offres actuelles (mais aussi les anciens 90Plan et compagnie) vous pouvez créer un répertoire à la racine de votre espace FTP, hors d’accès par le Web. Voilà qui devrait donner un peu plus d’utilité aux dizaines de Gigas de stockage inutilisées.

Site de l’auteur et page WordPress.org :

• http://backwpup.com/
• http://wordpress.org/extend/plugins/backwpup/

 

Avertissement

Cet article décrit le processus de mise à jour que j’ai suivi pour mettre à jour une version de CMSMS 1.6.6 vers la dernière en date à ce jour, CMSMS version 1.11.4.

Tout se passe sur une copie du site de départ qui a été mise en ligne sur une autre adresse (utilisation d’un sous-domaine). L’hébergeur est OVH, offre mutualisée Perso.

Il existe un guide (en anglais) décrivant la mise à jour d’une ancienne version.

Comme toujours, vous avez fait des sauvegardes et vous procédez à une mise à jour sur un site de test, comme moi, car vous aimez dormir la nuit.

C’est parti

Pré-requis

• BACKUP des fichiers et de la base
• PHP 5.3.x => la configuration minimale requise est la version PHP 5.2.4 recommandé PHP 5.2.12

Mise à jour

• htaccess : PHP 5.2.17 (OVH)
• Mettre à jour tous les plugins
• vider le répertoire tmp/templates_c
• Passer le site en MAINTENANCE
• htaccess : PHP 5.2.17 OK, mais PHP 5.3.2 ou plus est recommandé pour des problèmes de compatibilité avec les modules tierces parties
• htaccess : ajouter en début de fichier SetEnv PHP_VER 5_3
• htaccess : avec OVH, ne pas changer php_flag register_globals Off comme indiqué dans la procédure d’upgrade
• upload nouvelle version CMSMS
• Avant la mise à jour, le répertoire d’admin, s’il a été renommé, doit être « admin »
• SITE/install/upgrade.php

Erreurs rencontrées

• Avec SetEnv PHP_VER 5_3 -> on rencontre l’avertissement E_DEPRECATED is enabled dans le processus de MAJ
• Checking PHP register globals – PHP register globals is active. For security reasons, this should be disabled. Bon, ça nous empêche pas de dormir.
• Notez que PHP 5.2.17 est compatible, on pourrait en rester là. Mais bon, on met à jour ou bien ? On réessaye avec PHP 5.2 (modification de .htaccess et reload de la procédure de MAJ). Bon, si on a pas les erreurs maintenant on les aura plus tard, allez retour à htaccess : SetEnv PHP_VER 5_3, version de PHP qu’on gardera par la suite, donc autant s’y faire.

Note : A l’étape 6 script de mise à jour, nous avons de nombreuses erreurs. Pas vous ?

On continue. Si vous avez, à très juste titre, modifié le nom du répertoir d’admin TOTO : renommez-le admin_OLD et renommez le nouveau répertoire d’admin tel que vous l’avez mis dans le fichier de configuration (TOTO donc).

On se loggue dans l’interface d’aministration, et là, plein d’erreurs apparaissent en haut de page. C’est là qu’on se dit qu’il aurait peut-être mieux valu RTFM :

"If your current version is version 1.6.7 and you wish to upgrade to 1.10.1,
you should at a minimum upgrade to version 1.7, then to version 1.8, 1.9,
and finally version 1.10.1..."

• CGExtensions  : Mettre à niveau -> (affichage sans CSS), puis disparition des erreur. Visiblement c’est CGExtensions qui ne supporte pas le saut de 3 ou 4 générations de versions.
• FormBuilder :  Mettre à niveau
• MenuManager : Mettre à niveau
• SiteMapMadeSimple : Mettre à niveau
• TinyMCE : Mettre à niveau
• (Bref, mettre à jour tous les modules)
• Désactiver le mode Maintenance
• Vider le cache

Vérifications

• Problème avec le formulaire de contact (FormBuilder) lorsqu’on le valide : « The following From address failed ». Ah.
• Vérification du module CMSMailer. Méthode d’envoi des emails : SMTP (!) à changer par : Mail -> OK. Ehéh.
• Facultatif : Par la même occasion, remplacer Adresse de l’expéditeur : avec la bonne adresse (et pas root@localhost par défaut)
• Facultatif :Remettre l’email du propriétaire du site (à la place de votre adresse Gmail de test…)
• Pas facultatif (mais ça dépend de vous) : Tiens, un problème avec un truc obsolète, les assignations de variables  de bloc de contenu du genre : {content block= »monbloc » assign= »lebloc »} ben ça marche plus….

Sympa : la solution générale avec la documentation sur les Content block (en english) !

Il faut assigner les variables en début de template pour s’en servir plsu tard (une ou plusieurs fois dans problème), c’est vrai que c’e'st plus propre comme ça.

{content block=price label="Prix du produit" wysiwyg="false" assign=leprix}
 <!-- Only show content block when it has some content -->
 {if $leprix}
 {$leprix}
 {/if}

Sécurisation

Et oui, c’est pas WordPress, mais on va quand même essayer de sécuriser un peu l’install après le mal qu’on s’est donné.

Documentation en anglais : http://docs.cmsmadesimple.org/general-information/securing-cmsms

Les trucs de base

• Lire le fichier INSTALL.TXT et autre README sur les droits des répertoires et fichiers
• Supprimer le répertoire /install
• Renommer le répertoire d’administration
• Et donc, modifier son dans le le config.php
• htaccess : décommenter les 2 lignes suivantes si le serveur le permet.

  # (this is important, so uncomment if your host permits)
  #Options -Indexes
  #ServerSignature Off

Modules pour sécuriser CMSMS

Pas testé, vous me direz

Mail UDT : pour recevoir un email lorsqu’une tentative de connexion à l’administration échoue.
CGSmartImage : masque l’arborescence des répertoires et ajout un watermark sur les images (?)

Balises utilisateur (tag) pour sécuriser CMSMS

Création d’un l’UDT (User Defined Tag : balise utilisateur) pour tracer l’évènement « LoginFailed » et recevoir par mail le login et l’adresse IP (miam) du petit rigolo qui essaye de rentrer.

$cmsmailer = cms_utils::get_module('CMSMailer');
 // Receiver
 $cmsmailer->AddAddress('admin@website.com','Name');
 // Sender
 $cmsmailer->SetFrom('noreply@website.com');
 $cmsmailer->SetFromName('CMS Website.com');
 // Subject
 $username = $_SESSION['login_user_username'];
 $ipaddress = cms_utils::get_real_ip();
 $cmsmailer->SetSubject('Failed login: ' . $username . ' ' . $ipaddress);
 // Content
 $content = 'There has been a failed login in your admin panel!';
 $cmsmailer->SetBody($content);
 $cmsmailer->IsHTML(true);
 // Send mail
 $cmsmailer->Send();

Ou encore Ban IP-address UDT, pour banir une adresse IP. Voir le code :

$banned = array ("xxx.xxx.xxx.xxx","yyy.yyy.yyy.yyy","zzz.zzz.zzz.zzz");
 $ipaddress = cms_utils::get_real_ip();
 if (in_array($ipaddress, $banned))
 die ("You are banned from this website!");

Et ajouter en début de template : {ip_ban}

Autres sources de documentation :

http://wiki.cmsmadesimple.fr/wiki/Maj_cmsmadesimple_localhost
http://jc.etiemble.free.fr/abc/index.php?page=ressourcesfr
http://www.cmsmadesimple.fr/forum/viewtopic.php?id=4814

Limiter les risques au maximum, mettre à jour (un vieux) WordPress et son hébergement, sécuriser et prendre de bonnes habitudes.

Avant toute chose, si vous recherchez uniquement le mode d’emploi pour une mise à jour de WordPress, toute l’information nécessaire est ici :

• http://codex.wordpress.org/fr:Mettre_a_Jour_WordPress
• http://codex.wordpress.org/fr:Details_de_mise_a_jour

L’article suivant traite de la mise à jour d’un blog WordPress d’une assez ancienne version vers la dernière en date, cela en changeant par la même occasion d’hébergement Web. Dans mon cas, le précédent hébergement n’était plus compatible avec les dernières versions de WordPress nécessitant PHP 5.2.4 minimum.   afin de pouvoir bénéficier d’une version de PHP plus récente par exemple – WordPress 3.5.1 nécessite PHP 5.2.4 minimum -

Si vous estimez que votre hébergement actuel fait parfaitement l’affaire et est suffisamment à jour, vous devez néanmoins être en mesure de créer plusieurs sites dans votre interface d’administration. Je n’ai pas d’intérêts chez OVH, mais leur plan d’entrée de gamme permet de faire tout cela (multi-sites).

Avant toute chose :

• Sauvegardez votre base de données,
• Sauvegardez TOUS vos fichiers WordPress, y compris le fichier .htaccess (en anglais) si vous en avez un,
• Vérifiez que les sauvegardes que vous avez créées sont disponibles et utilisables.

Travailler sur une copie du site

Le principe de cette méthode consiste à ne pas mettre à jour votre blog. Nous n’allons pas y toucher et travailler uniquement sur sa copie, qui deviendra la future version du site. Le site WWW reste en ligne tant que le site TEST n’est pas parfaitement opérationnel. Ensuite, on modifiera la zone DNS du nom de domaine pour faire pointer le WWW vers la nouvelle version.

Création d’une copie du site sur un sous-domaine de test, en pré-production

L’ancien site est laissé en ligne sans aucune modification. Dans et exemple, le nouvel hébergeur est OVH, sur un simple plan mutualisé permettant le multi-domaines.

WordPress 3.5.1 nécessite PHP 5.2.4 minimum
http://wordpress.org/about/requirements/

Dans notre cas, il s’agissait du passage d’un hébergement avec une vieille version de PHP 5.2.0.x vers un autre en PHP 5.4.6. La non-compatibilité des dernières version de  WordPress avec notre version de PHP justifie le changement (pas le choix), mais un changement d’hébergement est une question à laquelle il faut réfléchir pour bien mesurer les avantages et les inconvénients.

Par exemple notre hébergement en question permet d’utiliser plusieurs de version de PHP au choix, dont la dernière en PHP 4 et pour la plus récente, PHP 5.2.4. Les serveurs de bases de données disponibles permettent eux aussi de choisir une version de MySQL. Il est même possible de commander d’autre types de BDD. En gros c’est flexible. L’espace d’hébergement est pléthorique, on a des boîtes mail à gogo, des dizaines de fonctionnalités pratiques et c’est pas cher…

A ce stade, vous avez effectué une sauvegarde complète des fichiers et de la basse de données de votre blog. Si ça n’est pas encore fait et que vous plantez votre site, ce qui arrive généralement comme une averse quand on sort sans parapluie, on vous aura prévenu.

Mise en place du 2ème site

1. Un sous-domaine de test – test.nomdedomainedublog.com – est créé qui va pointer vers le répertoire sur votre hébergement, par exemple /www/nomdedomainedublog.com.
2. On met en ligne la copie du site (upload via FTP) en ayant pris soin auparavant de modifier le fichier wp-config.php en y renseignant les paramètres de la nouvelle base de données.
3. Parallèlement, le dump de la base de données est importé. Il y aura juste à éditer la table wp_options où l’URL de votre blog (en www) www.nomdedomainedublog.com devra être remplacée par la nouvelle URL de test test.nomdedomainedublog.com.

Si vous ne vous êtes pas planté quelque part en route, le site test.nomdedomainedublog.com, copie conforme de www.nomdedomainedublog.com, est prêt à fonctionner.

Note pour OVH : il est possible que par défaut votre hébergement soit encore en PHP 4, pour choisir votre version de PHP il suffit de créer un fichier .htaccess à la racine et d’y écrire la ligne de votre choix, comme indiqué dans le guide.

• pour PHP 5.2 :

  SetEnv PHP_VER 5

• pour PHP 5.3 :

  SetEnv PHP_VER 5_3

• pour PHP 5.4 :

  SetEnv PHP_VER 5_4

Etape de mise à jour du blog

Inutile de le réécrire en moins clair, l’essentiel est ici :

• http://codex.wordpress.org/fr:Mettre_a_Jour_WordPress
• http://codex.wordpress.org/fr:Details_de_mise_a_jour

Vous pouvez sauter la partie sauvegarde et directement reprendre à partir de : Désactivez TOUTES vos extensions. Revenez quand c’est prêt. Notre mise à jour de WordPress 1.5.2 vers 3.5.1 n’a pas rencontré de problème en mode automatique chez notre hébergeur. Il est possible en fonction du vôtre que vous aillez à accomplir cetet dernière manuellement, c’est expliqué dans la documentation.

Que faire après la mise à jour ?

Vérifiez que vous ayez bien suivi les dernières recommandation :

• Etape 10 : Mettre à jour les Permaliens et les fichiers .htaccess
• Etape 11 : Installer les extensions et les thèmes mis à jour
• Etape 12 : Réactiver les extensions

A vous les nouvelles fonctionnalités et les dernières extensions ! A ce propose, je ne saurais vous recommander d’installer uniquement les extensions qui vous sont vraiment utiles, pour éviter la surcharge, celles qui ne sont plus suivies et mise à jour, etc. Mais après tout on s’en fout on les supprimera après, c’est le moment de faire des essais, avec notre nouvelle copie de Test ? Youpi !

Et pourquoi pas sécuriser votre WordPress ?

Ok, vous vous dites que votre tête n’est pas mise à prix chez les hackers, pourquoi vous et votre petit blog, etc. C’est encore plus simple que cela, votre blog sera piraté s’il n’est pas mis à jour et sécurisé, non pas par un tueur à gage ayant reçu un contrat sur vous mais par tout un éventail de personnes susceptibles de le faire par curiosité, désœuvrement ou intérêt (un morveux qui s’amuse, un BlackHatSEO pas sympa, ou le Service Marketing d’une organisation criminelle quelconque).

Vous n’êtes visé, mais les ressources accessibles via votre site le sont. Il y a de fortes chances que votre « pirateur » s’en tape parfaitement de vous et ne connaisse même pas le nom de votre blog qui est un parmis d’autres  dans un fichier Excel de blog vulnérables. C’est le contrôle de nombreux sites grâce à l’exploitation de failles documentées et publiées qui est l’enjeu.

Quelques extensions intéressantes :

• Better WP Security
• WordPress Security Scan
• WP Plugin Security Check

Ces plugins proposent de très nombreuses customisation de WordPress afin d’en améliorer la sécurité. Ici encore, vous pouvez tout tenter sur votre site de test.

Passage en prod : www

Voilà, votre version de test est parfaitement à jour, vous avez trouvé des plugins intéressants, fait vos essais, installé les extensions de sécurisation et paramétré leurs options, tout est OK. Il ne reste qu’à passer en production sur www.nomdedomainedublog.com.

1. Changez l’adresse du blog dans les réglages de WordPress : test.nomdedomainedublog.com -> www.nomdedomainedublog.com
2. Procéder à la même vérification dans les paramètres de toutes les extensions qui pourraient utiliser la valeur de l’URL en dur…
3. A partir de là, votre site de test.nomdedomainedublog.com s’affichera encore mais tous les liens pointeront vers www.nomdedomainedublog.com (l’ancien blog pour l’instant).
4. Modifiez la zone DNS en faisant pointer WWW vers votre nouvel hébergement
   Chez OVH, vous aurez créé un multidomaine test.nomdedomainedublog.com, il vous suffira de créer le multidomaine www.nomdedomainedublog.com pointant vers le même répertoire
5. Attendez le délais de mise à jour des serveurs DNS…

Pour terminer : faire des sauvegardes régulières, mettre à jour très régulièrement WordPress et ses extensions.