Lokasyon ng WordPress Debug Log: Nasaan ang debug.log at Paano Ito Ilipat

Isinusulat ng WordPress ang debug log nito sa wp-content/debug.log bilang default — na sa disk ay ang buong path na /path/to/your/site/wp-content/debug.log. Hindi umiiral ang file hangga’t walang aktuwal na naitatala, at naisusulat lang talaga ito kapag true ang WP_DEBUG at naka-enable ang WP_DEBUG_LOG sa wp-config.php. Tunay ding problema sa seguridad ang default na lokasyong iyon, dahil sa karamihan ng host, kahit sino ay puwedeng kunin ito sa browser.

Ang tatlong constant at ang ginagawa ng bawat isa

Silang tatlo ay napupunta sa wp-config.php, sa itaas ng linyang nagsasabing /* That's all, stop editing! Happy blogging. */. Anumang idinagdag sa ilalim ng linyang iyon ay tumatakbo pagkatapos nang mag-boot ang WordPress, kaya binabalewala.

Constant	Default	Ang ginagawa nito
WP_DEBUG	false	Pangunahing switch. Itinataas ang PHP error reporting para ipakita ang notices, warnings at deprecations. Walang gumagana sa listahang ito kung wala ito.
WP_DEBUG_LOG	false	Ipinapadala ang mga error sa isang file. Ang true ay nangangahulugang wp-content/debug.log. Ang string ay itinuturing na file path na susulatan.
WP_DEBUG_DISPLAY	true	Ipinapakita ang mga error sa HTML ng page, nakikita ng bawat bisita.

Ang pagkakadepende ang madalas na napagkakamalian. Binabasa ang WP_DEBUG_LOG sa loob ng WP_DEBUG na sanga ng startup code ng WordPress. Kung false ang WP_DEBUG, ang pagtatakda ng WP_DEBUG_LOG sa true ay wala talagang ginagawa — walang file, walang error, walang babala. Kung nakapagdagdag ka na ng WP_DEBUG_LOG pero walang lumabas na log, tingnan muna ang WP_DEBUG.

Isang gumaganang configuration para sa live na site:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Kung nakatakda na ang WP_DEBUG sa itaas na bahagi ng file — kadalasan ay ganoon nga, naka-false — i-edit ang umiiral na linyang iyon sa halip na magdagdag ng pangalawang define(). Ang pagtatakda ng parehong constant nang dalawang beses ay nagbubunga ng PHP warning, na sa site na naka-enable ang display ay lalabas mismo sa itaas ng page mo.

Bakit dapat false ang WP_DEBUG_DISPLAY sa production

Kapag naka-on ang display, ipinapakita ang mga PHP error sa loob mismo ng HTML response. Ang isang deprecation notice lang mula sa isang theme ay maglalabas ng buong filesystem path ng server mo sa bawat bisita. Ang database error ay maglalabas ng mga table name at piraso ng query. Mas malala, ang output na lumalabas bago maipadala ang headers ay sumisira sa redirects, sumisira sa REST at AJAX responses na umaasa sa malinis na JSON, at puwedeng magbunga ng puting screen na sinisisi naman ng mga tao sa isang plugin.

Isang detalyeng dapat malaman: ang pagtatakda ng WP_DEBUG_DISPLAY sa null ay hindi katulad ng false. Sinasabi ng null sa WordPress na huwag galawin ang display_errors setting ng PHP at manahin na lang kung ano ang nakaayos sa server. Ang false ay aktibong pumapatay nito. Sa production site, gamitin ang false at idagdag ang linya ng ini_set sa itaas bilang dobleng proteksiyon, dahil puwedeng ibalik ng isang plugin ang display_errors sa mas huling bahagi ng request.

Ang default na lokasyon ay puwedeng kunin ng kahit sino

Nasa loob ng web root ang wp-content/debug.log. Walang bahagi ng karaniwang WordPress install ang humaharang sa direktang request dito. Sa tipikal na Apache o nginx setup, ang https://yoursite.com/wp-content/debug.log ay ibinabalik ang file bilang plain text. Naglalaman ang debug logs ng buong server paths, panloob na detalye ng plugin at theme, database errors kasama ang totoong teksto ng query, at kung minsan ang mga halagang dumaan sa mga nabigong function. Libreng impormasyon iyan para sa kahit sinong makahula ng URL — at isa iyon sa mga unang URL na sinusubukan ng mga awtomatikong scanner.

Dalawang paraan para harapin ito. Ang mas mabuti ay ang paglipat ng log.

Ilipat ang log gamit ang isang path

Mula pa noong WordPress 5.1, tumatanggap ang WP_DEBUG_LOG ng string na file path sa halip na boolean. Ituro ito sa isang lugar na nasa labas ng document root:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/youruser/logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );

Tatlong panuntunan para sa path na iyon. Gumamit ng absolute path — ang relative na path ay tinutumbasan laban sa working directory ng PHP, na nagbabago depende sa request at sa server, kaya mawawalan ka ng tunton kung saan napunta ang file. Dapat umiiral na ang direktoryo; hindi ito gagawin ng PHP, at kung hindi nito mabuksan ang file, tahimik itong nabibigo. At dapat writable ang direktoryo ng PHP user, na sa shared hosting ay hindi ang parehong account na ginagamit mo sa SFTP.

Kung ikinukulong ka ng hosting mo sa loob ng web root at walang mapagsusulatan sa itaas nito, panatilihin ang default na path at harangan na lang ang access sa antas ng server. Sa Apache:

<Files "debug.log">
  Require all denied
</Files>

Napupunta iyan sa isang .htaccess file sa loob ng wp-content, hindi sa nasa root — muling isinusulat ng WordPress ang .htaccess sa root kapag nag-save ka ng permalinks at puwede nitong burahin ang idinagdag mo. Sa nginx, wala talagang ginagawa ang .htaccess; kailangan mo ng location block sa server config, na sa managed hosting ay kadalasang nangangahulugang humingi ng tulong sa support.

Maging tapat tayo sa naibibigay ng paghaharang: nasa disk pa rin ang file, sa isang direktoryong inihahain ng web server. Puwede pa rin itong mabasa ng isang path-traversal na bug sa kahit anong plugin. Mas matibay na solusyon ang paglipat nito sa labas ng web root.

Pagbasa at pag-tail sa file

Sa SSH, panoorin ito nang live habang inuulit mo ang bug:

tail -f wp-content/debug.log

Ulitin ang error sa ibang tab at lilitaw ang mga bagong linya habang isinusulat ang mga ito. Para makita lang ang kamakailang nangyari, o para i-filter sa isang plugin:

tail -n 100 wp-content/debug.log
grep -i 'plugin-slug' wp-content/debug.log | tail -n 50

Idinaragdag ng PHP ang bago sa dulo ng file, kaya basahin mula sa ilalim pataas. Naka-timestamp sa UTC ang bawat entry, na hindi tutugma sa timezone setting ng WordPress mo — huwag mong hayaang mapagkamalan mong luma ang tinitingnan mo.

Sa WP-CLI puwede mong baguhin ang mga constant nang hindi ine-edit nang manwal ang file:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

Mahalaga ang --raw na flag — kung wala ito, isinusulat ang halaga bilang string na "true" sa halip na boolean. Para sa anyong path, alisin ang --raw para maisulat ito bilang quoted string.

Walang SSH? I-download ang file sa pamamagitan ng SFTP o buksan ito sa file manager ng host mo. Iwasan ang mga plugin na inilalabas ang log sa loob ng wp-admin maliban kung lubos mo silang pinagkakatiwalaan; binibigyan mo ang isang plugin ng read access sa file na puno ng panloob na detalye ng server.

Kung gusto mo ang eksaktong wp-config block para sa setup mo, kasama ang ligtas na path sa labas ng root at ang katugmang panuntunan sa server, buuin ito para sa iyo ng WordPress debug log generator.

Patayin ito kapag tapos ka na

Walang bahagi ng WordPress core ang nagro-rotate o nagpuputol sa debug.log. Sa site na naglalabas ng notice sa bawat page load, lumalaki ito nang walang hanggan at puwedeng mapuno ang disk — na mas malala pang magpapatumba sa site kaysa sa bug na hinahabol mo. Buksan ang logging, ulitin ang problema, basahin ang log, tapos ibalik ang WP_DEBUG sa false.

Para linisin ang file nang hindi ito binubura:

: > wp-content/debug.log

Kapag nananatiling walang laman ang log

Dumaan sa mga ito nang sunod-sunod. false ang WP_DEBUG — ito ang pinakakaraniwang dahilan, at tahimik nitong pinapatay ang lahat ng iba pa. Nasa ilalim ng linyang “stop editing” ang constant sa wp-config.php. File permissions — hindi makasulat ang PHP sa wp-content, o sa custom na direktoryong itinakda mo. Isang fatal error bago matapos mag-load ang wp-config, tulad ng syntax error sa mismong config file, ay nangyayari nang napakaaga para masalo ng logging ng WordPress; napupunta ang mga iyon sa sariling PHP error log ng server. Ino-override ito ng host mo — may ilang managed platform na pinipirmi ang error_log setting ng PHP o dinadala ang logging sa sarili nilang dashboard, kung saan tama naman ang mga constant mo pero nasa ibang lugar lang ang output. Tingnan ang log viewer ng host bago mo isipin na sira ang config mo.