WordPress debug log yeri: debug.log harada saxlanılır və necə köçürülür

WordPress debug jurnalını standart olaraq wp-content/debug.log faylına yazır — diskdəki mütləq yolu /path/to/your/site/wp-content/debug.log şəklindədir. Fayl nəsə həqiqətən qeydə alınana qədər mövcud olmur və ümumiyyətlə yalnız wp-config.php faylında WP_DEBUG dəyəri true olanda və WP_DEBUG_LOG aktiv olanda yazılır. Bu standart yer həm də real təhlükəsizlik problemidir, çünki hostinqlərin çoxunda onu istənilən adam brauzerdə aça bilər.

Üç sabit və hər birinin funksiyası

Hər üçü wp-config.php faylına, /* That's all, stop editing! Happy blogging. */ yazılan sətirdən yuxarıya gedir. Həmin sətirdən aşağı əlavə edilən hər şey WordPress artıq işə düşəndən sonra icra olunur və nəzərə alınmır.

Sabit	Standart	Nə edir
WP_DEBUG	false	Əsas açar. PHP xəta hesabatını qaldırır ki, bildirişlər, xəbərdarlıqlar və köhnəlmiş funksiyalar görünsün. Bu siyahıdakı heç nə onsuz işləmir.
WP_DEBUG_LOG	false	Xətaları fayla göndərir. true dəyəri wp-content/debug.log deməkdir. Sətir verilsə, o, yazılacaq fayl yolu kimi qəbul edilir.
WP_DEBUG_DISPLAY	true	Xətaları səhifə HTML-inə çap edir, hər ziyarətçi onları görür.

İnsanların ən çox səhv saldığı məqam asılılıqdır. WP_DEBUG_LOG WordPress-in başlanğıc kodunda WP_DEBUG şaxəsinin içində oxunur. WP_DEBUG dəyəri false-dursa, WP_DEBUG_LOG dəyərini true etmək heç nə vermir — nə fayl, nə xəta, nə də xəbərdarlıq. WP_DEBUG_LOG əlavə etmisinizsə və jurnal görünmürsə, əvvəlcə WP_DEBUG dəyərini yoxlayın.

Canlı sayt üçün işlək konfiqurasiya:

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

WP_DEBUG faylın yuxarısında artıq təyin olunubsa — adətən elə belədir, özü də false dəyəri ilə — ikinci define() əlavə etmək əvəzinə mövcud sətri redaktə edin. Eyni sabiti iki dəfə təyin etmək PHP xəbərdarlığı yaradır, göstərmə yanıq olan saytda isə bu, birbaşa səhifənizin başında görünür.

WP_DEBUG_DISPLAY istehsalatda niyə false olmalıdır

Göstərmə yanıq olanda PHP xətaları HTML cavabına çap edilir. Mövzudan gələn bir köhnəlmə bildirişi serverinizin mütləq fayl sistemi yolunu hər ziyarətçiyə göstərir. Verilənlər bazası xətası cədvəl adlarını və sorğu fraqmentlərini çap edir. Daha pisi: başlıqlar göndərilməmişdən əvvəl görünən çıxış yönləndirmələri pozur, təmiz JSON gözləyən REST və AJAX cavablarını sındırır və insanların sonra plagini günahlandırdığı ağ ekranı yarada bilər.

Bilməyə dəyən bir incəlik: WP_DEBUG_DISPLAY dəyərini null etmək false etməklə eyni deyil. null WordPress-ə deyir ki, PHP-nin display_errors parametrinə toxunmasın və serverdə nə qurulubsa onu qəbul etsin. false isə onu aktiv şəkildə söndürür. İstehsalat saytında false işlədin və üstəlik yuxarıdakı ini_set sətrini əlavə edin — çünki plagin sorğunun sonrakı hissəsində display_errors parametrini yenidən yandıra bilər.

Standart yer ictimai olaraq endirilə bilir

wp-content/debug.log veb kökünün içindədir. Adi WordPress quraşdırmasında ona birbaşa sorğuları bloklayan heç nə yoxdur. Tipik Apache və ya nginx quruluşunda https://yoursite.com/wp-content/debug.log faylı adi mətn kimi qaytarır. Debug jurnallarında mütləq server yolları, plagin və mövzu daxili məlumatları, real sorğu mətni ilə verilənlər bazası xətaları, bəzən də uğursuz funksiyalardan keçən dəyərlər olur. Bu, URL-i təxmin edən hər kəs üçün pulsuz kəşfiyyatdır — üstəlik avtomatik skanerlərin ilk yoxladığı ünvanlardan biridir.

Bununla iki cür davranmaq olar. Daha yaxşısı jurnalı köçürməkdir.

Jurnalı yol göstərməklə köçürün

WordPress 5.1-dən bəri WP_DEBUG_LOG boolean əvəzinə sətir şəklində fayl yolu qəbul edir. Onu sənəd kökündən kənarda bir yerə yönəldin:

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

Həmin yol üçün üç qayda. Mütləq yol işlədin — nisbi yol PHP-nin işçi qovluğuna görə hesablanır, o isə sorğudan və serverdən asılı olaraq dəyişir, beləcə faylın hara getdiyini itirəcəksiniz. Qovluq artıq mövcud olmalıdır; PHP onu yaratmayacaq və faylı aça bilməsə, səssizcə uğursuz olacaq. Qovluq həm də PHP istifadəçisi tərəfindən yazıla bilən olmalıdır — paylaşılan hostinqdə bu, SFTP ilə giriş etdiyiniz hesabla eyni deyil.

Hostinqiniz sizi veb kökü ilə məhdudlaşdırırsa və yuxarıda yazmağa yer yoxdursa, standart yolu saxlayın və girişi server səviyyəsində bloklayın. Apache üçün:

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

Bu, kökdəki deyil, wp-content içindəki .htaccess faylına yazılır — çünki daimi keçidləri (permalink) yadda saxlayanda WordPress kökdəki .htaccess faylını yenidən yazır və əlavənizi silə bilər. nginx-də .htaccess ümumiyyətlə işləmir; server konfiqurasiyasında location bloku lazımdır, idarə olunan hostinqdə isə bu, adətən dəstəyə müraciət etmək deməkdir.

Bloklamanın nə verdiyi barədə dürüst olaq: fayl hələ də diskdə, veb serverin xidmət etdiyi qovluqdadır. İstənilən plagindəki yol keçidi (path traversal) boşluğu onu yenə oxuya bilər. Veb kökündən kənara köçürmək daha güclü həlldir.

Faylı oxumaq və canlı izləmək

SSH üzərindən xətanı təkrarlayarkən onu canlı izləyin:

tail -f wp-content/debug.log

Başqa tabda xətanı təkrarlayın və yeni sətirlər yazıldıqca görünəcək. Yalnız son vaxtlar baş verənləri görmək və ya bir plaginə görə süzgəcdən keçirmək üçün:

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

PHP faylın sonuna əlavə edir, ona görə aşağıdan yuxarı oxuyun. Hər qeydin vaxt möhürü UTC-dədir və WordPress saat qurşağı parametrinizə uyğun gəlməyəcək — bunun sizə köhnə qeydlərə baxdığınızı düşündürməsinə imkan verməyin.

WP-CLI ilə sabitləri faylı əl ilə redaktə etmədən dəyişə bilərsiniz:

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

--raw bayrağı vacibdir — onsuz dəyər boolean yox, "true" sətri kimi yazılır. Yol formatı üçün isə --raw işlətməyin ki, dəyər dırnaqlı sətir kimi yazılsın.

SSH yoxdur? Faylı SFTP ilə endirin və ya hostinqin fayl menecerində açın. Jurnalı wp-admin daxilində göstərən plaginlərdən tam etibar etmirsinizsə uzaq durun; siz plaginə server daxili məlumatları ilə dolu bir faylı oxumaq icazəsi verirsiniz.

Quruluşunuz üçün dəqiq wp-config blokunu — təhlükəsiz kökdənkənar yol və uyğun server qaydası daxil olmaqla — istəyirsinizsə, WordPress debug jurnalı generatoru onu sizin üçün qurur.

İşiniz bitəndə söndürün

WordPress nüvəsində debug.log faylını fırladan və ya kəsən heç nə yoxdur. Hər səhifə yüklənməsində bildiriş verən saytda o, limitsiz böyüyür və diski doldura bilər — bu isə saytı axtardığınız xətadan da ağır şəkildə yıxır. Jurnalı yandırın, problemi təkrarlayın, jurnalı oxuyun, sonra WP_DEBUG dəyərini yenidən false edin.

Faylı silmədən təmizləmək üçün:

: > wp-content/debug.log

Jurnal boş qalanda

Bunları ardıcıllıqla nəzərdən keçirin. WP_DEBUG dəyəri false-dur — ən çox rast gəlinən səbəb və o, qalan hər şeyi səssizcə söndürür. Sabit wp-config.php faylında “stop editing” sətrindən aşağıdadır. Fayl icazələri — PHP wp-content qovluğuna, yaxud göstərdiyiniz xüsusi qovluğa yaza bilmir. wp-config yüklənməsi bitməmiş baş verən fatal xəta, məsələn konfiqurasiya faylının özündəki sintaksis xətası, WordPress jurnalının tuta bilməyəcəyi qədər erkən baş verir; belələri serverin öz PHP xəta jurnalına düşür. Hostinqiniz parametri üstələyir — bəzi idarə olunan platformalar PHP-nin error_log parametrini sabitləyir və ya jurnalı öz idarə panellərinə yönləndirir; bu halda sabitləriniz düzgündür, çıxış isə sadəcə başqa yerdədir. Konfiqurasiyanızın sınıq olduğunu düşünməzdən əvvəl hostinqin jurnal göstəricisini yoxlayın.