Migrer WordPress vers une base mutualisée
Changer d’hébergement ne se fait pas tous les jours, mais lorsque cela arrive, il faut que cette migration soit la plus transparente possible pour les visiteurs et pour les contributeurs. Dans le cas de la migration d’un WordPress, ça peut être assez simple, mais il y a une ou deux astuces à connaitre.
Dad 3.0, c’est 3 blogs distincts sous WordPress (avec GeekGarage et Art of Dad). Vous avez peut être vu que j’ai récemment migré ces blogs. Je détaillerai dans un autre post le pourquoi, mais les contraintes d’hébergement se sont un peu resserrés. Les fichiers étaient évidemment dans des répertoire différents, quand aux données, elles étaient dans trois bases distinctes qui ont dût migrer vers une unique base mutualisée. En soi, ça ne gène pas, WordPress propose lors de l’installation de préfixer la base. Par défaut, il s’agit de wp_. Pour deux d’entre elles, j’ai laissé ce défaut.
Lorsque ces 3 bases WordPress doivent coexister dans une base MySQL, il faut que les trois préfixes soient différents. Si ils ne le sont pas, il y a une série de manipulations à faire.
Principe
Migrer un site ou un blog consiste à déplacer le contenu d’un serveur à un autre. Cette manipulation nécessitant un certain temps et certaines manipulations, la procédure consistera donc à copier le contenu du site en local afin de pouvoir appliquer quelques modifications, déplacer le contenu vers l’hébergement cible et configurer les paramètres pour que le visiteur se rende à ce nouvel hébergement. Durant cette phase, il faut s’assurer qu’aucun contenu ne sera ajouté sur l’ancien hébergement puisque celui sera perdu.
Procédure :
- Assurez-vous qu’aucun contenu ne soit ajouté, coupez donc les commentaires et si possible les contributions.
- Recopiez le contenu du site en local
- Faites un dump de la base en local
- Éditez tout ce qui doit être modifié
- Transférez le contenu vers l’hébergement cible
- Importez la base dans la base cible
- Testez que tout fonctionne…
- Rétablissez les redirections
- Vérifiez à nouveau que tout fonctionne
- Autorisez les contributions
J’ai mis trois petits points après testez que tout fonctionne, car avec WordPress, cette étape est un peu difficile. Pour faire un test, il vous faut une adresse de test et WordPress est un peu dépendant de l’adresse d’hébergement.
Cas le plus simple : migration vers un hébergement d’un blog unique
La migration d’un blog est assez simple, il suffit de suivre aveuglément la procédure ci-dessus en éditant dans le fichier de configuration WordPress les informations de connexion à la base de données. Ceux-ci sont déclarés dans le fichier wp-config.php et Il faut changer les valeurs suivantes.
/** Nom de la base de données de WordPress. */ define('DB_NAME', 'blog_base'); /** Utilisateur de la base de données MySQL. */ define('DB_USER', 'utlisateur'); /** Mot de passe de la base de données MySQL. */ define('DB_PASSWORD', 'mot_de_passe'); /** Adresse de l'hébergement MySQL. */ define('DB_HOST', 'localhost');
Il est possible, voir même probable qu’il vous faudra éditer le dump de la base de données si celui-ci contient une instruction de création et d’utilisation de base de données. Cette instruction ne passera pas chez un hébergeur mutualisé, supprimez la.
Cas où plusieurs blogs cohabitent dans une même base MySQL
La plupart des hébergeurs ne vous mettent à disposition qu’une seule base de donnée MySQL. Si cette base doit héberger plusieurs blogs WordPress, il faut que chaque blog retrouve ses tables. Heureusement, les développeurs de WordPress ont prévu le coup en permettant de préfixer les tables. Par défaut, WordPress propose wp_. Si vous avez changé ce préfix et qu’il n’est pas utilisé dans la base cible, alors vous n’avez rien à faire. Sinon, il vous reste un peu de travail.
Commencez par renommer les tables de la base. Il y a plusieurs moyens pour faire cela, le plus simple est d’éditer le fichier dump de a base de données en remplaçant tous les wp_. Personnellement, je le fait avec Vim, et si je souhaite remplacer wp_ par dad_, l’instruction est
:%s/wp_/dad_/gc
Le g indique que je souhaite remplacer touts les occurrences. Le c indique que je souhaite confirmer la substitution.
Il faut ensuite que WordPress sache utiliser ce préfix. Ceci est configuré dans le même fichier que les paramètres de connexion à la base, il faut donc modifier le paramètre suivant :
/** * Préfixe de base de données pour les tables de WordPress. * * Vous pouvez installer plusieurs WordPress sur une seule base de données * si vous leur donnez chacune un préfixe unique. * N'utilisez que des chiffres, des lettres non-accentuées, et des caractères soulignés! */ $table_prefix = 'wp_';
On a maintenant de quoi remonter un blog WordPress accessible par les visiteurs. Mais si vous essayez de vous y connecter en tant qu’administrateur, vous aurez ce désagréable message
You do not have sufficient permissions to access this page.
La raison est que WordPress utilise le préfix de la base de données pour certaines clefs en base… Ne me demandez pas pourquoi… Ces clefs sont dans deux tables, wp_usermeta et wp_options d’après leur nom standard, ici elles doivent maintenant se nommer dad_usermeta et dad_options. Il faudra donc aussi renommer ces clefs de wp_clef à dad_clef.
Pour wp_usermeta, il s’agit de :
- wp_capabilities
- wp_user-settings
- wp_user-settings-time
- wp_user_level
Pour wp_options, c’est :
- wp_user_roles
Attention, il peut y avoir d’autres clefs en fonction des plug-ins que vous avez installé. Et paradoxalement, certaines doivent bien commencer par wp_… Comment savoir lesquelles ? Le plus simple est de comparer avec une installation « propre ». Installez un blog de test avec un préfixe dédié, ajoutez les plug-ins que vous utilisez dans votre blog de production et comparez la base créée à la votre.
Une fois ces modifications effectuées, votre WordPress devrait être à nouveau pleinement fonctionnel.
À propos de... Darko Stankovski
iT guy, photographe et papa 3.0, je vous fais partager mon expérience et découvertes dans ces domaines. Vous pouvez me suivre sur les liens ci-dessous.
1 réponse
[…] publiant mon précédent article sur la migration d’une base WordPress, j’ai évidemment relayé le post sur Twitter en y ajoutant le tag CMS (Content Management […]