3 ok, hogy miért érdemes használni wp_debug_log wordpress-tervezés szól wordpress

Mivel ez a helyzet sok más dolog fejlesztésével kapcsolatos WordPress, a legjobb módja annak, hogy megértsük az állandó WP_DEBUG_LOG -, hogy megtaláljuk azt a WordPress core kódot.

Egy fontos része kód a wp-includes / load.php file:

Ha a WP_DEBUG igaz, kérje WP_DEBUG_DISPLAY hamis és WP_DEBUG_LOG igaz, akkor ebben az esetben minden hibát jelennek debug.log fájlt a wp-content mappában; PHP hiba információt hiányozni fog.

Hogy meghatározza ezeket a konstansokat, hozzá kell adni a következő sorokat a wp-config.php:

De miért történik ez?

1. elrejtése hibák

Lát egy hiba a böngésző? Biztos benne, hogy megjelenik, mindent? Mi a helyzet a tartalmazó div, rejtett CSS? Mi az AJAX-kéréseket?

Interface - nem a legbiztonságosabb hely a hibákat. Log file PHP mutatja mindent.

2. A fogás minden hibát.

Talán szeretné használni plug-inek, mint a Debug Bar vagy a Query Monitor, hogy rögzítse a hibákat, és akkor nekik is elég. Nem hibáztatom ezért. Ezek a bővítmények nagyon cool.

Én azonban úgy találta, hogy hiányzik néhány hibát. Gyanítom, hogy ez annak köszönhető, hogy a természet - ezek plug-in, és más plug-in tölthető előttük. Persze, meg lehet változtatni a boot sorrendben, hogy azok töltik az elején, de hogyan lehet tekintetében hibákat több gépen és beépülő modulok a WordPress core? Továbbá, amint azt találtam hibát Szigorú szabványok nem készített ezen plug-inek.

Ezek a bedolgozók ideálisak különböző dolog, de abban az esetben a PHP gyönyörködtető hibákat nem kellene támaszkodnia. PHP is - ez egy megbízható hibaforrás jelentésben, és hogy egy ilyen jelentés megtalálható debug.log.

3. eltávolításához külső plug-inek hiba.

Mindez rendben van, ha a kód egy hiba. Meg tudod oldani őket.

De mi a helyzet a harmadik féltől származó beépülő modulokat, hogy aktiválta? Mi van, ha kiadja riasztások és értesítések az egész felület? És mivel már benne WP_DEBUG jelentések, kapsz értesítést, riasztások, mismatch szabványok, stb Overkill. Zavarhatja, és gyakorlatilag lehetetlenné teszik a munkát néhány plugins aktiválódik.

A múltban én csak deaktivált ilyen dugó. Nem a legjobb megoldás. Különben is, mi van, ha nem tud dolgozni anélkül, hogy ezeket a plug-in? Régebben csak levágta WP_DEBUG. Szégyenletesen, tudom.

Ezen a ponton én csak fog feltételezni, hogy üt. Már hozzáadta állandók fent wp-config.php és kampós debug.log. Most lehet nyomon követni, és szűrjük debug.log.

Monitoring és szűrés debug.log

Amellett, hogy nyomon követése debug.log hibákat, akkor természetesen szükség van, hogy távolítsa el a zaj által létrehozott külső plug-inek. Ellenkező esetben a „helyes” hiba lehet fulladt ez a zaj.

Persze, néhány ember használja a Console alkalmazást OS X olvasni egy log fájlt, amely a szűrő felesleges zajokat a harmadik féltől származó bővítményeket. Ez érdekesen hangzik, bár én még nem próbáltam. Úgy döntöttem, hogy kerülő úton.

Írtam egy PHP-script. Csak nyilvántartja a log fájl változások és a hibaüzenetet értesítést. Azt is kiszűrje Xdebug blokkok alapján reguláris kifejezések, így figyelmen kívül hagyhatja a figyelmeztetéseket és értesítéseket a harmadik fél plug-inek.

Egy debug.log az összes oldalak

Én használtam egy külön naplót debug.log az összes oldalak, amit találtam a szerzői környezet. Amikor áttért a másik oldalra vele dolgozni, kellett követni a különböző log fájlt. Nem a legjobb megoldás.

Most van egy minden oldalon jelentkezzen készlet. Én ezt egy egyszerű plugin. Én hozzá a következő kódot a wp-content / plugins mu-/ egyéni-debug-log-path.php minden egyes oldalon:

Most már csak követni a szakadék az egyik az összes telephely fejlesztés alatt áll.

Ez működik, csak finom. Persze, sok javulást lehet tenni, de én is elég volt a hiba jelentést.

Ön használ egy hasonló hiba jelentést? Milyen fejlesztések is javasol?