Share
Le langage PHP est largement adopté pour de nombreuses applications Web telles que WordPress. Aussi puissant que PHP, il présente certains inconvénients, mais l’une de mes caractéristiques préférées de PHP est qu’il affichera les erreurs directement sur la page Web. La nouvelle barre d'outils introduite dans WordPress 3.3 interfère avec cette fonctionnalité. La barre d’outils a une position absolue fixe qui couvre les premières lignes d’erreurs PHP.
Avec la nouvelle barre d’outils couvrant les erreurs PHP, nous devons utiliser d’autres options pour déboguer nos thèmes et plugins. Heureusement pour nous, nous avons le choix entre plusieurs options..
Depuis la création de la nouvelle barre d’outils, les développeurs ont créé quelques plugins qui peuvent nous aider à résoudre ce problème. Voici quelques plugins que vous pouvez utiliser pour désactiver la barre d’outils..
Tous ces plugins offrent des fonctionnalités différentes, mais ils nous permettent tous de désactiver la barre d’outils. Ce qui nous permettra de voir les erreurs PHP qui pourraient nous arriver. La bonne chose avec ces plugins est qu'ils peuvent être activés et désactivés si nécessaire.
La solution pour les erreurs PHP suggérée par l’équipe de base de WordPress consiste à utiliser la journalisation des erreurs. Si vous développez sur WordPress, vous devez déjà connaître la constante WP_DEBUG définie dans le fichier wp-config.php. Vous pouvez également définir la constante WP_DEBUG_LOG. Voici un exemple que WordPress Codex donne pour activer le journal de débogage.
Accentsconagua
define ('WP_DEBUG', true); // false if (WP_DEBUG) define ('WP_DEBUG_LOG', true); define ('WP_DEBUG_DISPLAY', false); @ini_set ('display_errors', 0); Cela produira toutes les erreurs PHP dans un fichier nommé debug.log dans le dossier wp-content. Les erreurs de journalisation comme celle-ci ont des hauts et des bas. Lorsque vous travaillez sur un plugin commercial ou dans un environnement d'équipe où la journalisation des erreurs est nécessaire. C'est la meilleure solution pour suivre vos erreurs, mais lors du développement d'un plugin ou d'un thème à une plus petite échelle, cela n'est tout simplement pas pratique. Lorsque tout ce que vous avez à faire est de vous assurer que tous vos I sont en pointillés et que vos T sont croisés. Il peut être très frustrant de devoir ouvrir, fermer et rouvrir le journal des erreurs chaque fois que vous effectuez un changement..
La méthode que j'ai adoptée consiste à générer des erreurs PHP sous forme d'alertes d'administration. Je pense que c'est la meilleure solution jusqu'à présent. Aucun plugin n'est requis, c'est plus pratique que la journalisation des erreurs, et il peut être laissé en place sans interférer avec la mise en page et la conception de l'espace administrateur ou de vos thèmes WordPress..
Le code utilisé pour y parvenir est simple et je ne comprends pas très bien pourquoi ce n’est pas une partie intégrante de WordPress Core. Le code suivant doit être placé dans votre fichier functions.php ou dans votre plugin de fonctionnalités..
function admin_alert_errors ($ errno, $ errstr, $ errfile, $ errline) $ errorType = array (E_ERROR => 'ERREUR', E_CORE_ERROR => 'ERREUR PRINCIPAL', E_COMPILE_ERROR => 'ERREUR COMPILE', E_USER_ERROR => 'USER ERROR ', E_RECOVERABLE_ERROR =>' ERREUR RECUPERABLE ', E_WARNING =>' AVERTISSEMENT ', E_CORE_WARNING =>' AVERTISSEMENT DE BASE ', E_COMPILE_WARNING =>' AVERTISSEMENT COMPILE ', E_USER_WARNING =>' AVERTISSEMENT UTILISATEUR ', E_NOTICE' '. > 'USER NOTICE', E_DEPRECATED => 'DEPRECATED', E_USER_DEPRECATED => 'USER_DEPRECATED', E_PARSE => 'PARSING ERROR'); if (array_key_exists ($ errno, $ errorType)) $ errname = $ errorType [$ errno]; else $ errname = 'UNKNOWN ERROR'; ob_start ();?>Erreur: [] en ligne
Quatre arguments sont transmis à la fonction admin_alert_errors ()..
Le tableau $ errorType définit le titre utilisé pour chaque type d'erreur.
par exemple. ATTENTION Erreur: [2] include (wuzup) [function.include]:
Ceux-ci peuvent être tout ce que vous voulez. Il peut dire "Wuzup G, tu as foiré quelque chose".
par exemple. ATTENTION Wuzup G, vous avez foiré quelque chose: [2] include (wuzup) [function.include]:
Je ne recommande pas de l'utiliser pour quoi que ce soit que vous fassiez pour un client à moins qu'il ait un très bon sens de l'humour, mais vous avez l'idée.
L'instruction IF vérifie si le type d'erreur correspond à l'une des constantes d'erreur définies dans le tableau $ errorType. Sinon, le titre de l'erreur sera affiché comme "ERREUR INCONNUE"
La dernière partie de la fonction est ce qui sera généré. La classe Erreur est une classe par défaut intégrée à WordPress utilisée pour styliser les alertes d'erreur d'erreur.
Pour lancer la fonction admin_alert_errors (), vous utiliserez la fonction set_error_handler (). Le premier paramètre est la fonction utilisée pour afficher les erreurs. Dans ce cas, la fonction admin_alert_errors (). Le prochain ensemble de paramètres est constitué des constantes d'erreur PHP que vous souhaitez afficher..
Si vous avez de l'expérience dans la gestion des erreurs, vous remarquerez qu'E_STRICT n'est pas inclus. En effet, certaines erreurs proviennent de WordPress Core. Je ne sais pas si c'est quelque chose qui manque à l'équipe principale de WordPress ou si c'est intentionnel, mais de toute façon, il n'est pas nécessaire d'afficher ces erreurs. De plus, utiliser E_ALL au lieu de répertorier toutes les constantes d'erreur ne semble pas fonctionner. Si vous utilisez E_ALL, toutes les erreurs ne seront pas affichées sous forme d'alertes admin..
Remarque: Cela n'affecte pas la façon dont les erreurs sont affichées sur le front-end de votre site. Seulement dans les pages d'administration.
une autre note: Lorsque les données de test WordPress sont installées. Je reçois un PÉRIMÉ erreur pour le fichier class-simplepie.php.
Eh bien, j'espère que cela vous aidera avec ces ennuyeuses erreurs PHP. Si quelqu'un a une autre solution, merci de l'afficher dans les commentaires. J'aimerais voir ce que vous avez créé.
