Erreur 500 dans WordPress… que faire?

Vous avez fait une mise à jour de votre site WordPress et vous obtenez maintenant une erreur 500 (erreur interne du serveur), ou une page blanche, ou une page qui s’est partiellement chargée. Catastrophe! Que s’est-il passé? Comment régler la situation pour ramener le site à un état fonctionnel?

Qu’est-ce qu’une erreur 500?

Par définition, le syndrome de la page blanche (pas celui des écrivains… celui des artisans du web!), de la page partiellement chargée ou de ce qu’on appelle communément une « erreur 500 » est causé par un problème provenant du serveur.

L’erreur est plutôt vague par définition, mais elle n’est généralement pas difficile à identifier. Voici des exemples du message qui apparaitra à l’écran dans ces circonstances :

• « Internal Server Error »
• « HTTP 500 – Internal Server Error »
• « This page isn’t working… »

Dans toutes nos investigations, nous évaluons que les erreurs 500 sont causées dans 99% des cas par l’un des deux cas suivants :

• Une erreur PHP (provenant généralement du thème ou d’une extension);
• Une erreur provenant du serveur web (Apache via le fichier .htaccess ou Nginx via sa configuration).

Comment identifier la provenance de l’erreur?

Tout d’abord, la première étape consiste à faire une copie de sauvegarde du site.

Mais même cette opération peut être plus difficile puisque si votre site envoie une erreur 500, les chances sont que votre extension de backup ne sera pas fonctionnelle non plus. Si tel est le cas, il faudra copier les fichiers et la base de données manuellement. Autrement, votre extension préférée de backup fera l’affaire!

Ensuite, il faut valider si l’erreur provient de WordPress, du thème ou d’une extension. Pour cela, il faut activer le mode de débogage de WordPress afin d’obtenir un indice. Pour ce faire, il suffit d’ajouter les lignes suivantes au fichier wp-config.php à la racine du site :

define( 'WP_DEBUG' , true );
define( 'WP_DEBUG_LOG' , true );
define( 'WP_DEBUG_DISPLAY' , false );
define( 'SCRIPT_DEBUG' , true );
define( 'SAVEQUERIES' , true );
define( 'IMPORT_DEBUG' , true );
@ini_set( 'display_errors' , 0 );

Depuis WordPress 5.1, il est maintenant possible de spécifier le nom du fichier debug.log de manière à changer le nom du fichier ou son emplacement. C’est une bonne pratique d’en changer l’emplacement pour éviter qu’une tierce-partie puisse y accéder et obtenir de l’information qui pourrait être compromettante à propos de votre installation. Il suffit de modifier la constante WP_DEBUG_LOG comme ceci :

define( 'WP_DEBUG_LOG', '/home/satellitewp/errors.log' );

Note : La valeur de la constante WP_DEBUG doit également avoir une valeur à true pour que le changement d’emplacement soit considéré.

Puis, on visite de nouveau le site afin de provoquer l’erreur. Si un fichier debug.log est créé dans le répertoire wp-content, c’est bon signe, ça veut dire que l’erreur provient du code et non du serveur web.

Il ne reste qu’à consulter le fichier debug.log et de valider ce qui cause le problème. Ensuite, on pourra régler le problème en corrigeant le code ou en retirant l’extension. Mais pour un néophyte, ça demeure quand même plus facile à dire qu’à faire.

Si le fichier debug.log n’existe pas, est vide ou ne contient aucune erreur récente, les chances sont que le problème est causé par la configuration de votre serveur web.

De manière générale, la majorité des hébergements web utilisent Apache comme serveur web. Apache utilise un fichier .htaccess qui contient certaines règlent nécessaires au bon fonctionnement de votre site. De nombreuses extensions peuvent modifier ce fichier et il est possible qu’un d’eux ait corrompu .htaccess en voulant y insérer des changements.

La façon la plus efficace de valider le tout est de vérifier les logs d’Apache. Malheureusement, l’emplacement du fichier est différent d’une configuration à l’autre et vous devrez peut-être contacter votre hébergeur pour en avoir le contenu.

Une façon simple de faire le test serait de renommer le fichier .htaccess-old et de créer un nouveau fichier .htaccess contenant le strict minimum, soit :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Par la suite, vous pouvez visiter votre site de nouveau et voir si le problème existe toujours. Avant de faire ce changement, sachez que les extensions de sécurité telles que iThemes Security, WordFence, All-in-One Security & Firewall et plusieurs autres (dont les extensions de caching) modifient fréquemment le fichier .htaccess. Si vous utilisez une telle extension, parfois désactiver et réactiver l’extension peut régler le problème.

Vous pouvez également configurer celles-ci pour ne pas modifier le fichier .htaccess, vous forçant à copier/coller les nouvelles règles manuellement, mais ainsi mieux gérer les changements à ce fichier essentiel au bon fonctionnement de votre site.

Devrais-je désactiver toutes mes extensions (plugins) ?

Non, non et non!

La méthode de « désactiver toutes les extensions et les réactiver une par une » est souvent suggérée pour identifier le problème. Or, le fait de tout désactiver aveuglément et de réactiver les extensions une à une montre une incompréhension de la situation et une tentative de trouver le problème par déduction plutôt que d’en comprendre la cause. Lorsque l’activation d’une extension causera un bris, on conclura que c’est elle la coupable. Par contre, c’est peut-être la combinaison de cette extension avec une autre qui cause le problème. C’est pourquoi il faut être méthodique et valider via des fichiers de logs.

Conclusion

À ce stade, soit vous avez réglé votre problème, soit vous êtes sans mot quant à ce qui doit être fait pour rétablir la situation.

Vous pouvez demander l’aide de votre hébergeur en premier lieu afin de voir si ce dernier peut vous aider sans frais. Certains, tels que Kinsta incluent ce service et ont également écrit des articles pour vous aider à diagnostiquer le problème vous-même. Sinon, vous pouvez demander l’aide d’experts WordPress et nous contacter. Nous réglons des problèmes de la sorte au quotidien et nous ferons le nécessaire pour rétablir votre site dans les meilleurs délais.