# Éditeur de code désactivé : le réactiver en urgence sans risque > Un client bloqué en plein incident, un accès SFTP perdu, et l'éditeur de thème verrouillé par sécurité. Voici comment intervenir proprement sans rouvrir une faille durable. - Auteur : Clément Hadrot - Publié le : 2024-06-04 - Mis à jour le : 2024-06-04 - Catégorie : Thèmes - URL : https://wpmoderne.dev.wordpress-developpement.fr/themes/editeur-code-desactive-reactiver-urgence/ ## L’essentiel - DISALLOW_FILE_EDIT bloque l'éditeur mais pas tout accès fichier - WP-CLI reste disponible même admin verrouillé - Toujours restaurer la constante après l'intervention Vendredi 17h, un client nous appelle : son site affiche une erreur critique après une modification malheureuse d'un fichier de thème, et il n'a plus accès SFTP — le mot de passe a été changé par un ancien prestataire et personne ne le retrouve dans l'urgence. Pire, l'éditeur de thème intégré à l'administration WordPress est désactivé, comme il se doit sur un site en production correctement sécurisé. Ce scénario, ou une variante proche, revient régulièrement dans nos interventions d'urgence. Il existe une solution propre, qui ne consiste pas à rouvrir une faille de sécurité en urgence puis à l'oublier. ## Comprendre ce que bloque réellement DISALLOW_FILE_EDIT La constante `DISALLOW_FILE_EDIT`, définie à `true` dans `wp-config.php`, désactive l'éditeur de thème et de plugins intégré à l'administration (menus Apparence > Éditeur de fichiers de thème et équivalent plugins). C'est une recommandation de sécurité standard : sans elle, n'importe quel compte administrateur compromis peut injecter du code PHP arbitraire directement depuis le navigateur, sans même avoir besoin d'un accès serveur. Ce que cette constante ne bloque pas : un accès direct aux fichiers par SFTP, SSH ou WP-CLI reste pleinement fonctionnel. Le problème du client n'était donc pas l'éditeur désactivé en lui-même, mais l'absence de tout autre moyen d'accès au serveur au moment de l'incident. ## Diagnostic avant toute intervention > L'essentiel à retenir : DISALLOW_FILE_EDIT bloque l'éditeur mais pas tout accès fichier ; WP-CLI reste disponible même admin verrouillé ; Toujours restaurer la constante après l'intervention Avant de réactiver quoi que ce soit, nous avons d'abord cherché un accès alternatif déjà disponible : un accès SSH existant sur l'hébergement, une interface web du panneau d'hébergement permettant l'édition de fichiers, ou un accès WP-CLI via une tâche cron déjà configurée par l'hébergeur. Dans ce cas précis, l'hébergeur proposait un accès WP-CLI via son propre terminal web, ce qui a suffi à résoudre l'incident sans toucher à `DISALLOW_FILE_EDIT`. ## La procédure WP-CLI, sans passer par l'éditeur Quand un accès en ligne de commande existe, la correction du fichier fautif ne nécessite jamais l'éditeur de thème. On identifie d'abord le fichier en cause à partir du message d'erreur, souvent affiché directement si `WP_DEBUG` est actif, sinon dans le journal d'erreurs du serveur : ``` # Localiser le thème actif et son chemin wp theme list --status=active --path=/var/www/html # Consulter le journal d'erreurs PHP le plus recent tail -n 50 wp-content/debug.log # Restaurer un fichier depuis une sauvegarde connue via WP-CLI wp eval 'copy("wp-content/backups/functions.php.bak", "wp-content/themes/theme-actif/functions.php");' ``` Cette dernière commande suppose qu'une sauvegarde du fichier existe déjà quelque part sur le serveur ou dans un outil de sauvegarde ; c'est une bonne raison supplémentaire de toujours conserver une copie avant toute modification manuelle en production. ## Si aucun accès alternatif n'existe vraiment Dans les cas où aucun accès serveur n'est disponible et où seul l'accès administrateur WordPress fonctionne, réactiver temporairement l'éditeur reste une option de dernier recours, mais encadrée strictement : - Commenter la ligne `define( 'DISALLOW_FILE_EDIT', true );` dans `wp-config.php` via la seule interface encore disponible (souvent un gestionnaire de fichiers du panneau d'hébergement, pas l'éditeur de thème lui-même). - Effectuer uniquement la correction strictement nécessaire, sans explorer d'autres fichiers par curiosité. - Remettre immédiatement la constante à `true` une fois l'incident résolu, avant de clore l'intervention. - Changer les mots de passe administrateur si le contexte de l'incident laisse un doute sur une compromission plutôt qu'une simple erreur humaine. > Une constante de sécurité qu'on désactive « juste le temps de » et qu'on oublie de remettre est une des causes les plus bêtes de compromission que nous ayons constatées sur des sites clients. ## Prévention pour la prochaine fois Cet incident a débouché sur une recommandation systématique pour tous nos clients hébergés : conserver en permanence un accès SSH ou WP-CLI documenté et testé, indépendant du seul compte administrateur WordPress. Un site qui ne dépend que de l'interface d'administration pour toute intervention technique se retrouve otage du moindre verrouillage, qu'il soit volontaire (sécurité) ou accidentel (mot de passe perdu). ## En résumé `DISALLOW_FILE_EDIT` reste une bonne pratique de sécurité qu'il ne faut jamais désactiver durablement. Face à une urgence, la bonne réaction est de chercher d'abord un accès alternatif au serveur (SSH, WP-CLI, panneau d'hébergement) avant d'envisager de rouvrir temporairement l'éditeur intégré, et de refermer systématiquement cette porte dès l'incident résolu.