Fichiers du cœur modifiés ? Comment restaurer les fichiers du cœur de WordPress en toute sécurité

Vous regardez un écran blanc là où se trouvait votre page d'accueil. C'est peut-être une erreur 500 à la place, ou une alerte de plugin de sécurité vous indiquant que les fichiers principaux de WordPress ont été modifiés.

J'ai remplacé les fichiers principaux sur des sites que j'ai cassés moi-même et sur des sites qui sont arrivés déjà cassés. Quelle que soit la raison qui vous amène ici, la solution est la même, et elle est moins destructrice qu'il n'y paraît.

Restaurer les fichiers principaux de WordPress signifie remplacer les propres fichiers du programme de WordPress (ceux dans wp-admin, wp-includes et votre répertoire racine) par des copies propres de WordPress.org. Vos articles, pages, médias, thèmes, plugins et paramètres ne bougent pas. Ils vivent ailleurs.

Deux choses tournent mal lorsque les gens tentent cela par eux-mêmes.

La première est la suppression de wp-content en même temps que les dossiers principaux, ce qui transforme une réparation de 20 minutes en une reconstruction complète. La seconde est de télécharger la dernière version de WordPress alors que le site utilise une version plus ancienne, ce qui force un saut de version majeure sur un site déjà instable.

Dans cet article, je vais vous montrer comment confirmer que les fichiers principaux sont le problème avant de supprimer quoi que ce soit, trois façons de les remplacer et quoi faire lorsque le remplacement n'est pas la vraie solution.

Points clés à retenir :

• Vérifiez avant de supprimer quoi que ce soit : wp core verify-checksums répond en une seule commande si les fichiers principaux sont le problème, et une passe propre signifie que vous remplaceriez des fichiers qui n'ont jamais été corrompus.
• Faites correspondre votre version au lieu de prendre la dernière : installer la dernière version de WordPress sur un ancien site force une mise à niveau majeure non planifiée et un changement de schéma de base de données sur un site déjà instable.
• Vous avez trois options : le bouton Réinstaller la version X.X.X si vous pouvez vous connecter, une commande WP-CLI si vous avez SSH, et un échange manuel FTP si vous n'avez ni l'un ni l'autre.
• Supprimez les dossiers principaux plutôt que de les écraser : l'écrasement laisse les fichiers ajoutés par l'attaquant dans wp-admin et wp-includes car rien dans la version officielle ne remplace un fichier qui n'en fait pas partie.
• Les fichiers principaux propres ne nettoient pas un site piraté : les portes dérobées dans wp-content/uploads, les mu-plugins malveillants et les lignes de base de données injectées survivent tous, c'est à ce moment qu'une restauration complète est préférable à une réparation fichier par fichier.

Table des matières

Quels sont les fichiers principaux de WordPress ?

Avant de supprimer quoi que ce soit, vous devez savoir quels dossiers comptent comme fichiers principaux de WordPress et lesquels sont les vôtres. Se tromper sur ce point est l'erreur la plus coûteuse de tout le processus.

Voici ce qui compte comme un fichier principal :

• Tout dans wp-admin. C'est le tableau de bord d'administration lui-même, chaque écran auquel vous vous connectez.
• Tout dans wp-includes. Ce sont les bibliothèques sur lesquelles WordPress fonctionne. C'est le plus grand dossier en nombre de fichiers et celui qui est le plus susceptible d'être signalé comme modifié.
• Les fichiers PHP lâches dans votre répertoire racine. Des fichiers comme index.php, wp-login.php, wp-settings.php et wp-cron.php se trouvent à côté de vos dossiers, et ils sont également remplacés.

Quels fichiers WordPress ne faut-il pas remplacer ?

Voici ce que vous devriez laisser tranquille :

• wp-content. Il contient les téléchargements spécifiques au site, les plugins installés, les thèmes, les mu-plugins et parfois des artefacts d'hébergement ou de déploiement. WordPress fournit une copie de ce dossier, mais le vôtre est unique.
• wp-config.php. Il contient vos identifiants de base de données. Écrasez-le, et votre site ne pourra pas trouver son propre contenu.
• .htaccess. Ce n'est pas un fichier principal, mais WordPress y écrit. Sauvegardez une copie et laissez l'original en place.
• Tout ce que votre hébergeur ou votre développeur a ajouté. Fichiers de vérification de domaine, scripts personnalisés, un fichier robots.txt édité à la main. Si cela ne provenait pas du téléchargement de WordPress, cela reste.

Supprimez wp-content, et vous ne restaurerez plus les fichiers principaux. Vous reconstruirez votre site à partir de zéro.

Quand faut-il restaurer les fichiers principaux de WordPress ?

Les fichiers principaux restent intacts pendant des mois. Lorsqu'ils se corrompent, c'est presque toujours l'une des quelques causes. Savoir laquelle vous rencontrez change la façon dont vous gérez le nettoyage par la suite.

Voici quand remplacer les fichiers principaux est la bonne décision :

• Une mise à jour du cœur a échoué en cours de route. La connexion a été interrompue, le serveur a expiré, ou PHP a atteint sa limite de mémoire. Vous vous retrouvez avec certains fichiers de l'ancienne version et d'autres de la nouvelle, et WordPress n'a aucun moyen de les réconcilier.
• Une analyse a signalé que les fichiers principaux de WordPress ont été modifiés. Wordfence, Sucuri et de nombreux hébergeurs gérés comparent vos fichiers aux versions officielles de WordPress.org. Un fichier principal modifié signifie que quelque chose a changé dans le code que personne ne devrait modifier.
• Votre site a été piraté. Les attaquants injectent du code dans les fichiers principaux car ces fichiers sont chargés à chaque requête. Les remplacer efface le code injecté (cela n'effacera pas le reste de l'infection, sur lequel je reviendrai plus tard).
• Des fichiers ont été corrompus lors d'un transfert. Une session FTP interrompue ou une migration inachevée laisse des fichiers tronqués. Ils semblent normaux dans une liste de fichiers et échouent la deuxième fois que PHP essaie de les exécuter.
• Un écran blanc ou une erreur 500 a survécu au dépannage de base. Si vous avez désactivé tous les plugins, basculé vers un thème par défaut, et que l'erreur n'a pas bougé, les fichiers principaux sont le prochain endroit à examiner.
• Quelqu'un a modifié un fichier principal intentionnellement. Cela arrive plus souvent que vous ne le pensez. La modification persiste jusqu'à ce qu'une mise à jour la remplace ou que le fichier ne corresponde plus à ce que WordPress attend.

Il y a une situation où la restauration des fichiers principaux ne vous aidera pas du tout : un plugin ou un thème défectueux. Ce processus ne touche pas à wp-content, donc si c'est là le vrai problème, vous ferez tout le travail et vous vous retrouverez avec la même erreur. L'étape 1 vous permet de le savoir avant de passer une heure dessus.

Ce dont vous avez besoin avant de commencer

Voici ce qu'il faut avoir sous la main avant de restaurer les fichiers principaux de WordPress :

• Une sauvegarde complète effectuée maintenant. Stockez-la quelque part à l'écart du serveur que vous êtes sur le point de modifier (je recommande Duplicator Cloud). Si vous utilisez Duplicator Pro, c'est ce qui transforme un mauvais après-midi en restauration en un clic.
• Accès via au moins l'une des méthodes suivantes : le tableau de bord WordPress, SFTP ou FTP (FileZilla est gratuit et fait le travail), le gestionnaire de fichiers de votre hébergeur, ou SSH. Vous n'en avez besoin que d'une, et celle que vous avez détermine votre méthode à l'étape 4.
• Votre numéro de version exact de WordPress, écrit. Si le tableau de bord est inaccessible, ouvrez wp-includes/version.php via FTP et lisez la ligne $wp_version près du début.
• Copies locales de wp-config.php et .htaccess. Téléchargez les deux avant de toucher quoi que ce soit.
• 15 à 30 minutes, selon la méthode que vous finirez par utiliser.

Si votre site reçoit du trafic réel, faites-le pendant une heure creuse. Il sera partiellement indisponible pendant que le téléchargement s'exécute.

Comment restaurer les fichiers principaux de WordPress

Le processus comporte six étapes. Trois d'entre elles sont identiques quelle que soit la méthode, et l'étape 4 est celle où vous choisissez un chemin en fonction de l'accès dont vous disposez encore.

Voici comment restaurer vos fichiers principaux WordPress :

• Étape 1 : Confirmez que les fichiers principaux sont le problème. Un scan de somme de contrôle vous indique si vous réparez la bonne chose avant de supprimer quoi que ce soit d'irréversible.
• Étape 2 : Sauvegardez le site avant de remplacer quoi que ce soit. Un transfert qui échoue à mi-chemin peut faire tomber tout le site, et c'est l'étape qui rend cela récupérable.
• Étape 3 : Faites correspondre la version de WordPress que vous restaurez. Tirer la mauvaise version transforme une réparation en une mise à niveau imprévue par-dessus un site cassé.
• Étape 4 : Remplacez les fichiers principaux. Choisissez le tableau de bord, WP-CLI ou FTP en fonction de l'accès dont vous disposez, et n'en exécutez qu'un seul des trois.
• Étape 5 : Exécutez la mise à niveau de la base de données et nettoyez les restes. Un nouveau code contre un ancien schéma, un fichier .maintenance bloqué et des caches obsolètes sont tous interprétés comme « c'est toujours cassé » alors que les fichiers sont déjà corrects.
• Étape 6 : Vérifiez que la restauration a fonctionné. Un site qui se charge n'est la preuve de rien, et un second passage de somme de contrôle propre l'est.

Étape 1 : Confirmer que les fichiers principaux sont le problème

Sautez cette étape, et vous pouvez passer une heure à remplacer des fichiers qui n'ont jamais été cassés. Je l'ai fait. Un fichier principal corrompu et une erreur fatale de plugin se ressemblent de manière identique en façade.

WP-CLI règle la question en une seule commande.

WP-CLI est l'outil en ligne de commande de WordPress, et vous l'exécutez via SSH (une connexion terminal à votre serveur). La plupart des hébergeurs gérés l'ont déjà installé, alors vérifiez avant de supposer qu'il n'est pas disponible.

Connectez-vous via SSH, déplacez-vous dans votre répertoire WordPress et exécutez :

wp core verify-checksums

WordPress.org publie une somme de contrôle pour chaque fichier de chaque version, qui est une courte empreinte du contenu de ce fichier. La commande récupère la liste pour votre version et la compare à ce qui se trouve sur votre serveur.

Une installation propre renvoie une seule ligne de succès. Une installation endommagée nomme chaque fichier qu'elle ne peut pas vérifier :

Warning: File doesn't verify against checksum: wp-includes/version.php

Error: WordPress installation doesn't verify against checksums.

Un résultat est une fausse alerte qui mérite d'être reconnue. readme.html échoue constamment car les hébergeurs le modifient ou le suppriment. La commande détecte la langue de votre installation automatiquement, vous n'avez donc besoin du drapeau --locale (par exemple, wp core verify-checksums --locale=de_DE) que si elle se trompe dans sa détection.

Exécutez-la ensuite à nouveau avec --include-root :

wp core verify-checksums --include-root

Ce drapeau vous avertit des fichiers situés dans votre répertoire racine qui ne font pas du tout partie de WordPress. Sur un site piraté, c'est souvent là que vous trouvez ce qui a causé le problème en premier lieu.

Si vous n'avez pas d'accès SSH, vous avez trois autres moyens de vérifier :

• Exécutez un scan Wordfence. Sa comparaison de fichiers principaux fait le même travail depuis le tableau de bord et vous montre exactement ce qui a changé dans chaque fichier.
• Utilisez l'outil d'intégrité des fichiers de votre hébergeur. La plupart des hébergeurs gérés en ont un, généralement classé sous un onglet sécurité ou outils.
• Comparez à la main. Téléchargez une copie fraîche de votre version de WordPress, ouvrez le fichier suspect des deux copies et lisez-les côte à côte.

Lisez maintenant vos résultats honnêtement avant d'aller plus loin. Si les sommes de contrôle reviennent propres, vos fichiers principaux sont corrects, et votre problème vient d'un plugin, d'un thème ou de votre base de données.

Remplacer les fichiers principaux ne résoudra aucun de ces problèmes.

Vous êtes prêt pour l'étape 2 lorsque vous avez en main soit une liste de fichiers spécifiques qui n'ont pas pu être vérifiés, soit un rapport de succès qui vous dit de chercher ailleurs.

Étape 2 : Sauvegarder le site avant de remplacer quoi que ce soit

Vous êtes sur le point de supprimer deux dossiers dont WordPress a besoin pour fonctionner. Si le téléversement qui les remplace échoue à mi-chemin, votre site passera de cassé à inexistant.

C'est un problème pire que celui que vous avez actuellement.

Effectuez une sauvegarde complète couvrant à la fois vos fichiers et la base de données. Assurez-vous d'envoyer une copie ailleurs que sur le serveur que vous êtes sur le point de modifier. Une copie hors site est la seule qui survive à une défaillance au niveau du serveur.

Duplicator est mon outil préféré pour cela. Allez dans Duplicator Pro » Backups et cliquez sur Add New.

Choisissez le préréglage de sauvegarde Full Site et sélectionnez au moins deux emplacements de stockage (j'aime utiliser Local et Duplicator Cloud).

Vous vous retrouverez avec deux fichiers : l'archive, qui contient votre site et votre base de données compressés, et l'installateur, qui est le script PHP qui remet tout en place.

Si quelque chose se passe mal pendant le processus de restauration des fichiers, téléversez à nouveau ces fichiers sur votre serveur et lancez l'installateur de Duplicator.

Si vous n'utilisez pas Duplicator, faites une sauvegarde manuelle. Voici le minimum requis pour cette étape :

• Téléchargez wp-content, wp-config.php et .htaccess sur votre ordinateur via FTP.
• Exportez votre base de données depuis phpMyAdmin sous forme de fichier .sql.

Vous êtes prêt à passer à l'étape suivante lorsque vous savez où se trouve votre sauvegarde et comment vous la remettriez en place.

Étape 3 : Faire correspondre la version de WordPress que vous restaurez

Chaque tutoriel sur ce sujet vous dit de télécharger la dernière version de WordPress. C'est un bon conseil si votre site utilise déjà la dernière version. C'est un piège si ce n'est pas le cas.

Supposons que vous ayez deux versions majeures de retard. Vous installez les derniers fichiers principaux, et vous n'avez encore rien réparé. Ce que vous avez fait, c'est forcer une mise à niveau de version majeure plus un changement de schéma de base de données sur un site instable, en pleine urgence, sans test.

Restaurez la version que vous utilisez. Mettez à niveau plus tard, intentionnellement, une fois que le site est sain.

Voici comment trouver votre numéro de version :

• Depuis le tableau de bord : allez dans Tableau de bord » Mises à jour. La version que vous utilisez est indiquée en haut de l'écran.
• Via FTP : ouvrez wp-includes/version.php et lisez la ligne $wp_version près du haut du fichier. Cela fonctionne quand rien d'autre ne fonctionne.
• Via SSH : exécutez wp core version et il affichera le numéro.

Maintenant, téléchargez cette version exacte depuis les archives des versions de WordPress au lieu de la page de téléchargement principale. La page principale ne propose que la version actuelle.

Le téléchargement des fichiers principaux de WordPress est une seule archive zip contenant wp-admin, wp-includes, wp-content et les fichiers racine lâches. Faites correspondre la chaîne de version complète, pas seulement le numéro majeur. Une différence de version mineure constitue toujours un ensemble de fichiers différent.

Si vous optez pour la voie WP-CLI, vous pouvez sauter le téléchargement complètement. La commande de la Méthode 2 ci-dessous lit votre version et récupère les fichiers correspondants en une seule étape.

Vous êtes prêt pour l'Étape 4 lorsque vous avez un zip WordPress sur votre ordinateur qui correspond à votre site ou un terminal ouvert et en attente.

Étape 4 : Remplacer les fichiers principaux

C'est l'étape où les fichiers endommagés sortent et les propres entrent. Il y a trois façons de le faire, et elles remplacent toutes les fichiers du programme de WordPress par des copies vérifiées de WordPress.org tout en laissant votre contenu et vos paramètres intacts.

Celui que vous utilisez dépend de l'accès que vous avez :

• Méthode 1 : Le bouton du tableau de bord. Utilisez ceci si vous pouvez toujours vous connecter à WordPress. C'est de loin le plus rapide.
• Méthode 2 : WP-CLI. Utilisez ceci si vous avez SSH. C'est le plus précis, et c'est le seul qui épingle votre version dans la même commande.
• Méthode 3 : FTP manuel. Utilisez ceci lorsque vous n'avez ni l'un ni l'autre. Il fonctionne sur n'importe quel hôte et offre le plus de possibilités d'erreurs.

Méthode 1 : Utiliser le bouton Réinstaller du tableau de bord

Si wp-admin se charge toujours, commencez ici. C'est le moyen le plus rapide de réinstaller le cœur de WordPress, et vous n'aurez pas à toucher un seul dossier.

Allez dans Tableau de bord » Mises à jour. Lorsque vous êtes déjà sur la version actuelle, WordPress vous le dit et vous propose de réinstaller cette version pour vous, avec un bouton Réinstaller la version X.X.X.

Cliquez dessus. WordPress téléchargera la mise à jour, décompressera la mise à jour du cœur, vérifiera les fichiers décompressés, installera la dernière version et mettra à niveau la base de données. Il se termine par un message de succès sur le même écran.

Sachez une limitation avant de commencer. Ceci réinstalle la version sur laquelle WordPress pense que vous devriez être, donc cela ne peut pas vous faire reculer. Si une mauvaise mise à jour est ce qui a cassé votre site, ce bouton ne l'annulera pas.

Il écrase également les fichiers plutôt que de supprimer les dossiers, tout comme la Méthode 2. Tout ce qu'un attaquant a ajouté dans wp-admin ou wp-includes reste en place. Si vous nettoyez un piratage, utilisez la Méthode 3, ou confirmez ensuite avec un passage de somme de contrôle qu'il ne reste rien d'inhabituel.

Certains hôtes interrompent le processus avec une boîte de dialogue Informations de connexion demandant les identifiants FTP. C'est un problème de propriété de fichier, et la section de dépannage ci-dessous couvre la solution.

Méthode 2 : Utiliser WP-CLI

WP-CLI est ce que j'utilise chaque fois que j'ai accès au terminal. Connectez-vous via SSH, déplacez-vous dans votre répertoire WordPress et exécutez :

wp core download --version=$(wp core version) --force --skip-content

Voici ce que fait chaque partie :

• --version=$(wp core version) lit la version que votre site exécute et télécharge cette version exacte.
• --force écrase les fichiers existants. Sans cela, WP-CLI refuse de toucher un répertoire qui contient déjà WordPress.
• --skip-content exclut complètement wp-content du téléchargement, de sorte que vos thèmes, plugins et téléchargements n'approchent jamais de l'écrasement.

N'utilisez pas wp core install ici, même si le nom semble correct. Cette commande exécute la routine d'installation de WordPress sur un nouveau site, et c'est le mauvais outil pour un site qui existe déjà.

Avant d'appuyer sur entrée, sachez que --force ne demande pas de confirmation. Si quelqu'un a délibérément modifié un fichier principal de ce site, cette modification disparaît à la seconde où la commande s'exécute. C'est généralement le but recherché, mais vérifiez auprès de la personne qui a construit le site si vous n'êtes pas sûr.

Confirmez ensuite le résultat :

wp core verify-checksums

Une passe propre signifie que la moitié du problème liée aux fichiers est résolue.

Méthode 3 : Remplacer les fichiers manuellement via FTP

Lorsque vous ne pouvez pas accéder au tableau de bord et que vous n'avez pas d'accès SSH, vous effectuez le même travail manuellement : retirez les deux dossiers principaux du serveur et mettez-en de nouveaux à leur place.

Aucun des gestes individuels n'est difficile. La séquence est ce qui protège les fichiers que vous devez conserver, il est donc utile de la suivre dans l'ordre.

1. Désactivez vos plugins si vous pouvez toujours accéder au tableau de bord. Sautez cette étape si ce n'est pas le cas. C'est une précaution, pas une exigence.
2. Décompressez le téléchargement de WordPress sur votre ordinateur. Vous verrez wp-admin, wp-includes, wp-content, et une poignée de fichiers en vrac.
3. Supprimez wp-admin et wp-includes sur le serveur. Les deux dossiers, complètement. Laissez tout le reste exactement où il est.
4. Téléversez les nouveaux wp-admin et wp-includes de votre copie décompressée au même endroit.
5. Téléversez les fichiers racines en vrac de la nouvelle version et écrasez les anciens. Ne supprimez pas votre dossier racine d'abord. Vous perdriez wp-config.php et .htaccess avec.
6. Copiez les fichiers de l'intérieur du nouveau wp-content dans votre wp-content existant. Copiez à l'intérieur. Ne le remplacez jamais.
7. Vérifiez que wp-config.php et .htaccess sont toujours dans votre racine. Si l'un d'eux est manquant, téléversez la copie que vous avez sauvegardée précédemment.

L'étape 3 de cette liste est là où les gens hésitent, car supprimer semble plus risqué que d'écraser. C'est le contraire.

Écraser ne remplace que les fichiers qui existent dans les deux copies. Tout ce qu'un attaquant a déposé dans wp-admin ou wp-includes ne fait pas partie de la version officielle, donc rien ne l'écrase, et il passe à travers tout votre nettoyage sans être touché. Supprimer les dossiers d'abord est ce qui en fait une vraie solution plutôt qu'une solution cosmétique.

Fixez également vos attentes en matière de temps. wp-includes à lui seul contient plus d'un millier de fichiers, et le FTP les déplace un par un. Vingt minutes est normal sur une connexion lente, et des transferts interrompus peuvent se produire.

Si le téléversement continue d'échouer, envoyez le zip sur votre serveur en un seul fichier et extrayez-le là-bas avec le gestionnaire de fichiers de votre hébergeur. Un seul gros transfert est beaucoup plus fiable qu'un millier de petits.

Vous avez terminé cette étape lorsque votre structure de dossiers correspond à la nouvelle copie, que wp-config.php est intact et que le site se charge, même s'il vous accueille avec une invite de mise à jour de la base de données.

Étape 5 : Exécuter la mise à niveau de la base de données et effacer les restes

Vos fichiers sont maintenant propres, mais WordPress peut toujours se trouver dans l'état où la mise à jour échouée l'a laissé. Trois petits nettoyages terminent le travail.

Commencez par visiter /wp-admin. Il se peut qu'on vous demande de vous reconnecter, ce qui est normal.

Si WordPress détecte que votre base de données doit rattraper le code, il affiche un écran Mise à jour de la base de données requise avec un bouton Mettre à jour la base de données WordPress. Cliquez dessus et laissez-le s'exécuter.

Faites-le immédiatement, car tant que vous ne l'aurez pas fait, votre site exécutera du nouveau code contre un ancien schéma.

Ensuite, recherchez dans votre répertoire racine un fichier nommé .maintenance et supprimez-le s'il s'y trouve. WordPress crée ce fichier au début d'une mise à jour et le supprime une fois la mise à jour terminée. Lorsqu'une mise à jour échoue en cours de route, le fichier reste, et les visiteurs voient le message de maintenance.

C'est un fichier caché, il n'apparaîtra donc pas dans votre liste de fichiers tant que vous n'aurez pas activé l'affichage des fichiers cachés. Dans FileZilla, c'est Serveur » Forcer l'affichage des fichiers cachés, et dans la plupart des gestionnaires de fichiers d'hébergement, c'est une case à cocher Afficher les fichiers cachés dans les paramètres.

Ensuite, videz tous les caches que vous avez : votre plugin de cache, le cache serveur de votre hébergeur, votre CDN et votre propre navigateur. Si vous sautez cette étape, vous risquez de passer 20 minutes à déboguer une page qui était déjà corrigée.

Réactivez vos plugins si vous les avez désactivés pendant la Méthode 3.

Vous avez terminé ici lorsque le tableau de bord se charge, que l'invite de mise à jour a disparu et que votre front-end s'affiche correctement.

Étape 6 : Vérifier que la restauration a fonctionné

Un site qui se charge n'est pas la même chose qu'un site qui est réparé. Avant de fermer l'onglet, parcourez cette liste.

Voici ce qu'il faut vérifier :

• Relancez wp core verify-checksums. Une exécution réussie est la seule preuve définitive que vos fichiers principaux correspondent à la version officielle.
• Chargez votre front-end déconnecté dans une fenêtre de navigation privée. Les vues connectées masquent les problèmes de cache et les erreurs de permission.
• Cliquez sur les pages importantes. Votre page d'accueil, un article unique, une archive de catégorie, l'écran de connexion, et tout formulaire ou processus de paiement dont vous dépendez.
• Réenregistrez vos permaliens. Allez dans Paramètres » Permaliens et cliquez sur Enregistrer les modifications sans rien changer. Cela régénère vos règles de réécriture, ce qui est la raison habituelle pour laquelle les articles commencent à retourner des 404 après un échange de fichiers.
• Confirmez vos URL. Sous Paramètres » Général, vérifiez que WordPress Address (URL) et Site Address (URL) correspondent exactement à ce qu'ils étaient avant.
• Lisez votre journal d'erreurs. Tout ce qui est nouveau dedans mérite d'être traité maintenant, pendant que vous vous souvenez encore de ce que vous avez changé.

Ensuite, faites une autre sauvegarde. Votre site est dans un état connu et fonctionnel à cet instant précis, c'est l'état qu'il faut capturer, et c'est une copie beaucoup plus utile à conserver que celle d'urgence que vous avez faite à l'étape 2.

Et si le remplacement des fichiers principaux ne résout pas le problème ?

Parfois, vous suivez toutes les étapes, les sommes de contrôle sont correctes, et le site ne fonctionne toujours pas. Lorsque cela se produit, les fichiers principaux endommagés étaient un symptôme plutôt que la cause.

Trois scénarios expliquent la plupart de ces cas :

• Le site a été piraté. Le remplacement des fichiers principaux supprime le code injecté des fichiers principaux et rien d'autre. Une porte dérobée dans wp-content/uploads, un fichier functions de thème modifié, ou quelque chose caché dans mu-plugins y survivent tous. L'indice le plus clair est la présence de fichiers PHP dans votre dossier uploads, où seuls les médias devraient se trouver.
• La base de données a également subi des dommages. Vos fichiers vont bien, et votre contenu aussi. Les liens de spam injectés dans la table des posts, un siteurl réécrit dans la table des options, et des comptes administrateurs inconnus survivent tous à une restauration du noyau.
• Les sommes de contrôle passent et le site génère toujours des erreurs. Cela pointe vers un plugin, un thème ou une incompatibilité de version PHP. L'étape 1 vous a mis sur la bonne voie ; les fichiers principaux n'ont jamais été le problème.

Dans les trois cas, restaurer l'ensemble du site à partir d'une sauvegarde fiable est préférable à le nettoyer fichier par fichier. Vous arrêtez de deviner ce qui est propre.

Dans Duplicator Pro, trouvez une sauvegarde datant d'avant le début des problèmes et restaurez-la.

Si cette sauvegarde se trouve sur Google Drive, Dropbox ou un autre emplacement de stockage connecté, vous pouvez restaurer directement depuis WordPress sans avoir à télécharger et re-télécharger l'archive au préalable.

Si WordPress ne se charge pas du tout, téléchargez à nouveau la sauvegarde avec laquelle vous avez commencé dans votre répertoire racine. Lancez l'installateur de Duplicator avec une URL telle que : https://votre-domaine/installer.php

Une restauration ramène votre site au moment où cette sauvegarde a été effectuée, donc tout ce qui a été publié ou commandé depuis sera perdu. Sur un site compromis, c'est généralement la bonne décision, car un nettoyage partiel qui manque une porte dérobée vous ramène ici en une semaine.

Duplicator ne scanne pas et ne supprime pas les logiciels malveillants. Il vous fournit une copie propre d'un site qui fonctionnait. Associez-le à un scanner de sécurité si vous traitez une infection active.

Pour la méthode manuelle, Comment restaurer manuellement votre site WordPress couvre la restauration des fichiers et des bases de données à la main, et Comment restaurer un site Web avec uniquement une sauvegarde de base de données couvre ce qu'il faut faire lorsque la base de données est tout ce qu'il vous reste.

Dépannage : Erreurs courantes après la restauration des fichiers principaux

Ce sont les échecs qui surviennent le plus souvent après un échange de fichiers principaux. Travaillez à partir du symptôme que vous observez.

Pourquoi mon site affiche-t-il « Indisponible pour maintenance planifiée » ?

Vous obtenez une page blanche unie avec une seule ligne de texte, et elle ne disparaît pas.

WordPress écrit un fichier appelé .maintenance dans votre répertoire racine lorsqu'une mise à jour commence et le supprime lorsque la mise à jour se termine. Si la mise à jour a échoué entre-temps, ce fichier est toujours là, et WordPress ne peut pas savoir que la tâche n'a jamais été terminée. WordPress cesse de prendre en compte le fichier après 10 minutes, mais une mise à jour échouée peut laisser votre site à moitié mis à jour entre-temps.

Supprimez .maintenance de votre répertoire racine via FTP en activant l'affichage des fichiers cachés. Via SSH, wp maintenance-mode deactivate fait la même chose. Votre site revient à la normale dès que le fichier est supprimé.

Pourquoi me demande-t-on mes informations de connexion FTP ?

Vous cliquez sur Réinstaller la version X.X.X et WordPress ouvre une boîte de dialogue Informations de connexion demandant un nom d'hôte, un nom d'utilisateur et un mot de passe. Il s'agit d'un problème de propriété de fichier.

WordPress n'écrit des fichiers directement que lorsqu'ils appartiennent au même utilisateur que celui sous lequel le serveur Web s'exécute. Lorsqu'ils ne lui appartiennent pas, il demande des informations d'identification FTP afin de pouvoir les écrire d'une autre manière.

Entrez les informations d'identification du compte FTP qui possède vos fichiers WordPress, et il continuera. Si vous ne les avez pas, demandez à votre hébergeur de corriger la propriété, ce qui est la vraie solution.

Vous trouverez également des conseils en ligne sur l'ajout de define('FS_METHOD', 'direct'); à wp-config.php. Cela fonctionne parfois, mais cela contourne le symptôme et peut échouer plus tard de manière plus difficile à diagnostiquer que la boîte de dialogue.

Pourquoi ai-je un écran blanc après avoir remplacé les fichiers principaux ?

Rien ne se charge du tout, ni le front-end ni l'administration, et il n'y a aucun texte d'erreur sur lequel travailler. Trois causes couvrent presque tous ces cas : un transfert FTP qui s'est terminé incomplètement, des permissions de fichiers qui se sont avérées incorrectes lors du téléchargement, ou une erreur fatale PHP qui est supprimée.

Ré-téléchargez d'abord wp-includes, car c'est le dossier le plus volumineux et le plus susceptible d'avoir perdu des fichiers. Vérifiez ensuite vos permissions, qui devraient être 644 pour les fichiers et 755 pour les dossiers.

Si l'écran est toujours vierge, ajoutez define('WP_DEBUG', true); et define('WP_DEBUG_LOG', true); à wp-config.php et lisez wp-content/debug.log. Cela transforme un écran blanc en nom de fichier et numéro de ligne.

Pourquoi les sommes de contrôle échouent-elles toujours après une réinstallation propre ?

Vous avez tout remplacé, et wp core verify-checksums affiche toujours des avertissements. Il s'agit généralement de l'une des trois choses suivantes : readme.html est signalé car votre hébergeur le modifie ou le supprime, la commande a choisi la mauvaise langue pour votre installation, ou quelque chose dans ces dossiers n'y appartient vraiment pas.

Si chaque fichier est signalé, réexécutez-le avec votre locale (wp core verify-checksums --locale=fr_FR, par exemple) et voyez ce qui reste. Un avertissement « Le fichier ne devrait pas exister » signifie que quelque chose d'inattendu se trouve dans un dossier principal, et l'écrasement ne le supprimera pas. Supprimez complètement wp-admin et wp-includes et téléchargez de nouvelles copies, ce qui fait la différence de la Méthode 3.

Pourquoi WordPress indique-t-il qu'une mise à jour est déjà en cours ?

Vous essayez de réinstaller et on vous dit « Une autre mise à jour est en cours ». WordPress définit un verrou dans votre table d'options lorsqu'une mise à jour du cœur commence, de sorte que deux mises à jour ne peuvent pas s'exécuter en même temps. Une mise à jour plantée laisse ce verrou derrière elle sans rien pour le supprimer.

Le verrou expire de lui-même après 15 minutes, donc attendre ne vous coûte rien d'autre que du temps. Pour le supprimer maintenant, exécutez wp option delete core_updater.lock, ou ouvrez votre table d'options dans phpMyAdmin, trouvez la ligne core_updater.lock et supprimez-la.

Rien ne fonctionne : que faire maintenant ?

Vous avez parcouru la liste, et le site est toujours en panne. À ce stade, arrêtez de réparer et commencez à restaurer.

Retournez à la sauvegarde que vous avez effectuée à l'étape 2. Si vous pouvez toujours accéder au tableau de bord, effectuez une restauration en un clic depuis Duplicator Pro » Backups. Si ce n'est pas le cas, téléchargez à nouveau l'archive et l'installateur dans votre répertoire racine et lancez l'installateur dans votre navigateur, ce qui fonctionne sans installation WordPress fonctionnelle derrière.

Si vous n'avez pas de sauvegarde, contactez votre hébergeur et demandez un instantané côté serveur. La plupart des hébergeurs conservent des sauvegardes quotidiennes sur une fenêtre glissante, même sur les plans mutualisés, et le support peut en restaurer une pour vous.

Questions fréquemment posées (FAQ)

Les fichiers principaux propres sont la base : voici ce qu'il faut faire ensuite

Vous avez remplacé les fichiers du programme de WordPress par des copies vérifiées et confirmé cela avec une vérification de somme de contrôle. Cette vérification est plus importante que le simple chargement du site. Un site peut se charger parfaitement bien avec un fichier principal modifié exécutant discrètement le code de quelqu'un d'autre à chaque requête, c'est pourquoi l'étape de diagnostic est venue avant tout le reste.

Trois habitudes vous évitent cela à partir de maintenant.

• Planifiez vos sauvegardes au lieu de les faire quand vous vous en souvenez.
• Effectuez une nouvelle sauvegarde après chaque mise à jour réussie, de sorte que votre état de fonctionnement le plus récent ne soit jamais à plus d'une restauration.
• Exécutez wp core verify-checksums comme une vérification mensuelle de routine plutôt qu'une mesure d'urgence, car un fichier principal modifié que vous détectez lors d'un contrôle de santé est un problème beaucoup moins important que celui que vous découvrez lorsque le site tombe en panne.

Une chose de plus qui vaut la peine d'être faite pendant que vous êtes déjà dans wp-config.php. Ajoutez define('DISALLOW_FILE_EDIT', true); pour désactiver les éditeurs de thèmes et de plugins intégrés, ce qui ferme le chemin le plus facile pour quiconque ayant un accès administrateur modifie un fichier depuis le tableau de bord. Ajoutez ensuite un petit fichier .htaccess dans wp-content/uploads qui bloque l'exécution de PHP là-bas :

<Files *.php>

Require all denied

</Files>

Ce second élément est la syntaxe Apache 2.4, donc sur nginx, vous voudrez le bloc de localisation équivalent dans la configuration de votre serveur. Ensemble, ils ferment les deux portes qui ont mis la plupart des gens dans cette situation au départ, et aucun ne prend plus d'une minute.

Arrêtez de réparer les sites WordPress à la main

Remplacer manuellement les fichiers principaux fonctionne. Cela vous coûte également un après-midi, et cela n'aide que si vous attrapez le problème avant qu'il ne se propage. Une sauvegarde récente et une restauration en un clic transforment cette longue session de débogage en deux minutes.

Duplicator Pro est ce sur quoi plus de 1,5 million d'utilisateurs actifs comptent pour les sauvegardes planifiées, les restaurations en un clic directement depuis le stockage cloud et une URL de récupération d'urgence qui fonctionne toujours lorsque WordPress ne se charge pas. Chaque plan payant est assorti d'un remboursement de 14 jours sans poser de questions.

Si ce tutoriel vous a aidé, ces guides méritent également d'être mis en favoris.

• Comment restaurer WordPress à partir d'une sauvegarde (en moins de 5 minutes)
• Comment restaurer manuellement votre site WordPress
• Comment restaurer un site web avec seulement une sauvegarde de base de données
• Comment rétrograder votre version de WordPress et annuler les mauvaises mises à jour
• Comment restaurer votre site WordPress à partir d'une sauvegarde Google Cloud
• Comment restaurer un site WordPress à une date antérieure sans sauvegarde