Réi­ni­tia­li­ser WordPress : méthodes et conseils

WordPress est le système de gestion de contenu (Content Ma­na­ge­ment System ou CMS) le plus utilisé au monde. Le recours à WordPress facilite la cons­truc­tion d’un site Web. À partir d’un vaste choix de plugins (nommés « ex­ten­sions » dans WordPress) et de thèmes, vous pouvez composer la fonc­tion­na­lité souhaitée et l’aspect approprié. Cinq minutes suffisent pour mettre en ligne son propre site.

Malgré sa sim­pli­cité apparente, on peut ra­pi­de­ment perdre le fil lors de la création d’un site WordPress. Le site ne se charge plus cor­rec­te­ment ou n’est plus du tout en mesure de fonc­tion­ner. Parvenu à un certain point, on en a assez et l’on ne souhaite plus qu’une seule chose : réi­ni­tia­li­ser le site WordPress pour prendre un nouveau départ. Quelles options sont proposées pour réi­ni­tia­li­ser WordPress et à quel moment ceci s’impose ?

WordPress est un système de gestion de contenu (Content Ma­na­ge­ment System ou CMS). La souplesse du logiciel permet de créer des sites et des ap­pli­ca­tions com­plè­te­ment dif­fé­rents sur la base du CMS. Vous trouverez des plugins adaptés pour pra­ti­que­ment chaque projet, qu’il s’agisse d’un single page scroller, d’une boutique en ligne ou d’un réseau social. La souplesse ca­rac­té­ris­tique de WordPress est cependant une bé­né­dic­tion et une ma­lé­dic­tion à la fois. C’est au plus tard après s’être embourbé dans une jungle de plugins in­com­pa­tibles que l’on aimerait tout annuler en appuyant sim­ple­ment sur un bouton de réi­ni­tia­li­sa­tion.

Même dans le contexte de l’ad­mi­nis­tra­tion courante d’un site WordPress, il est parfois utile de pouvoir réi­ni­tia­li­ser au moins des parties d’un site WordPress. La plupart du temps, le besoin se pose lorsqu’il est prévu d’apporter des chan­ge­ments majeurs au site. Quelques scénarios fréquents se pré­sen­tent où il est re­com­mandé de réi­ni­tia­li­ser WordPress. Il s’agit notamment de migrer un domaine WordPress chez un nouveau four­nis­seur d’hé­ber­ge­ment (migration), de la refonte du site (re­con­cep­tion) ou de re­dé­mar­rer le site sous le domaine existant (relance).

Certaines cir­cons­tances imposent également de réi­ni­tia­li­ser un site WordPress : par exemple, si le site a été piraté ou ne se charge plus après une mise à jour (res­tau­ra­tion/ré­cu­pé­ra­tion). Parfois, il est également utile de réi­ni­tia­li­ser des parties de WordPress dans le cadre d’un « nettoyage de printemps ». La sup­pres­sion à in­ter­valles réguliers des éléments hérités épars et superflus renforce la sécurité du site et peut con­tri­buer à rendre WordPress plus rapide.

La réi­ni­tia­li­sa­tion s’avère par­ti­cu­liè­re­ment utile dans les flux de travail de dé­ve­lop­pe­ment et de test. D’une manière idéale, on utilise à ce stade un site de pré­pro­duc­tion ou de dé­ve­lop­pe­ment local. On n’a pas à se soucier ainsi des dommages éventuels.

Qu’est-ce que cela signifie quand nous parlons de réi­ni­tia­li­ser WordPress ? En fait, cela peut signifier plusieurs choses. Parce que WordPress se compose de quatre com­po­sants de base :

1. Dossiers et fichiers WordPress Core
2. Fichiers de con­fi­gu­ra­tion WordPress
3. Base de données WordPress
4. Données du site WordPress dans le dossier wp-content

Si vous voulez réi­ni­tia­li­ser WordPress, vous devez avoir cerné pré­ci­sé­ment vos objectifs. Voulez-vous supprimer uni­que­ment le contenu ou voulez-vous réi­ni­tia­li­ser les pa­ra­mètres ou le thème WordPress à son état d'origine ? Le site a-t-il été piraté ou déplacé ? Selon le scénario, il peut être né­ces­saire de réi­ni­tia­li­ser dif­fé­rents com­po­sants du site.

Il est important de com­prendre que les com­po­sants sont imbriqués. Par exemple, si vous supprimez uni­que­ment la base de données, les plugins, les thèmes et les fichiers chargés sur le serveur (té­lé­char­ge­ments) sont conservés. Cependant, les té­lé­char­ge­ments ne figurent plus dans la mé­dia­thèque WordPress en raison de la perte de la base de données. Vous ne pouvez donc plus les supprimer de WordPress. Dans ce cas, il serait judicieux de réi­ni­tia­li­ser le dossier de té­lé­char­ge­ments WordPress.

« WordPress Core » désigne les dossiers et les fichiers qui composent le « noyau » de WordPress. Ceux-ci sont créés lors de l’ins­tal­la­tion de WordPress et modifiés si né­ces­saire pendant les mises à jour. Les dé­ve­lop­peurs WordPress d’iThemes sont les auteurs d’une dé­fi­ni­tion éclai­rante :

Examinons à titre d’exemple les noms des fichiers et dossiers du noyau de WordPress dans le ré­per­toire racine de WordPress. En tant qu’uti­li­sa­teur, veillez à ne pas toucher à ces dossiers et fichiers, faute de quoi l’ins­tal­la­tion de WordPress pourrait être fa­ci­le­ment en­dom­ma­gée :

• index.php
• wp-login.php
• wp-admin/
• wp-includes/
• etc.

La réi­ni­tia­li­sa­tion est utile quand le noyau WordPress est endommagé. Le noyau de WordPress est ha­bi­tuel­le­ment endommagé par un accès inap­pro­prié de l’uti­li­sa­teur ou par l’intrusion de logiciels mal­veil­lants. Si le noyau de WordPress a été modifié à l’issue d’un piratage, il est pré­fé­rable de re­cons­truire le site de bout en bout à partir d’une sau­ve­garde. Cela permet de tordre le cou à cet élément nuisible.

Les fichiers de con­fi­gu­ra­tion de WordPress sont une poignée de fichiers qui sont stockés dans le ré­per­toire racine de l’ins­tal­la­tion de WordPress. Ils con­sig­nent des pa­ra­mètres de con­fi­gu­ra­tion spéciaux en dehors de la base de données. Les fichiers de con­fi­gu­ra­tion WordPress suivants se re­trou­vent dans la plupart des ins­tal­la­tions WordPress :

Les mo­di­fi­ca­tions apportées aux fichiers de con­fi­gu­ra­tion de WordPress en­dom­ma­gent ra­pi­de­ment le site. Ces dommages ont souvent des ré­per­cus­sions im­mé­diates ; le site ne se charge plus cor­rec­te­ment ensuite. Cependant, des dommages plus subtils peuvent aussi se produire, qui ne de­vien­nent per­cep­tibles qu’au terme d’une période prolongée : par exemple lorsque le clas­se­ment Google du site plonge dans les abîmes.

Si les fichiers de con­fi­gu­ra­tion de WordPress ont été en­dom­ma­gés, il est vivement re­com­mandé de les restaurer à partir d’une sau­ve­garde. Si vous essayez d’analyser les dommages et de les réparer ma­nuel­le­ment, vous risquez de les aggraver. Dans ce cas, il est possible de restaurer un fichier de con­fi­gu­ra­tion WordPress endommagé à son état d’origine. Tous les pa­ra­mètres spé­ci­fiques au site seront toutefois perdus lors de cette opération.

La base de données WordPress contient la plupart du contenu du site et des pa­ra­mètres de con­fi­gu­ra­tion. Ils sont stockés dans des tables de base de données in­di­vi­duelles. Deux types de tables de base sont utilisés ici :

1. Tables du noyau WordPress, dont :
   • wp_posts
   • wp_options
   • wp_users
   • wp_comments
2. Tables de plugins et thèmes
   • Leur nom exact dépend du plugin ou du thème respectif.

Si vous supprimez des parties de la base de données, ceci peut éven­tuel­le­ment agir sur WordPress comme une réi­ni­tia­li­sa­tion. Notez qu’il existe deux méthodes pour réi­ni­tia­li­ser la base de données WordPress :

1. Supprimer les entrées de la base de données (DELETE * FROM <table>)
2. Supprimer les tables de base de données (DROP TABLE <table>)

Il est essentiel de créer une sau­ve­garde de base de données (« database dump ») avant de modifier la base de données WordPress. Gé­né­ra­le­ment, un vidage de base de données génère un fichier texte compressé avec une ins­truc­tion SQL. Le vidage de la base de données est remis en jeu pour rétablir un état antérieur de la base de données WordPress. Les ins­truc­tions SQL contenues sont exécutées de manière sé­quen­tielle et les données sont re­cons­ti­tuées.

Un piège est tendu lors de la res­tau­ra­tion de la base de données WordPress après la réi­ni­tia­li­sa­tion : si uni­que­ment des entrées in­di­vi­duelles ont été sup­pri­mées lors de la réi­ni­tia­li­sa­tion, le vidage de la base de données doit avoir été exporté avec les entrées DROP TABLE IF EXISTS. La res­tau­ra­tion est condamnée à l’échec en cas contraire.

Con­trai­re­ment au noyau de WordPress, les données du site évoluent au fil du temps. Les données du site englobent tous les dossiers et fichiers du dossier wp-content. Penchons-nous sur les dossiers prin­ci­paux avec leurs chemins relatifs :

• Données du site : wp-content/
  • Ex­ten­sions ins­tal­lées : plugins/
  • Thèmes installés : themes/
  • Fichiers té­lé­char­gés : uploads/

Chaque plugin et thème figure dans un dossier propre. Si vous supprimez l’un de ces dossiers, le thème ou le plugin cor­res­pon­dant sera supprimé. Cependant, les tables et les entrées sont con­ser­vées dans la base de données WordPress. Quand on supprime le dossier wp-content complet, on réi­ni­tia­lise les données du site WordPress. On peut alors re­com­men­cer à installer des plugins et des thèmes depuis le début.

Trois approches prin­ci­pales existent pour réi­ni­tia­li­ser un site WordPress. Nous les examinons plus en détail à la suite :

1. Réi­ni­tia­li­ser WordPress ma­nuel­le­ment
2. Réi­ni­tia­li­ser WordPress à l’aide de plugins
3. Réi­ni­tia­li­ser WordPress avec WP-CLI

De nombreux guides de réi­ni­tia­li­sa­tion de WordPress dis­sé­mi­nés sur la toile pré­co­ni­sent une méthode manuelle avec un certain nombre d’étapes in­di­vi­duelles. On manipule ici le serveur ou le back-end de l’en­vi­ron­ne­ment d’hé­ber­ge­ment. Il s’agit de supprimer des fichiers et des dossiers de manière ciblée, et de modifier les pa­ra­mètres de con­fi­gu­ra­tion de l’ins­tal­la­tion de WordPress et de l’en­vi­ron­ne­ment d’hé­ber­ge­ment. On ajuste les pa­ra­mètres DNS, crée une nouvelle base de données ou supprime des tables dans la base de données existante. On peut faire appel à des scripts spéciaux si né­ces­saire.

Dans la plupart des cas, la méthode manuelle n’est pas la meilleure façon de réi­ni­tia­li­ser un site WordPress. Il est gé­né­ra­le­ment plus facile de créer une nouvelle ins­tal­la­tion propre de WordPress. Car à l’issue d’une réi­ni­tia­li­sa­tion complète, un site WordPress ne doit présenter aucune dif­fé­rence avec un site WordPress nou­vel­le­ment installé dans un cas de figure idéal.

La méthode manuelle est l’approche la plus puissante et permet de réi­ni­tia­li­ser des parties de WordPress avec une précision chi­rur­gi­cale, à condition de disposer du savoir-faire approprié. Car en l’absence des con­nais­sances et de l’ex­pé­rience requises, on peut ra­pi­de­ment détruire le site. Par con­sé­quent, il faut im­pé­ra­ti­ve­ment créer une sau­ve­garde avant de s’atteler à la tâche. Il serait encore mieux de tra­vail­ler sur un site de pré­pro­duc­tion WordPress Staging. Examinons quelques scénarios dans lesquels l’approche manuelle entre en jeu.

Imaginons de disposer d’un site WordPress existant sous le domaine www.example.com. Nous sou­hai­tons commencer avec un WordPress vierge dès le début. Nous voulons évi­dem­ment maintenir le domaine existant et l’autorité du moteur de recherche associé. Une approche com­mu­né­ment adoptée consiste à réi­ni­tia­li­ser le site WordPress existant et à le re­cons­truire ensuite sous le domaine existant. Mal­heu­reu­se­ment, cette approche est fondée sur une erreur de jugement.

Rappelons-nous ceci : une réi­ni­tia­li­sa­tion complète ne doit pas pouvoir se dis­tin­guer d’un site WordPress fraî­che­ment installé en théorie. Par con­sé­quent, il vaut mieux installer une version vierge de WordPress et con­fi­gu­rer ensuite le domaine existant sur la nouvelle ins­tal­la­tion. Pour ce faire, on ajuste les pa­ra­mètres DNS dans le back-end d’hé­ber­ge­ment ou auprès du bureau d’en­re­gis­tre­ment du domaine pour relier celui-ci à l’adresse IP du serveur. On adapte ensuite l’URL du site WordPress et on remplace toutes les instances de la base de données par la nouvelle URL.

Il est souvent pratique de laisser l’ancien site en place lors de la relance. On peut ainsi continuer à consulter son contenu et ses pa­ra­mètres ul­té­rieu­re­ment afin de les trans­fé­rer si né­ces­saire. Une bonne approche consiste à héberger le site existant sous un sous-domaine du type old.example.com après la relance. Dans la même ligne, on construit le nouveau site sous un sous-domaine du type dev.example.com avant la relance. On permute les deux sites au moment de la relance :

Si on adopte cette approche, il est in­dis­pen­sable de créer un fichier robots.txt dans le ré­per­toire principal de l’ancien site pour le rendre invisible aux moteurs de recherche. Sinon, le risque de problème de contenu en double se pose et peut avoir des con­sé­quences négatives sur le clas­se­ment des nouveau et ancien sites. On intègre l’entrée suivante au fichier robots.txt de l’ancien site :

Quand on s’attèle à la con­cep­tion d’un site WordPress, il est re­com­mandé de créer un thème enfant dès la mise en place du site, que l’on utilise un thème com­mer­cial ou gratuit. Le thème enfant hérite ensuite de toutes les mo­di­fi­ca­tions apportées au thème. Quand on adopte cette approche, il est aisé de dé­ve­lop­per un nouveau design ul­té­rieu­re­ment.

Il suffit de créer un nouveau thème enfant pour la refonte, et de tester ce dernier sur un site de pré­pro­duc­tion jusqu’à ce que le résultat se montre sa­tis­fai­sant. On copie ensuite le thème enfant terminé dans l’ins­tal­la­tion WordPress existante. Si on active à cet instant le thème enfant, on redémarre avec un thème « frais ».

Qu’en est-il si aucun thème enfant n’a été créé ? Dans ce cas, toutes les mo­di­fi­ca­tions ont été exercées di­rec­te­ment sur le thème. Les modalités de réi­ni­tia­li­sa­tion du thème WordPress dépendent du thème en question.

Quand on recherche des ex­pli­ca­tions pour réi­ni­tia­li­ser un site WordPress, on rencontre le plus fré­quem­ment cette méthode sur la toile. Il s’agit ici de supprimer ma­nuel­le­ment les com­po­sants variables au fil du temps du site WordPress, tout en con­ser­vant (en théorie) certains com­po­sants non mo­di­fiables. D’une certaine manière, on « dénoyaute » le site pour le remplir ensuite de nouveaux contenus.

Nous exposons cette méthode ici uni­que­ment afin de fournir un tour d’horizon complet. Car ce procédé n’est pas moins laborieux que de réins­tal­ler com­plè­te­ment WordPress. Certains com­po­sants WordPress pouvant résister à la réi­ni­tia­li­sa­tion, le risque de voir certains éléments de l’ancienne ins­tal­la­tion poser des problèmes ul­té­rieu­re­ment existe. Examinons le processus :

1. Créer une sau­ve­garde complète du site existant.

Ne pas oublier de sau­ve­gar­der la base de données WordPress et le ré­per­toire WordPress à ce stade !

      2. Créer une nouvelle base de données et prendre note des iden­ti­fiants pour accéder à la nouvelle base de données.

On crée la nouvelle base de données dans le back-end d’hé­ber­ge­ment ou on utilise la commande mysql dans la ligne de commande.

Il est souvent re­com­mandé de supprimer la base de données existante à ce stade. Mais ceci est en fait inutile. Il vaut mieux conserver les données pendant un certain temps. On supprime l’ancienne base de données uni­que­ment si on est sûr que tout a bien réussi.

       3. Vider tous les contenus du dossier wp-content/

Il est souvent re­com­mandé à ce point de supprimer com­plè­te­ment le dossier wp-content. Dans la ligne de commande Linux, la commande suivante permet d’exécuter cette opération si nous nous trouvons dans le ré­per­toire principal de WordPress :

Il est plus pratique de renommer ou de déplacer le dossier :

WordPress ne trouve plus le dossier et crée un nouveau dossier wp-content vide. Les contenus initiaux sont conservés dans le dossier _wp-content en parallèle. Ils restent ainsi ac­ces­sibles afin de vi­sua­li­ser des fichiers et de les trans­fé­rer le cas échéant.

      4. Réins­tal­ler WordPress.

Appeler l’adresse WordPress dans le na­vi­ga­teur à cet effet et accoler le morceau suivant : /wp-admin/install.php

Saisir les iden­ti­fiants de la nouvelle base de données et reprendre le processus d’ins­tal­la­tion.

Le processus manuel de réi­ni­tia­li­sa­tion d’un site WordPress est laborieux et sujet à erreurs. Il vaut mieux limiter les sources d’influence. Moins il existe de voies bien définies, mieux les choses se passent. C’est pré­ci­sé­ment ce en quoi les plugins de réi­ni­tia­li­sa­tion WordPress sont in­té­res­sants. Nous vous pré­sen­tons ici le plugin « WP Reset » en détail.

Pour la plupart des uti­li­sa­teurs, WP Reset constitue le moyen le plus simple et le plus direct pour réi­ni­tia­li­ser un site WordPress. Le plugin dispose d’une interface Web intuitive et offre un bon panel de fonc­tion­na­li­tés. En pratique, le plugin permet de créer un « snap » (capture) de la base de données WordPress. Ceci permet d’annuler une réi­ni­tia­li­sa­tion. Mais ne vous méprenez pas sur ce point : la capture contient uni­que­ment la base de données, les fichiers quant à eux ne sont pas sau­ve­gar­dés ! On veillera donc toutefois à créer une sau­ve­garde complète au­pa­ra­vant.

La « WordPress Command Line Interface » (interface de ligne de commande WordPress, WP-CLI) est un outil in­té­res­sant pour les ad­mi­nis­tra­teurs WordPress. On l’utilise pour piloter WordPress à partir de la ligne de commande. Le logiciel combine les opé­ra­tions du système de fichiers et celles de la base de données dans une interface cohérente. Vous pouvez ainsi utiliser WP-CLI pour réi­ni­tia­li­ser une site WordPress.

Les outils de ligne de commande sont pratiques car ils per­met­tent de nor­ma­li­ser les étapes. L’uti­li­sa­tion de la ligne de commande rend les processus re­pro­duc­tibles et permet de les en­cap­su­ler comme des scripts. L'uti­li­sa­tion de WP-CLI est plus agile et moins risquée que la méthode manuelle.

L'uti­li­sa­tion de WP-CLI nécessite un accès SSH au serveur sur lequel WordPress est exécuté. Une approche solide du travail avec WP-CLI consiste à tester chaque étape sur un site de pré­pro­duc­tion en premier lieu. Vous exécutez les commandes et do­cu­men­tez celles-ci dans un fichier texte. En cas de réussite, les commandes testées sont exécutées dans l’ordre de suc­ces­sion correct sur le site publié.

Examinons quelques-unes des commandes WP-CLI utiles pour réi­ni­tia­li­ser un site WordPress :

L’uti­li­sa­tion d’un plugin est plus facile, mais requiert le bon fonc­tion­ne­ment de WordPress. Les plugins peuvent se mettre en grève, par exemple, si la base de données ne répond pas, si le noyau de WordPress est corrompu, ou en présence d’une erreur de serveur. En outre, l’uti­li­sa­tion d’un plugin est sujette à moins de pos­si­bi­li­tés d’influence détaillée que les deux autres méthodes.

L’uti­li­sa­tion de WP-CLI offre un bon compromis entre puissance et con­vi­via­lité. Toutefois, le logiciel doit être installé sur le serveur pour utiliser WP-CLI. Vous avez également besoin d’un accès SSH au serveur. WP-CLI peut cependant elle aussi refuser de fonc­tion­ner dans certaines cir­cons­tances. Cela peut se produire, par exemple, en cas de conflit de version entre l’ins­tal­la­tion de WordPress et la WP-CLI installée ou si PHP échoue com­plè­te­ment sur le serveur.

La méthode manuelle est puissante et fonc­tionne toujours tant que l’on dispose d’un accès au serveur ou à ses res­sources. Outre SSH, l’accès peut être réalisé via (S)FTP, cPanel et php­MyAd­min. Si la méthode manuelle est puissante, elle exige toutefois la plus grande des adresses. En l’absence des con­nais­sances requises, de graves dommages peuvent être encourus.

Pour résumer, nous évaluons les trois approches comme suit :