3 motive pentru care ar trebui să utilizați wp_debug_log în wordpress-development, totul despre wordpress

Ca și în multe alte aspecte legate de dezvoltarea WordPress, cea mai bună modalitate de a înțelege constanta WP_DEBUG_LOG este să o găsiți în codul kernelului WordPress.







O secțiune importantă a codului este în fișierul wp-include / load.php:

Dacă setați WP_DEBUG la true, cere WP_DEBUG_DISPLAY la fals și WP_DEBUG_LOG adevărat, atunci în acest caz, toate erorile sunt afișate în fișierul debug.log în dosarul-wp conținut; în PHP, informații despre erori vor fi absente.

Pentru a seta aceste constante, trebuie să adăugați următoarele linii la wp-config.php:

Dar de ce se face acest lucru?

1. Pentru a ascunde erorile

Iti place sa vezi bug-uri intr-un browser web? Ești sigur că primești absolut totul? Ce se întâmplă cu blocurile div ascunse cu CSS? Ce zici de întrebările AJAX?

Interfața nu este cel mai fiabil loc pentru a prinde erori. Fișierul jurnal PHP arată totul.

2. Pentru a prinde toate erorile.

Poate doriți să utilizați pluginuri precum Debug Bar sau Query Monitor pentru a prinde bug-uri și sunteți destul de mulțumit de ele. Nu te învinovățesc pentru asta. Aceste plugin-uri sunt foarte cool.

Cu toate acestea, am constatat că le lipsesc unele greșeli. Bănuiesc că acest lucru se datorează naturii lor - sunt plug-in-uri, iar alte plug-in-uri pot fi încărcate înaintea lor. Desigur, puteți schimba ordinea de încărcare astfel încât acestea să fie încărcate la început, dar cum rămâne cu erorile din pluginurile multi-site și în centrul WordPress? În plus, după cum am descoperit, erorile cu standarde stricte nu sunt luate în considerare de aceste pluginuri.

Aceste plugin-uri sunt ideale pentru lucruri diferite, dar în cazul în care prindeți toate erorile PHP pe ele, nu trebuie să vă bazați. În sine, este o sursă sigură de rapoarte de eroare, și acesta este exact ceea ce găsiți în debug.log.







3. Pentru a elimina erorile pluginurilor terță parte.

Toate acestea sunt bine dacă codul dvs. generează erori. Le puteți rezolva.

Dar cum rămâne cu plug-in-urile terță parte pe care le-ați activat? Ce se întâmplă dacă emite avertismente și notificări peste tot în interfața dvs.? Deoarece ați activat rapoartele WP_DEBUG, primiți notificări, avertismente, inconsecvențe etc. Overkill. Acest lucru poate împiedica și va face aproape imposibil să lucrați cu anumite pluginuri activate.

În trecut, aș dezactiva pur și simplu astfel de plug-in-uri. Nu este cea mai bună soluție. De asemenea, dacă nu puteți lucra fără aceste pluginuri? Anterior am deconectat pur și simplu WP_DEBUG. Sincer, știu.

În această etapă, voi presupune pur și simplu că te-am depășit. Ați adăugat deja constantele de mai sus la wp-config.php și debug.log conectat. Acum puteți monitoriza și filtra debug.log.

Monitorizarea și filtrarea debug.log

În plus față de monitorizarea debug.log pentru erori, trebuie să eliminați în mod natural toate zgomotul creat de pluginurile terță parte din acesta. În caz contrar, greșelile dvs. "corecte" se pot îneca în acest zgomot.

Desigur, unii oameni folosesc aplicația Consola în OS X pentru a citi fișierul jurnal, care are propria filtrare a zgomotului suplimentar de la plug-in-uri terțe. Sună interesant, deși eu nu am încercat eu însumi. M-am hotarat sa merg intr-un sens giratoriu.

Am scris un script PHP. Pur și simplu urmărește fișierul jurnal pentru modificări și emite notificări de eroare. De asemenea, poate filtra toate blocurile Xdebug bazate pe expresii regulate, ceea ce vă va permite să ignorați avertismentele și notificările de la pluginurile terță parte.

Un debug.log pentru toate site-urile

Anterior, am folosit jurnale separate de depanare pentru toate site-urile pe care le am în mediul de dezvoltare. Când am trecut la un alt site pentru a lucra cu el, a trebuit să urmăresc și un alt fișier jurnal. Nu este cea mai bună soluție.

Acum am un jurnal pentru toate site-urile. Am făcut-o cu un simplu plug-in. Am adăugat următorul cod la wp-content / mu-plugins / custom-debug-log-path.php pentru fiecare site:

Acum mi-a fost de ajuns să urmăresc un jurnal pentru toate site-urile mele dezvoltate.

Această abordare funcționează foarte bine. Desigur, există încă multe îmbunătățiri care pot fi făcute, dar m-am săturat de acest raport de eroare.

Utilizați un raport de eroare similar? Ce îmbunătățiri puteți oferi?







Trimiteți-le prietenilor: