Désactiver l'éditeur de fichiers WordPress après un incident
`DISALLOW_FILE_EDIT` évite qu'un administrateur — ou le voleur de sa session — réécrive le thème depuis l'admin. Ça ne remplace pas le nettoyage. Ça ferme une commodité dangereuse, une fois le site propre, ou tout de suite si vous savez encore écrire dans `wp-config`.
DISALLOW_FILE_EDIT évite qu'un admin (ou un voleur de session) réécrive le thème depuis l'admin. Ça ne remplace pas le nettoyage. Ça ferme une commodité dangereuse.
Ce que l'éditeur de thème permet vraiment
Apparence → Éditeur : n'importe quel admin colle du PHP dans `header.php` ou `functions.php`. Pas de SFTP. Pas de revue. Une session volée, un compte `agence` oublié, et le thème est la porte. Moins spectaculaire qu'un webshell à la racine, même effet.
L'éditeur de plugins fait la même chose dans `wp-content/plugins`. Un attaquant n'a pas besoin d'uploader s'il peut sauver un fichier existant.
C'est une fonctionnalité de confort pour les sites « on bricole en ligne ». Après un incident, ce confort est une récidive en un clic. On le coupe.
Ce que la constante ne fait pas
Elle n'enlève pas un PHP déjà écrit. Elle n'empêche pas le SFTP, ni un plugin vulnérable, ni GTM. Elle n'est pas un antivirus. Les dossiers qui « posent DISALLOW et s'arrêtent » reviennent.
Elle n'empêche pas `DISALLOW_FILE_MODS` d'être plus large (plus d'install de plugins via l'admin). On peut poser les deux, ou seulement l'édition. Distinguez : éditer ≠ installer.
Elle ne remplace pas la révocation des admins. Un admin avec SFTP n'a pas besoin de l'éditeur. Comptes.
Quand la poser : pendant ou après
Si vous avez encore la main sur `wp-config.php` et que des sessions admin sont douteuses : posez-la tout de suite, ça réduit la suite. Si `wp-config` a pu être lu, régénérez aussi les clés AUTH, tournez les secrets. L'ordre des mots de passe tient.
Si vous n'êtes pas à l'aise avec `wp-config`, ne le « tentez pas » au milieu d'une 500. Posez la constante à la clôture, une fois le site stable. Un `wp-config` cassé (quote, PHP) éteint tout le site. Copie avant.
Un nettoyeur sérieux la pose en fin d'intervention, et le dit dans le constat. Relisez le devis : ce n'est pas un extra facturable à part, c'est une ligne de fermeture.
Plugin editor, installateur, et le reste
`DISALLOW_FILE_EDIT` cache éditeur thème et plugins. L'installateur de plugins / thèmes reste, sauf `DISALLOW_FILE_MODS`. Après un incident, interdire l'install depuis l'admin a du sens sur une vitrine stable : les mises à jour se font par un circuit que vous maîtrisez (SFTP, CI). Sur une boutique qui vit d'extensions, c'est un arbitrage : plus dur à vivre, plus dur à contourner pour un admin volé.
L'éditeur de fichiers n'est pas l'éditeur de contenus (Gutenberg). Vous continuez d'écrire des articles. Vous arrêtez d'écrire du PHP dans l'UI.
Les plugins « file manager » dans l'admin sont pire que l'éditeur natif. S'il y en a un, c'est souvent LA porte. File manager. Il sort, il ne se « désactive pas pour plus tard ».
Ceux qui « ont besoin » d'éditer en prod
Le freelance qui n'a pas Git, l'agence qui « ajuste le CSS en live ». Après un piratage, ce workflow n'est plus acceptable sur la prod. Staging, thème enfant versionné, déploiement. C'est plus lent. C'est le prix d'une session volée qui ne réécrit plus `functions.php` à 3 h.
Un CSS custom via l'customizer ou Elementor reste possible (et reste une surface : relisez-le). Ce n'est pas du PHP serveur.
Si quelqu'un pose la réactivation de l'éditeur comme condition de maintenance, c'est un critère de prestataire. Accès.
Thème enfant et le vrai circuit
Les vrais correctifs passent par le thème enfant, un dépôt, une revue. L'éditeur admin court-circuite ça et, souvent, écrase ou diverge du dépôt. Après incident, alignez prod et dépôt. Si le dépôt n'existe pas, c'est le moment d'en créer un — à froid, pas une refonte.
Un `functions.php` déjà injecté se nettoie par comparaison, pas en « sauvant » depuis l'éditeur. L'éditeur est le problème, pas l'outil de réponse.
Headless : l'éditeur WP ne touche pas Next, mais il touche encore les plugins et le thème d'admin. Posez la constante quand même. Headless.
Vérifier que c'est pris en compte
Reconnectez-vous : les menus Éditeur ont disparu. Un mu-plugin ou un « security » peut les cacher sans la constante : insuffisant. Lisez `wp-config` (hors web si possible) pour voir la ligne. Si `wp-config` n'est pas à vous (hébergeur géré), le panel a parfois un équivalent ; sinon un must-use que VOUS posez, plus dur à tenir.
Cache objet : rare, mais un vieux `wp-config` cuit n'existe pas — `wp-config` n'est généralement pas caché ainsi. Le cache page n'affecte pas l'admin. Si l'éditeur réapparaît, quelqu'un a transmis un `wp-config` sans la ligne (restauration).
Sauvegarde Updraft : une resto peut ramener un `wp-config` ancien. Revérifiez après toute restauration.
Dans une checklist de clôture
À côté de 2FA, révocation, `DISALLOW_FILE_EDIT`, plus de file manager, plus de PHP in post. Petits interrupteurs, grand effet sur la récidive par admin.
Documentez-le dans le constat : posé, date. Un assureur comprend. Un successeur aussi.
Créer un compte : nous le posons en fin d'intervention sauf si vous avez un circuit qui l'interdit (certains hébergeurs managés). On le dit avant, on ne le facture pas comme une option mystère.