« Raccourcis claviers dans WordPress :: Migration accomplie »
Les versions de WordPress pleuvent en ce moment, la 2.0.7 pour des raisons de sécurité, la 2.1 en Release Candidate. Mais la question la plus importante c’est comment déployer WordPress à chaque nouvelle version ? Quelle est la meilleur solution pour un site productif ? Par site productif, j’entends bien évidement un site accessible à des utilisateurs, ça n’a aucun rapport avec le contenu ou la fréquence de mise à jour…
Il existe une méthode qui a fait ses preuves depuis de nombreuses années, à l’époque où peu de sites n’utilisaient de langages tels que PHP. Charger les fichiers à mettre à jour via votre client FTP favoris en remplaçant les anciens. Le problème c’est que le temps de transfert n’est toujours pas immédiat. Donc pendant que vous allez transférer vos fichiers, vos utilisateurs vont utiliser une application avec des bouts de code de versions différentes et là c’est le drame. Soit vous avez de la chance et tout fonctionne, soit le site plante avec une erreur PHP et votre visiteur vous prend pour un charlot, soit tout semble fonctionner pour lui et vos données deviennent incohérentes dans la base. Bref ce n’est pas la meilleur solution si vous avez un peu de trafic sur votre site. Sinon utilisez la plage de 2 heures lorsque personne ne visite votre site (souvent entre 2h et 4h du matin).
Une autre méthode consiste à rediriger toutes les visites vers une page indiquant que pour des raisons techniques et/ou de maintenance le site est indisponible pendant quelques temps, le temps pour vous de mettre à jour tous les scripts, de mettre à jour la base de données et de vérifier que tout s’est bien passé. Malheureusement pendant ce temps, les visiteurs peuvent se décourager et ne pas revenir si le temps de maintenance est trop long ce qui est souvent le cas pour les visites depuis un moteur de recherche.
La méthode que je vous propose devrait vous permettre de réduire considérablement le temps d’indisponibilité lors d’une mise à jour majeure.
La première chose à faire est de tester la nouvelle version en local pour s’assurer que tout va fonctionner. C’est évident mais comme ça va sans dire, c’est toujours mieux en le disant. C’est la phase de qualification (pour les pros).
Procédure de déploiement d’une nouvelle version de WordPress :
<?php /* Short and sweet */
define('WP_USE_THEMES', true);
require('./v2/wp-blog-header.php');
?>v2 doit correspondre au nom du répertoire qui contient la nouvelle version.
C’est fini. De plus de cette façon, vous avez placé la nouvelle version wordpress dans son propre répertoire ce qui a pour vertu de l’isoler du reste de votre site. Avantage : seule l’étape 3 étant cruciale, vous pouvez préparez les autres étapes sur des mois.
Vous me direz qu’entre les étapes 3.1 et 3.2, vous allez vous retrouvé dans la situation de la méthode bourrin où la version précédente manipule un modèle de données différent de celui pour lequel elle a été construite. Certes rien ne vous empêche de passer par l’astuce du malin et de rediriger vos visiteurs vers un page de maintenance en indiquant de revenir dans la seconde, mais le temps de bascule est réduit à son minimum. Cette opération ne doit pas vous prendre plus de quelques secondes, soit le temps de passer de votre navigateur à votre client FTP.
A moins que vous ne fassiez cette opération depuis une ligne GSM…
Si j’ai bien compris :
- l’ancien blog va fonctionner avec les templates du nouveau
- c’est la connexion au nouveau blog et la mise à jour de la base , qu’il faut préciser , il n’y a pas encore eu d’installation du nouveau
blog ( que des transfert FTP )
- comment a lieu cette connexion ?
@+
L’ancien blog ne peut a priori jamais tourné avec les templates du nouveau.
Soit ça tourne dans une version, soit dans l’autre (en terme d’applicatif). Il s’agit uniquement des données qui sont utilisées (articles, pages, options…)
Il n’y a pas d’installation du nouveau blog, puisque l’on utilise la même base de données et les mêmes tables.
L’activation de la nouvelle version se fait à la dernière étape, en chargeant le bon fichier index.php car c’est lui qui indique quelle version de WordPress il faut exécuter.
Je n’ai pas encore fait la bascule entre 2 versions de wordpress , mais j’ai lu :
- que avec le ftp il fallait copier les nouveaux fichiers sur les anciens en gardant la base
- est ce correct ?
- qu’une mise à jour automatique est possible depuis la version 2.1
J’ai la 2.2 et je ne sais pas encore ce qui est le mieux pour la suite …
@+
Effectivement, s’il s’agit d’une simple mise à jour de l’applicatif WordPress. Ecraser les fichiers par FTP est souvent suffisant.
C’est la méthode 1 et elle marche.
Pour la mise à jour automatique, je ne sais pas mais je me méfie de ce qui est automatique.
Le passage par ftp d’une version 2.0.xx vers 2.2 , s’est bien passé .
Avant que le blog s’affiche il y a eu une maj de la base et le résultat est parfait .
J’ai maintenant 2 blog en version 2.2 , et comment migrer la base , du plus complet vers le vide
- les pages et articles
- la blogliste
J’ai 2 bases
J’ai cette erreur sql :
requête SQL :
INSERT INTO wp_categories
VALUES ( 1, ‘Non classé’, ‘non-classe’, », 0, 0, 0, 0, 0 )
MySQL a répondu:
#1062 – Duplicate entry ’1′ for key 1
Le passage d’une base vers l’autre a réussi avec un export sql :
- nouveau prefix de table
- recherche / remplacer blog1/ par blog2/ (*)
La sidebar de blog2 renvoyait sur blog1 et impossible de se connecter à blog2
Il a fallu retoucher à la main dans la table wp_options , l’adresse fixe du blog (*) , qui n’est pas passé ( pas de / codé )
Donc finition avec phpmyadmin à la main . La base de wp 2.2 a malgré tout atteint une très bonne fiabilité .
1. Il ne fallait pas créer une seconde base.
2. C’est un problème d’auto increment dans la table
3. En ne gardant qu’une seule base, ces opérations ne sont pas nécessaires
Un dernier post qui n’a pas d’écho sur le forum de wp ( de ‘ ouf ‘ ):
http://www.wordpress-fr.net/support/sujet-6283-flux-rss