DISALLOW_FILE_EDIT et l'approche de co-débogage de WP

introductif

assezWordPressLes débutants, en particulier ceux qui s'initient à la gestion de sites web, peuvent être confrontés à un dilemme. D'une part, les développeurs chevronnés nous conseilleront tous de désactiver l'édition des thèmes et des plugins, ce qui signifie qu'il faut paramétrer l'option disallow_file_editEn revanche, lorsque nous voulons modifier rapidement un petit problème, l'"éditeur" familier en arrière-plan disparaît soudainement, ce qui est très gênant, comme s'il s'agissait d'un ensemble de "chaînes". D'autre part, lorsque nous voulons modifier rapidement un petit problème du site web, l'"éditeur" familier en arrière-plan disparaît soudainement, ce qui est très gênant, comme s'il s'agissait d'un ensemble de "chaînes".

DISALLOW_FILE_EDIT Isolation de l'environnement de débogage sécurisé

Dans ce billet, nous allons parler en profondeur de ce sujet apparemment contradictoire. Vous y trouverezdisallow_file_edit Non pas pour vous limiter, mais pour vous protéger. Plus important encore, nous explorerons ensemble un moyen plus sûr de vous débarrasser de votre dépendance à l'égard d'un éditeur de fichiers en arrière-plan.

Partie I : Comprendre DISALLOW_FILE_EDIT - Qu'est-ce que c'est vraiment ?

Avant d'entrer dans le vif du sujet, passons brièvement en revue le cœur de cette fonctionnalité.

1.1 Un simple interrupteur de sécurité

disallow_file_edit est un paramètre du système WordPress. Il s'agit d'un paramètre que vous pouvez définir lorsque vous ajoutez une page à la base de données de votre site. wp-config.php Ce fichier de configuration de base, ajoutez une ligne de code spécifique, le menu d'apparence du backend de WordPress sous le "Theme Editor" et le menu du plugin sous le "Plugin Editor" disparaîtront immédiatement.

DISALLOW_FILE_EDIT Spécification du code de débogage de sécurité

1.2 Sa mission principale : la prévention et l'isolement

Il existe pour deux raisons principales et très pratiques :

Protection contre les abus internes : Pour les utilisateurs ou les membres de l'équipe qui ne sont pas familiarisés avec le code, une légère erreur dans l'éditeur du backend, comme la suppression d'un point-virgule, peut transformer tout le frontend du site en "écran blanc", également connu sous le nom de "White Screen of Death" (écran blanc de la mort). La désactivation de cette fonction permet d'éliminer de tels accidents à la racine.
Augmenter la difficulté pour les intrus : En supposant que quelqu'un ait réussi à se connecter au backend de votre site web, il ne sera pas en mesure de modifier les fichiers centraux et d'introduire des codes malveillants directement par le biais de ces éditeurs. Cela ajoute une couche supplémentaire à la sécurité de votre site.

Partie II : Parapluie ou entrave ? --Deux points de vue

C'est là le cœur de la controverse. La même caractéristique, dans des scénarios différents, donne une impression très différente.

2.1 Pourquoi est-elle considérée comme un "parapluie" ?

Du point de vue de la stabilité et de la sécurité du site webdisallow_file_edit Sans aucun doute un parapluie fiable.

Maintenir la stabilité du site : Il garantit que le code du site en ligne (c'est-à-dire le site que l'utilisateur visite) n'est pas modifié au hasard. Toutes les modifications doivent passer par un processus plus contrôlé, par exemple être modifiées sur un ordinateur local, testées pour en vérifier l'exactitude, puis téléchargées sur le serveur.
Suivre les meilleures pratiques : Dans un processus professionnel de gestion et de développement de sites web, la modification du code directement sur le serveur de production est une pratique déconseillée. Ce paramètre vous oblige à prendre de meilleures habitudes.

2.2 Pourquoi a-t-on également l'impression d'avoir affaire à des "chaînes" ?

Ce sentiment est généralement dû aux inconvénients du processus de développement ou de débogage.

L'attrait de la "solution miracle" : Lorsqu'un petit problème survient sur un site web, l'idée la plus immédiate est d'aller dans le backend et de modifier le code, tout ira bien. En fermant l'éditeur, ce chemin "court et rapide" est coupé.
Le processus est devenu "lourd" : Maintenant, vous devez d'abord modifier le fichier sur votre ordinateur local, puis utiliser le FTP ou des outils de gestion de fichiers pour le télécharger et l'écraser, les étapes deviennent de plus en plus nombreuses et de moins en moins efficaces.

2.3 Redéfinition : ce n'est pas une entrave, c'est un panneau indicateur

En fait, ce "désagrément" est un rappel bienveillant. Il vous dit : "Hé, cette méthode est risquée, il y a un moyen plus sûr et plus professionnel de procéder". Il vous éloigne de ce raccourci semé d'embûches et vous oriente vers la voie de la commande professionnelle.

Partie III : Dites adieu à l'éditeur d'arrière-plan - adoptez un partenaire de débogage professionnel : WP_DEBUG

Quelle est donc la "solution de facilité" ? La réponse est d'utiliser les fonctions de débogage de WordPress, plutôt que de s'appuyer sur le dangereux éditeur du backend.

3.1 Qu'est-ce que WP_DEBUG ?

WP_DEBUG est une autre option de configuration de base de WordPress, que l'on trouve également dans la section wp-config.php fichier. On peut l'assimiler à un "voyant de défaut sur le tableau de bord d'une voiture".

Lorsqu'il se ferme, votre site, même s'il contient une erreur de code, peut se contenter d'afficher un écran blanc flou et vous n'avez aucune idée du problème.
Lorsqu'il est activé, il détecte activement toutes sortes d'erreurs, d'avertissements et de notifications dans votre code et les affiche clairement, en vous indiquant dans quel fichier et dans quelle ligne se trouve le problème.

3.2 Comment les deux fonctionnent-ils ensemble ?

disallow_file_edit répondre en chantant WP_DEBUG Ce ne sont pas des oppositions, mais des partenaires en or dans la division du travail.

disallow_file_edit La responsabilité principale de l'application est de mettre en œuvre des contrôles de sécurité. Il applique la normalisation du processus de modification du code en désactivant l'éditeur de fichiers intégré dans l'environnement de production. Cela permet de prévenir efficacement le risque d'abus dû à des modifications directes en ligne et d'élever le seuil de sécurité pour les accès non autorisés. Au fond, il établit la limite de sécurité "pas de modification en ligne"..
WP_DEBUGest de fournir des diagnostics sur les problèmes. Il s'exécute dans l'environnement de développement et révèle exactement les erreurs, les avertissements et les notifications présents dans le code. Il traduit les problèmes logiques cachés en rapports clairs qui aident les développeurs à localiser rapidement la cause première. Au fond, il répond à la question "Quel est le problème et pourquoi ?""

L'un est destiné à la "sécurité" et l'autre au "diagnostic". Ensemble, ils forment un environnement à la fois sûr et efficace pour identifier les problèmes.

Partie IV : Mise en place d'un processus de commissionnement de la sécurité

4.1 Principe de la séparation environnementale

Il s'agit du concept de base. Veuillez diviser votre environnement de travail en deux catégories :

Environnement de développement local : Sur votre propre ordinateur, utilisez la fonctionXAMPPetLocalWPet d'autres logiciels pour construire un environnement WordPress exactement comme le serveur en ligne.
Environnement de production en ligne : C'est-à-dire le site web que les utilisateurs visitent réellement. Il doit être stable et sûr.

4.2 Configuration correcte dans différents environnements

dans votre environnement de développement local :Vous pouvez conserver disallow_file_edit est désactivé (c'est-à-dire qu'il n'est pas défini ou qu'il est défini à false) pour que vous puissiez utiliser l'éditeur quand vous le souhaitez.Doit être allumé WP_DEBUGIl vous aide à trouver les erreurs en temps réel.

// Dans le fichier wp-config.php
 define('WP_DEBUG', true ) ;

Dans votre environnement de production en ligne : doit être activé disallow_file_editpour verrouiller l'édition du fichier.Doit être fermé WP_DEBUGLes messages d'erreur détaillés ne doivent pas être divulgués aux visiteurs du site (ce qui constitue en soi un risque pour la sécurité).

// dans le fichier wp-config.php
define('DISALLOW_FILE_EDIT', true ) ;
define('WP_DEBUG', false ) ;

4.3 Techniques de débogage en ligne plus avancées

Les sites en ligne ont parfois des problèmes et des écrans blancs, mais que faire si vous ne pouvez pas voir le message d'erreur ? Il existe un moyen d'obtenir le meilleur des deux mondes :Enregistrement des erreurs dans un fichier journal.

Vous pouvez consulter le site web de wp-config.php C'est ainsi qu'il est mis en place dans le

define('DISALLOW_FILE_EDIT', true ) ;
define( 'WP_DEBUG', true ) ;
define('WP_DEBUG_DISPLAY', false ) ; /// Désactiver l'affichage des erreurs sur la page
define( 'WP_DEBUG_LOG', true ) ; /// Enregistre les erreurs dans le fichier /wp-content/debug.log

Ainsi, lorsqu'une erreur se produit, les détails de l'erreur sont discrètement écrits dans le fichier wp-content/debug.log Ce fichier journal n'est pas visible pour les utilisateurs du site, mais vous pouvez le télécharger pour résoudre le problème. Une fois le dépannage terminé, n'oubliez pas de déplacer le fichier WP_DEBUG remettre en place faux.

Partie V : Au-delà de l'essentiel - Des outils de débogage plus puissants

en dehors de WP_DEBUGCependant, il existe de nombreux outils plus puissants dans le monde de WordPress qui peuvent vous aider, et ils sont beaucoup plus puissants que l'éditeur du backend.

Moniteur de requêtes : Il s'agit d'un plugin très populaire auprès des développeurs. Il affiche toutes les requêtes de base de données générées par la page,Erreur PHPLes informations sont extrêmement détaillées et constituent un excellent outil pour le débogage avancé.
Editeur de code professionnel : utilisez un outil tel queCode VSLes éditeurs professionnels comme PhpStorm écrivent le code dans votre environnement local. Ils disposent de fonctionnalités telles que la coloration syntaxique, les conseils de code, la vérification des erreurs, etc., qui vous permettront d'éviter un grand nombre d'erreurs dès l'écriture du code.

rendre un verdict

Revenons à notre question initiale :disallow_file_editS'agit-il d'un parapluie ou d'une manille ?

La réponse réside dans vos choix. Si vous vous en remettez obstinément à cet éditeur de backend risqué, vous serez entravé. Mais si vous comprenez ce pour quoi il a été conçu et que vous êtes prêt à adopter une approche plus spécialisée de la gestion de l'information, vous ne serez pas déçu. WP_DEBUG Avec un flux de développement local, c'est un parapluie solide pour la stabilité et la sécurité de votre site web.

Acceptez ce changement. Il ne s'agit pas seulement de désactiver une fonctionnalité, c'est une étape importante dans votre parcours de passionné de WordPress vers un webmaster plus professionnel et plus fiable. Laissez tomber ce dangereux éditeur de backend, et vous verrez que le monde que vous pouvez contrôler et comprendre est devenu beaucoup plus large et plus solide.

Contactez nous
Vous n'arrivez pas à lire le tutoriel ? Contactez-nous pour une réponse gratuite ! Aide gratuite pour les sites personnels et les sites de petites entreprises !	Service clientèle WeChat
① Tel : 020-2206-9892
② QQ咨询：1025174874
(iii) Courriel : [email protected]
④ Horaires de travail : du lundi au vendredi, de 9h30 à 18h30, jours fériés.