L'erreur de serveur interne 500 est le fléau le plus inutile des utilisateurs de WordPress partout. C'est un message d'erreur fourre-tout qui signifie précisément :quelque chose s'est mal passé quelque part. Pire encore, votre site WordPress peut ne présenter aucune erreur et afficher simplement une page blanche vierge.
Alors, comment pouvez-vous déterminer exactement ce qui ne va pas et y remédier ?
Premièrement :ne paniquez pas, car c'est généralement une solution facile ! Ensuite :suivez ce processus de débogage et votre erreur de serveur interne WordPress sera corrigée en un rien de temps.
Si vous venez d'installer un nouveau plugin ou si votre site affiche une erreur 500 après une mise à jour principale de WordPress, la cause la plus probable est un plugin incompatible. Il existe de nombreuses raisons pour lesquelles un plugin peut être cassé :
L'identification du plugin est facile si vous venez d'en installer un et que l'erreur vient d'apparaître. Mais comment désactiver le plugin si la zone d'administration est inaccessible ? Et si vous ne savez même pas quel plugin a causé l'erreur ? Vous aurez besoin d'un accès FTP dans les deux cas, mais un gestionnaire de fichiers Web de CPanel ou Plesk fonctionnera également correctement.
Savoir précisément quel plugin est cassé ? Trouvez le plugin et supprimez-le depuis wp-content/plugins/ dossier. Vous devriez maintenant pouvoir vous reconnecter. Trouvez une alternative pour la fonctionnalité que vous vouliez.
Si vous n'êtes pas sûr du plugin qui a causé l'erreur, vous devez renommer l'intégralité de wp-content/plugins/ dossier lui-même. Placez un trait de soulignement ("_ ") devant, il s'appelle donc _plugins .
En renommant le dossier, vous désactivez efficacement tous les plugins à la fois. Vous devriez maintenant pouvoir vous reconnecter, mais vous serez accueilli par une liste de messages d'erreur de WordPress indiquant "Le plugin quelque chose.php a été désactivé en raison d'une erreur :le fichier du plugin n'existe pas."
Ne vous inquiétez pas, vous n'avez perdu aucun paramètre. Les paramètres des plugins sont stockés dans la base de données et la plupart des plugins les retrouveront lors de la réactivation.
Ensuite, renommer le dossier à nouveau , en supprimant le trait de soulignement. Ils seront tous répertoriés sur votre page Plugins, mais dans un état désactivé. Vous pouvez maintenant les réactiver un par un jusqu'à ce que vous trouviez le coupable.
Lorsque le site plante à nouveau, répétez le processus, mais cette fois ne réactivez pas le plugin cassé !
La désactivation des plugins n'a pas aidé ? Cela peut être quelque chose à voir avec votre thème alors. Tout comme les plugins, vous pouvez désactiver de force le thème actif en renommant simplement son dossier, que vous trouverez dans le wp-content/themes/ répertoire.
Si vous ne pouvez toujours pas accéder à la zone d'administration après avoir essayé de renommer à la fois les plugins et votre thème actuel, vous devez continuer avec les étapes suivantes. Si vous pouvez vous connecter, WordPress vous avertira qu'il est revenu à un thème par défaut. À ce stade, vous pouvez soit trouver un nouveau thème, contacter le développeur du thème pour obtenir de l'aide, soit essayer de le réparer vous-même.
Pour le réparer vous-même ou pour fournir des explications supplémentaires au développeur, consultez la section plus loin sur Activer le mode de débogage de WordPress .
Si la désactivation de vos plugins et de votre thème n'a rien donné, il est possible que votre .htaccess le fichier a été corrompu d'une manière ou d'une autre. C'est généralement le cas si vous pouvez toujours accéder à la zone d'administration du site, mais que le frontal ne fonctionne pas correctement.
Le fichier .htaccess gère la conversion des permaliens (de jolies versions d'une URL comme /my-blog-post ), au schéma d'URL interne laid de WordPress (celui que vous obtenez par défaut, qui ressemble à /? p=12345). C'est une partie essentielle de WordPress, mais les plugins peuvent parfois le gâcher.
Encore une fois, rendez-vous sur votre client FTP ou votre gestionnaire de fichiers. Renommez le .htaccess fichier à la racine de votre répertoire d'installation WordPress à quelque chose comme .htaccess_old . Si vous ne pouvez pas voir le fichier ici, vous devez activer l'affichage des fichiers cachés ---la méthode exacte de le faire variera en fonction de votre client FTP.
Le point au début du nom de fichier est une façon de dire "masquer ce fichier" sous Linux et d'autres systèmes de type UNIX.
Une fois que vous avez renommé le .htaccess actuel, revenez à la zone d'administration de WordPress, puis rendez-vous dans Paramètres > Permaliens et, sans apporter de modifications, appuyez sur Enregistrer. Cela générera automatiquement une nouvelle version de travail du fichier.
Si vous avez apporté des modifications au fichier manuellement, celles-ci seront perdues (mais vous ne devriez pas modifier le fichier à la main de toute façon).
Nous pouvons activer un journal de débogage à partir de la configuration de WordPress, ce qui pourrait donner un indice sur le problème exact, mais à ce stade, vous êtes seul. Vous devrez trouver comment le réparer, ce qui nécessitera des compétences en codage.
Pour activer le journal de débogage, ouvrez wp-config.php , que vous trouverez dans le répertoire racine de votre installation WordPress. Soyez très prudent lorsque vous modifiez ce fichier :il peut être judicieux de faire d'abord une copie que vous pourrez annuler en cas de modifications involontaires.
Trouvez la ligne qui dit :
define('WP_DEBUG', false);
Si votre site n'est pas fréquemment visité et que les messages d'erreur affichés pour tout le monde ne vous dérangent pas, changez simplement le mot faux à vrai . Les messages d'erreur seront désormais affichés lorsque vous chargez le site.
Si vous préférez garder les messages d'erreur privés, commentez cette ligne en tapant // au début, puis collez ce qui suit en dessous :
define('WP_DEBUG', true);
définir('WP_DEBUG_LOG', vrai);
définir('WP_DEBUG_DISPLAY', faux);
@ini_set('display_errors',0);
Cela commencera à générer des erreurs dans un fichier dans wp-content dossier appelé error.log . Si vous actualisez le client FTP et ne voyez rien après environ une minute, il est possible que WordPress n'ait pas l'autorisation de créer le fichier. Créez manuellement un nouveau fichier error.log et donnez-lui la permission 666.
Soyez averti :ce fichier continuera de grossir jusqu'à ce que vous supprimiez ces lignes de votre fichier de configuration. N'oubliez pas de décommenter également la ligne d'origine. Lisez le fichier dans n'importe quel éditeur de texte et vérifiez s'il y a des erreurs PHP critiques.
Dans l'exemple, je vois beaucoup d'avis PHP sur le code obsolète, mais ceux-ci ne vont pas réellement casser un site.
Exécuter votre propre serveur privé virtuel n'est pas facile. Une fois, j'ai été confronté à un cas mystérieux où environ la moitié de tous les chargements de pages affichaient une erreur 500, mais sans motif perceptible ni indice dans les journaux d'erreurs du serveur. L'activation des journaux de débogage de WordPress n'a rien montré d'évident non plus :beaucoup d'avis et d'obsolescences PHP, mais rien de critique.
Enfin, j'ai réalisé que j'avais installé la mise en cache APC sur le serveur le week-end précédent, à utiliser avec W3 Total Cache afin d'accélérer le site. La désinstallation qui a complètement éradiqué les 500 erreurs.
Mon point est que l'erreur 500 pourrait simplement être une combinaison de configurations de serveur qui présentent une incompatibilité. Cela est peu probable si vous utilisez des services gérés, mais avec votre propre serveur privé virtuel (qu'est-ce qu'un serveur virtuel et pourquoi vous en voulez un), vous êtes responsable de vous assurer que tout fonctionne ensemble, et c'est plus difficile qu'il n'y paraît .
Sur un hébergeur partagé, vous pouvez trouver la limite de mémoire PHP est touché --- WooCommerce, les forums ou les plugins de publications connexes peuvent en être la cause en raison de leur complexité. Si vous avez de la chance, vous verrez un message d'erreur du type "Erreur fatale :taille de mémoire autorisée de xxx octets épuisée", mais pas toujours.
Vous pourrez peut-être résoudre ce problème en ajoutant la ligne suivante à votre wp-config.php :
define('WP_MEMORY_LIMIT', '64M'); Cependant, la plupart des hôtes partagés ne vous permettent pas d'augmenter la limite de mémoire --- vous obtenez ce qu'on vous donne. Il est peut-être temps d'envisager d'autres formes d'hébergement.
La meilleure défense contre tout type d'erreur WordPress critique est de maintenir des sauvegardes quotidiennes ainsi qu'une sauvegarde manuelle avant chaque action importante (comme une mise à jour principale de WordPress). Gardez également les plugins et les thèmes à jour :les nouvelles versions de WordPress cassent fréquemment l'ancien code.
Cela peut être effrayant lorsque votre site tombe en panne, surtout s'il s'agit d'une source de revenus pour vous et pas seulement d'un passe-temps. En suivant ce guide et en étant méthodique, vous devriez le retrouver bientôt.
Envisagez de passer à un service d'hébergement WordPress géré qui gère les sauvegardes et les optimisations pour vous, rendant ces erreurs inexistantes. Nous recommandons InMotion Hosting (utilisez ce lien pour obtenir 38 % de réduction) et Bluehost (utilisez ce lien pour obtenir 25 % de réduction).