Que faire quand un plugin modifie votre fichier .htaccess ?

Sur un site WordPress hébergé sous Apache, le fichier de configuration local est un point de passage obligé et un espace partagé. WordPress y écrit ses règles de réécriture, et un grand nombre d'extensions y ajoutent les leurs : cache, sécurité, redirections, protection de dossiers, compression, en têtes de mise en cache. Quand plusieurs programmes écrivent dans le même fichier sans se concerter, les modifications du fichier .htaccess par un plugin deviennent une source d'incidents difficiles à diagnostiquer, dont le plus spectaculaire est l'erreur 500 qui rend le site entièrement inaccessible, y compris son administration, et dont la cause n'apparaît nulle part à l'écran. Quelques précautions suffisent pourtant à rendre cette cohabitation sereine, et elles tiennent davantage à des habitudes de travail qu'à des connaissances avancées en configuration de serveur.

Comprendre qui écrit quoi

La première étape consiste à savoir ce que contient le fichier et qui en est responsable, ce qui n'est pas toujours évident sur un site repris. Cette lecture s'appuie sur les notions générales exposées dans notre article consacré au fichier htaccess.

Les blocs délimités par des marqueurs

La convention établie par WordPress, reprise par la plupart des extensions sérieuses, consiste à encadrer les règles gérées automatiquement par deux commentaires marquant le début et la fin d'un bloc nommé. Tout ce qui se trouve entre ces marqueurs est susceptible d'être réécrit sans préavis, à chaque changement de réglage, à chaque mise à jour et parfois à chaque enregistrement d'un contenu. Tout ce qui se trouve à l'extérieur est en principe préservé, et c'est là que doivent vivre les règles écrites à la main.

Les extensions qui n'utilisent pas de marqueurs

Certaines extensions ajoutent leurs directives sans les délimiter, ce qui rend impossible de savoir ce qui leur appartient. Le repérage se fait alors par recoupement : on note le contenu du fichier, on désactive l'extension, on compare. C'est fastidieux et cela ne se fait qu'une fois. Une extension qui écrit sans marqueurs est par ailleurs un mauvais signe sur sa qualité générale, et ce constat entre légitimement dans le choix d'un remplaçant, au même titre que la fréquence de ses mises à jour.

Les règles orphelines

Sur un site de quelques années, le fichier contient presque toujours des blocs d'extensions désinstallées depuis longtemps, la désinstallation ne nettoyant pas toujours ce qu'elle a écrit. Ces règles continuent de s'appliquer, parfois avec des effets réels : une redirection vers un dossier disparu, une interdiction sur un chemin devenu utile, une directive de compression en double. Leur identification passe par la lecture des noms de blocs, et leur suppression est en général sans risque après vérification. La prudence commande de retirer un bloc à la fois, en testant entre chaque, plutôt que de nettoyer d'un coup un fichier dont on découvre l'historique.

L'ordre, qui décide de tout

Le fichier est lu de haut en bas, et la première règle de réécriture qui correspond et se termine par un arrêt met fin au traitement. Une règle correcte placée après le contrôleur frontal de WordPress ne sera jamais atteinte, puisque celui ci capture tout ce qui n'est pas un fichier réel. C'est la cause la plus fréquente de règle qui semble ne rien faire, et elle n'a rien à voir avec sa syntaxe : elle est simplement écrite au mauvais endroit. Le déplacement de quelques lignes vers le haut du fichier suffit alors à la faire fonctionner, sans en changer un caractère.

Ce qui n'a pas sa place dans ce fichier

Beaucoup de ce que l'on y écrit gagnerait à figurer dans la configuration principale du serveur, quand on y a accès : c'est plus rapide, puisque le fichier local est relu à chaque requête et pour chaque dossier traversé. Sur un serveur dédié ou une machine virtuelle, désactiver la prise en compte de ces fichiers et déplacer les règles dans la configuration principale apporte un gain mesurable. Sur un hébergement mutualisé, la question ne se pose pas, ce fichier étant le seul levier disponible. Il faut alors accepter son coût, qui reste modeste tant que le fichier est court et que l'arborescence n'est pas profonde.

Le cas des serveurs qui ne lisent pas ce fichier

Une part croissante des hébergements ne tourne plus sous Apache mais sous un serveur qui ignore complètement ces fichiers, ou sous une architecture où un serveur léger se place devant. Le fichier reste alors présent, les extensions continuent d'y écrire, et rien de ce qu'il contient ne s'applique. C'est un piège particulièrement désagréable : les règles de sécurité que l'on croit actives ne le sont pas, les redirections écrites n'ont aucun effet, et aucun message ne le signale. La vérification tient en une manipulation, ajouter une règle de redirection évidente et vérifier qu'elle s'applique. Si elle est ignorée, tout ce qui a été écrit dans ce fichier depuis des années doit être transposé dans la configuration du serveur réellement utilisé, ce qui est un chantier à part entière mais qui vaut mieux qu'une protection imaginaire.

Éviter les conflits

Une fois la cartographie faite, quelques règles d'organisation évitent la quasi totalité des incidents. Elles relèvent de la même discipline que celle décrite dans notre article sur la manière de surveiller les mises à jour de plugins avec WP-CLI.

Écrire ses propres règles dans un bloc identifié

Les règles écrites à la main doivent être encadrées par des marqueurs portant un nom explicite, propre au projet, avec la date et le motif en commentaire. Cela ne les protège pas techniquement d'une réécriture, mais cela permet à quiconque ouvre le fichier de savoir immédiatement ce qui est géré par un humain. Sur les sites que nous reprenons, ce simple usage réduit d'emblée le temps de compréhension du fichier à quelques minutes. Le même bloc sert de point de restauration : si une extension l'écrase, on sait exactement ce qu'il faut remettre.

Placer ses règles avant celles de WordPress

Les règles personnalisées qui doivent s'appliquer avant le routage, redirections d'anciennes adresses, réécritures de compatibilité, interdictions ciblées, doivent figurer au dessus du bloc géré par WordPress. C'est le seul emplacement qui garantit qu'elles seront atteintes. Les directives qui ne sont pas des réécritures, en têtes ou règles de mise en cache par exemple, sont moins sensibles à l'ordre et peuvent se placer en fin de fichier, où elles resteront lisibles sans gêner le routage.

Limiter le nombre d'extensions qui écrivent

Deux extensions de cache, deux extensions de sécurité ou deux gestionnaires de redirections écrivent chacune leur bloc, et leurs directives se contredisent. Le symptôme classique est un comportement qui change selon l'ordre d'activation, ce qui est impossible à diagnostiquer sans lire le fichier. La règle est la même que pour le reste de la pile : une seule extension par fonction, choisie et assumée. Quand deux extensions sont réellement nécessaires, il faut au minimum vérifier que leurs blocs ne se recouvrent pas et fixer leur ordre explicitement.

Vérifier après chaque changement de réglage

Beaucoup d'extensions réécrivent le fichier au moment où l'on enregistre un réglage, y compris un réglage sans rapport apparent. Prendre l'habitude de comparer le fichier avant et après toute intervention sur une extension qui y touche prend dix secondes et évite de découvrir la modification trois semaines plus tard. Sur un site versionné, cette comparaison est automatique ; sinon, une copie datée du fichier avant intervention suffit. Conserver ces copies pendant quelques mois permet en outre de reconstituer l'historique des modifications quand un comportement inexpliqué apparaît.

Attention aux échappements

Les extensions qui exposent une zone d'édition du fichier depuis l'administration introduisent parfois des caractères d'échappement supplémentaires lors de l'enregistrement, transformant une expression valide en expression fausse. Le symptôme est une règle qui fonctionnait et cesse de fonctionner après un simple enregistrement sans modification. La parade consiste à ne jamais éditer ce fichier depuis une interface web, et à passer par un accès direct au serveur. Quand cet accès n'existe pas, il vaut mieux conserver une copie de référence hors du site et la comparer après chaque enregistrement, plutôt que de faire confiance à l'éditeur.

Prévoir l'écriture concurrente

Deux processus qui réécrivent le fichier au même moment produisent un résultat imprévisible, allant du bloc dupliqué au fichier tronqué. Le cas se présente plus souvent qu'on ne l'imagine sur un site actif, notamment quand une tâche planifiée et une action d'administration coïncident. Les extensions correctes utilisent un verrou et écrivent de manière atomique, en passant par un fichier temporaire renommé ensuite ; les autres écrivent directement, avec une fenêtre pendant laquelle le serveur peut lire un fichier incomplet et refuser toutes les requêtes. Cette différence de qualité n'est visible qu'en lisant le code de l'extension, ce que personne ne fait, mais elle explique une partie des erreurs 500 qui surviennent sans intervention humaine.

Diagnostiquer une erreur 500

C'est le scénario redouté : après une modification, le site entier répond une erreur serveur, administration comprise. La bonne nouvelle est que le diagnostic est rapide quand on procède dans l'ordre, à condition d'avoir un accès direct aux fichiers, ce qui fait partie des prérequis rappelés dans nos articles de la rubrique extensions WordPress.

Neutraliser le fichier en premier

Le premier geste consiste à renommer le fichier, ce qui le désactive instantanément. Si le site redevient accessible, la cause est identifiée et l'on peut travailler tranquillement ; si l'erreur persiste, le problème est ailleurs et l'on vient d'écarter une hypothèse en trente secondes. Sur un site WordPress, l'absence de ce fichier casse les adresses propres mais laisse l'accueil et l'administration fonctionner, ce qui suffit pour intervenir. Il faut penser à remettre le fichier en place une fois le problème corrigé, un site laissé sans adresses propres perdant l'ensemble de ses pages pour les visiteurs comme pour les moteurs.

Lire le journal des erreurs du serveur

Le journal d'erreurs d'Apache indique très précisément la ligne fautive et la nature du problème, information qu'aucune page d'erreur ne donne au visiteur. C'est le réflexe qui fait gagner le plus de temps, et pourtant celui qui est le moins pris. Sur un hébergement mutualisé, ce journal est en général accessible depuis le panneau de gestion, parfois avec quelques minutes de décalage. Sur les hébergements où il n'est pas accessible du tout, le passage temporaire du site en mode débogage ne sert à rien pour ce type d'erreur, qui se produit avant même l'exécution de PHP.

Chercher un module absent

La cause la plus fréquente n'est pas une faute de syntaxe mais une directive appartenant à un module non chargé sur le serveur. Une règle de compression sur un serveur sans le module correspondant, une directive d'en tête sans le module de gestion des en têtes, suffisent à produire une erreur immédiate. La parade consiste à envelopper toute directive dépendant d'un module dans un test de présence, ce que les extensions correctes font systématiquement et que les scripts trouvés en ligne omettent presque toujours. Cette précaution a un effet secondaire agréable : le même fichier devient transposable d'un hébergement à l'autre sans adaptation.

Réintroduire par moitiés

Quand le fichier est long et que la cause n'est pas évidente, la méthode la plus rapide reste la dichotomie : on remet la première moitié, on teste, puis on affine. Trois ou quatre essais suffisent à isoler la ligne fautive sur un fichier de cent lignes. Cette méthode mécanique évite de relire dix fois un fichier en cherchant une erreur qui, une fois trouvée, paraît évidente. Elle fonctionne aussi lorsque le fichier a été assemblé par plusieurs extensions et que personne ne sait plus quelle version était fonctionnelle.

Reprendre la main durablement

Au delà de l'incident, quelques dispositions rendent ce fichier gérable dans la durée, y compris par quelqu'un qui ne l'a pas écrit.

Le versionner

Ce fichier est de la configuration et mérite d'être suivi comme telle. Le placer dans un dépôt, ou à défaut en conserver une copie datée à chaque modification, permet de savoir ce qui a changé, quand et pourquoi. C'est aussi ce qui rend possible la restauration immédiate d'une version fonctionnelle, ce qui est bien plus rapide que de chercher l'erreur quand le site est indisponible. La copie doit être conservée ailleurs que sur le serveur concerné, un incident d'hébergement emportant les deux d'un coup.

Documenter chaque règle

Chaque règle écrite à la main doit être précédée d'un commentaire indiquant sa date, son auteur et son motif. Sans cela, personne n'osera jamais supprimer quoi que ce soit, et le fichier ne fera que croître indéfiniment, chaque intervenant ajoutant sa couche par précaution. Avec, une revue annuelle permet de retirer les règles devenues sans objet, notamment les redirections d'adresses que plus personne ne demande, ce qui se vérifie dans les journaux du serveur. Une règle dont l'origine n'a reçu aucune demande depuis douze mois peut être retirée sans crainte, la trace de sa suppression restant dans l'historique.

Surveiller les modifications

Une empreinte du fichier, calculée quotidiennement et comparée à la précédente, signale toute modification non prévue. C'est utile pour repérer une extension trop bavarde, et c'est aussi une mesure de sécurité : la modification de ce fichier est l'une des premières actions d'une compromission réussie, servant à rediriger une partie du trafic ou à autoriser l'exécution de fichiers déposés. Ces modifications malveillantes sont souvent placées en fin de fichier, ou noyées dans un bloc portant un nom d'apparence légitime, ce qui rend la comparaison automatique bien plus fiable que la lecture.

Savoir quand ne pas y toucher

Une part des règles que l'on est tenté d'y écrire ont un meilleur emplacement ailleurs. Les redirections liées au contenu se gèrent mieux dans le système de gestion, où elles sont visibles par l'équipe éditoriale et associées aux contenus concernés, avec un historique et une possibilité de recherche que ce fichier n'offre pas. Les en têtes de sécurité gagnent à être posés une fois dans la configuration du serveur. Réserver ce fichier aux règles qui doivent impérativement s'appliquer avant l'exécution du site le maintient court, et un fichier court est un fichier que l'on ose modifier. Un fichier de trois cents lignes accumulées sur huit ans finit toujours par être traité comme une boîte noire que personne ne veut ouvrir, ce qui est exactement la situation à éviter. La règle pratique consiste à retirer une directive devenue inutile chaque fois qu'on en ajoute une, ce qui maintient le fichier à une taille lisible sans jamais imposer de chantier de nettoyage dédié.