Moins, c'est plus : faire le tri et résoudre les conflits

Module 5: Thèmes et extensions · Temps de lecture : 9 minutes

Objectif pédagogique : après cette leçon, vous saurez faire le tri dans vos extensions et repérer puis résoudre vous-même un conflit ou une page blanche.

Notions clés : désactiver vs supprimer, code inactif, erreur critique, mode de récupération (recovery mode), Santé du site, mode de résolution de problèmes, renommer le répertoire d'une extension, WP_DEBUG, WP_DEBUG_LOG, debug.log, journal d'erreurs

Désactiver n'est pas supprimer

Dans Extensions, vous pouvez désactiver ou supprimer une extension. La différence :

• Désactiver : WordPress ne charge plus l'extension. Mais les fichiers restent dans wp-content/plugins/, et sont souvent encore directement accessibles via le serveur web. S'il y a une faille dans un fichier PHP isolé de cette extension, cette faille existe toujours. Les pirates scannent les fichiers vulnérables connus, pas les extensions actives.
• Supprimer : les fichiers disparaissent. Certaines extensions nettoient aussi leurs réglages et leurs tables dans la base de données à la suppression ; d'autres les laissent en place.

Si vous n'utilisez plus une extension, supprimez-la. La désactivation n'est que temporaire (pendant la recherche d'un problème). Il en va de même pour les thèmes (leçon 2.4).

Faire le tri : une ronde régulière

Passez en revue vos extensions une fois par trimestre (leçon 9.4). Pour chaque extension :

1. À quoi sert-elle ? Si vous ne vous en souvenez plus, renseignez-vous. Il arrive souvent qu'une extension ait été installée un jour pour une seule chose et jamais retirée depuis.
2. Est-elle encore utilisée ? Une extension de diaporama alors qu'il n'y a de diaporama nulle part, une extension de formulaire alors que votre page de contact utilise un autre formulaire.
3. Peut-on s'en passer ? Est-ce que WordPress, le thème ou une autre extension le fait déjà (leçon 5.3) ?
4. Est-elle encore maintenue ? Dernière mise à jour, toujours présente dans le répertoire des extensions ?

Faites d'abord ce nettoyage sur un site de préproduction (staging) (leçon 8.3), ou faites au moins une sauvegarde, et supprimez une extension à la fois afin de savoir ce qui a posé problème en cas de souci. Attention aux shortcodes : si vous supprimez une extension qui fournissait [formulier id="2"], ce texte apparaîtra ensuite littéralement sur votre page.

Quand ça tourne mal : l'erreur critique

Après une mise à jour, une nouvelle extension ou une mise à niveau PHP, vous voyez soudain :

Il y a eu une erreur critique sur ce site.

ou une page entièrement blanche. Cela signifie que PHP s'est arrêté sur une erreur fatale avant qu'une page ne soit générée (leçon 1.2). C'est généralement dû à une extension ou un thème incompatible avec autre chose : une autre extension, la nouvelle version de WordPress, ou la version de PHP.

Depuis WordPress 5.2, WordPress fait alors deux choses :

• il envoie un e-mail à l'adresse de l'administrateur indiquant quelle extension ou quel thème a provoqué l'erreur, avec un lien spécial ;
• ce lien vous permet de vous connecter en mode de récupération (recovery mode) : l'administration fonctionne alors, l'extension fautive étant temporairement désactivée, ce qui vous permet de la mettre à jour, de la remplacer ou de la supprimer.

C'est pourquoi il est si important d'avoir une adresse d'administrateur que vous consultez réellement (leçon 2.2).

Chercher soi-même : les étapes

Vous ne recevez aucun e-mail, ou le mode de récupération ne fonctionne pas ? Voici comment trouver vous-même la solution.

1. Consultez le journal d'erreurs

L'erreur se trouve presque toujours dans le journal d'erreurs du serveur web ou de PHP. Sous DirectAdmin, vous le trouvez dans les journaux de votre domaine. Cherchez une ligne contenant PHP Fatal error et l'heure de votre tentative :

PHP Fatal error:  Uncaught Error: Call to undefined function create_function()
in /home/gebruiker/domains/example.com/public_html/wp-content/plugins/oude-slider/slider.php:42

Le chemin vous indique le coupable : ici, l'extension dans le répertoire oude-slider. Le reste de la ligne indique pourquoi (ici : une fonction supprimée dans PHP 8, leçon 8.4).

2. Activez le journal de débogage (pas l'affichage à l'écran)

Rien d'exploitable dans le journal d'erreurs ? Ajoutez alors dans wp-config.php (au-dessus de « stop toute modification ») :

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

WordPress écrit alors toutes les erreurs dans wp-content/debug.log, sans les afficher aux visiteurs. Ne laissez jamais cette option activée plus longtemps que nécessaire : debug.log se trouve dans un répertoire exposé par le serveur web, et quiconque en connaît l'adresse peut le lire. On y trouve des chemins, parfois des noms d'utilisateur et d'autres informations qui facilitent la tâche d'un pirate. Désactivez-le à nouveau une fois la recherche terminée et supprimez debug.log. Ou bien laissez WordPress écrire le fichier journal en dehors du répertoire web en indiquant un chemin pour WP_DEBUG_LOG (par exemple '/home/gebruiker/logs/wp-debug.log', si votre hébergeur l'autorise). À la leçon 7.4, vous vérifierez que debug.log n'est pas accessible publiquement.

3. Désactiver une extension sans accès à l'administration

Vous n'arrivez pas à accéder à l'administration ? Désactivez alors l'extension suspecte en renommant son répertoire, via le Gestionnaire de fichiers ou en SFTP :

wp-content/plugins/oude-slider   wordt   wp-content/plugins/oude-slider-uit

WordPress ne trouve alors plus l'extension et la désactive. Si vous ne savez pas laquelle est en cause, renommez tout le répertoire plugins en plugins-uit : toutes les extensions sont alors désactivées. Si le site fonctionne de nouveau, créez un nouveau répertoire plugins vide, réactivez les extensions une par une et vérifiez après chacune si l'erreur revient. Pour un thème, c'est pareil : renommez le répertoire du thème actif et WordPress revient à un thème par défaut, s'il en reste un (leçon 2.4).

4. Les conflits sans erreur fatale

Tout problème n'est pas une erreur critique. Parfois, une seule fonctionnalité ne marche pas : un bouton ne réagit pas, le formulaire ne s'envoie pas, l'éditeur se charge à moitié. C'est souvent un conflit entre deux extensions ou entre une extension et le thème. Pour cela, l'extension officielle Health Check & Troubleshooting est pratique : en mode de résolution de problèmes, elle désactive toutes les extensions uniquement pour votre session et bascule vers un thème par défaut, tandis que les visiteurs continuent de voir le site normal. Réactivez-les ensuite une par une jusqu'à ce que le problème réapparaisse.

Regardez aussi dans la console de votre navigateur (F12) : les erreurs JavaScript indiquent souvent le fichier, et donc l'extension, en cause.

Santé du site

Sous Outils > Santé du site, WordPress vérifie lui-même votre site : version de PHP obsolète, extensions et thèmes non actifs, extensions PHP manquantes, API REST qui ne fonctionne pas, tâches planifiées en retard. Dans l'onglet Infos figurent toutes les données de votre installation (versions, chemins, réglages PHP). Cet onglet peut être copié et transmis si vous demandez de l'aide. Consultez-le après chaque modification importante.

Résumé

• La désactivation laisse les fichiers en place ; supprimez les extensions et thèmes que vous n'utilisez pas.
• Faites le tri chaque trimestre, une extension à la fois, avec une sauvegarde ou sur un site de préproduction (staging).
• En cas d'erreur critique, WordPress envoie un e-mail avec un lien vers le mode de récupération.
• Le journal d'erreurs ou debug.log indique le chemin du coupable ; désactivez le débogage une fois la recherche terminée, car debug.log est sinon accessible publiquement.
• Sans accès à l'administration, désactivez une extension en renommant son répertoire ; recherchez les conflits avec le mode de résolution de problèmes.

Quiz

Exercice

Exercice A5.4 : Votre journal de débogage n'est-il pas public ? Indiquez l'adresse de votre site et prouvez, avec le code fourni par l'exercice, qu'il s'agit bien de votre propre site (un enregistrement TXT ou un petit fichier). Le programme demande /wp-content/debug.log : c'est bon si ce fichier n'existe pas ou si l'accès est refusé (404 ou 403). Si le programme reçoit un fichier en retour, c'est signalé en rouge. Le programme compte également combien de répertoires d'extensions différents apparaissent dans le HTML de votre page d'accueil (à titre purement informatif).

Exercice D5.4 : Faire le tri dans votre liste d'extensions. Dressez la liste de toutes vos extensions (actives et inactives) : nom, à quoi elle sert, encore nécessaire (oui/non), alternative sans extension. Supprimez (après une sauvegarde ou sur un site de préproduction (staging)) les extensions qui ne sont plus nécessaires, une à la fois, et vérifiez après chaque suppression que le site fonctionne toujours. Indiquez combien d'extensions vous aviez et combien il en reste, et notez s'il subsistait des shortcodes que vous avez dû nettoyer.

Pour aller plus loin

Ces articles décrivent les étapes dans les panneaux de WebOké ; dans d'autres panneaux, le fonctionnement est comparable.

• Guide DirectAdmin 18.1: Mon site web est blanc ou affiche une erreur 500
• Erreur 500 ou « erreur critique » sur votre site web (également après une mise à jour de WordPress)
• Guide DirectAdmin 14.6: Erreurs après une mise à niveau de PHP et trouver le journal des erreurs
• Guide DirectAdmin 17.2: Résumé du site & journaux : le journal des erreurs et le journal d'accès
• Comment déboguer PHP sans modifier le php.ini ?
• Déboguer dans WordPress (developer.wordpress.org, en anglais) : https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/