WordPress کی ڈی بگ لاگ کہاں ہوتی ہے؟

پہلے سے طے شدہ طور پر یہ wp-content/debug.log ہے، یعنی سیدھا آپ کے wp-content فولڈر کے اندر۔ WordPress یہ فائل تب ہی بناتا ہے جب واقعی کوئی خرابی لاگ ہو، اس لیے wp-content میں فائل نہ ہونے کا مطلب یہ نہیں کہ لاگنگ خراب ہے۔ اگر WP_DEBUG_LOG کو true کے بجائے کوئی فائل پاتھ دیا گیا ہو تو لاگ اُسی پاتھ پر لکھی جاتی ہے۔

wp-content میں debug.log فائل کیوں نہیں ہے؟

تین عام وجوہات ہیں۔ WP_DEBUG false ہے، اس لیے WP_DEBUG_LOG چاہے کچھ بھی ہو، WordPress لاگنگ آن ہی نہیں کرتا۔ ابھی تک کوئی خرابی ہوئی ہی نہیں، اس لیے فائل بنی نہیں۔ یا فائل پرمیشنز کی وجہ سے PHP، wp-content میں لکھ نہیں سکتا۔ پہلے کونسٹنٹس دیکھیں، پھر پرمیشنز۔

کیا کوئی بھی میری WordPress debug.log ڈاؤن لوڈ کر سکتا ہے؟

عام طور پر جی ہاں۔ wp-content/debug.log ویب روٹ کے اندر ہوتی ہے اور اسے بچانے کے لیے کوئی رسائی رول موجود نہیں ہوتا، اس لیے براؤزر سے اُس URL کی درخواست اکثر فائل واپس کر دیتی ہے۔ ڈی بگ لاگز میں معمول کے مطابق سرور کے مکمل پاتھ، ڈیٹابیس کی خرابیاں اور کوئری کے ٹکڑے ہوتے ہیں۔ لاگ کو ویب روٹ سے باہر منتقل کریں یا سرور کنفیگ میں اس تک رسائی روکیں۔

WP_DEBUG_LOG اور WP_DEBUG_DISPLAY میں کیا فرق ہے؟

WP_DEBUG_LOG خرابیاں ایک فائل میں لکھتا ہے۔ WP_DEBUG_DISPLAY انہیں صفحے کے HTML میں چھاپ دیتا ہے جہاں آنے والے انہیں پڑھ سکتے ہیں۔ لائیو سائٹ پر آپ لاگنگ آن اور ڈسپلے آف چاہتے ہیں۔ دونوں مکمل طور پر نظرانداز ہو جاتے ہیں جب تک WP_DEBUG کو true نہ کیا جائے، اور یہی وہ قدم ہے جو زیادہ تر لوگ بھول جاتے ہیں۔

WordPress کی ڈی بگ لاگ کیسے پڑھیں؟

SSH پر لاگ کے پاتھ پر tail -f چلائیں تاکہ مسئلہ دوبارہ پیدا کرتے ہوئے نئے اندراج لائیو نظر آتے رہیں۔ SSH نہ ہو تو فائل SFTP سے ڈاؤن لوڈ کریں یا ہوسٹ کے فائل مینیجر میں کھولیں۔ نیچے سے اوپر کی طرف پڑھیں، کیونکہ PHP نئے اندراج فائل کے آخر میں جوڑتا ہے۔

کیا WP_DEBUG آن کرنے سے لائیو سائٹ سست ہو جاتی ہے؟

تھوڑی بہت، مگر بڑا خطرہ ڈسک کا ہے۔ مصروف سائٹ پر تفصیلی لاگنگ debug.log کو گیگا بائٹس تک بڑھا کر ڈسک بھر سکتی ہے، جس سے سائٹ بیٹھ جاتی ہے۔ اسے آن کریں، بگ دوبارہ پیدا کریں، لاگ پڑھیں، پھر واپس بند کر دیں۔ WordPress کور میں کوئی چیز اس فائل کو نہ گھماتی ہے نہ چھوٹا کرتی ہے۔

WordPress ڈی بگ لاگ کہاں ہوتی ہے: debug.log کا مقام اور اسے منتقل کرنے کا طریقہ

WordPress پہلے سے طے شدہ طور پر اپنی ڈی بگ لاگ wp-content/debug.log میں لکھتا ہے — ڈسک پر اس کا مکمل پاتھ /path/to/your/site/wp-content/debug.log بنتا ہے۔ یہ فائل تب تک موجود نہیں ہوتی جب تک واقعی کچھ لاگ نہ ہو، اور یہ لکھی ہی تب جاتی ہے جب wp-config.php میں WP_DEBUG کی قدر true ہو اور WP_DEBUG_LOG فعال ہو۔ یہ طے شدہ مقام ایک حقیقی سیکیورٹی مسئلہ بھی ہے، کیونکہ زیادہ تر ہوسٹس پر کوئی بھی اسے براؤزر سے کھول کر لے جا سکتا ہے۔

تین کونسٹنٹس اور ہر ایک کا کام

تینوں wp-config.php میں اُس لائن سے اوپر جاتے ہیں جس پر لکھا ہے /* That's all, stop editing! Happy blogging. */۔ اس لائن کے نیچے جو کچھ شامل کیا جائے وہ WordPress کے بوٹ ہو جانے کے بعد چلتا ہے اور نظرانداز ہو جاتا ہے۔

کونسٹنٹ	طے شدہ قدر	یہ کیا کرتا ہے
`WP_DEBUG`	`false`	مرکزی سوئچ۔ PHP کی ایرر رپورٹنگ بڑھا کر نوٹسز، وارننگز اور ڈیپریکیشنز دکھاتا ہے۔ اس کے بغیر اس فہرست کی کوئی چیز کام نہیں کرتی۔
`WP_DEBUG_LOG`	`false`	خرابیاں ایک فائل میں بھیجتا ہے۔ `true` کا مطلب `wp-content/debug.log` ہے۔ کوئی سٹرنگ دی جائے تو اسے وہ فائل پاتھ سمجھا جاتا ہے جہاں لکھنا ہے۔
`WP_DEBUG_DISPLAY`	`true`	خرابیاں صفحے کے HTML میں چھاپتا ہے، جو ہر آنے والے کو نظر آتی ہیں۔

انحصار والا حصہ ہی وہ ہے جہاں لوگ غلطی کرتے ہیں۔ WP_DEBUG_LOG کو WordPress کے ابتدائی کوڈ میں WP_DEBUG کی شرط کے اندر پڑھا جاتا ہے۔ اگر WP_DEBUG کی قدر false ہو تو WP_DEBUG_LOG کو true کرنے سے کچھ بھی نہیں ہوتا — نہ فائل، نہ خرابی، نہ وارننگ۔ اگر آپ نے WP_DEBUG_LOG شامل کیا اور کوئی لاگ نہ آئی تو پہلے WP_DEBUG دیکھیں۔

لائیو سائٹ کے لیے ایک کارآمد کنفیگریشن:

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

اگر WP_DEBUG فائل میں پہلے ہی اوپر کہیں طے شدہ ہے — اور عام طور پر ہوتا ہے، false پر — تو دوسرا define() جوڑنے کے بجائے وہی موجودہ لائن ایڈٹ کریں۔ ایک ہی کونسٹنٹ دو بار طے کرنے سے PHP وارننگ آتی ہے، جو ڈسپلے آن ہونے والی سائٹ پر سیدھی آپ کے صفحے کے اوپر آ بیٹھتی ہے۔

پروڈکشن میں WP_DEBUG_DISPLAY کا false ہونا کیوں ضروری ہے

ڈسپلے آن ہو تو PHP کی خرابیاں HTML جواب کے اندر چھپ جاتی ہیں۔ کسی تھیم کا ایک ڈیپریکیشن نوٹس بھی آپ کے سرور کا مکمل فائل سسٹم پاتھ ہر آنے والے کو دکھا دیتا ہے۔ ڈیٹابیس کی خرابی ٹیبل کے نام اور کوئری کے ٹکڑے چھاپ دیتی ہے۔ اس سے بھی بدتر، ہیڈرز بھیجے جانے سے پہلے نکلنے والا آؤٹ پٹ ری ڈائریکٹس توڑ دیتا ہے، صاف JSON کی توقع رکھنے والے REST اور AJAX جوابات توڑ دیتا ہے، اور وہ سفید سکرین پیدا کر سکتا ہے جس کا الزام لوگ بعد میں کسی پلگ ان پر ڈالتے ہیں۔

ایک باریک بات جاننے کے قابل ہے: WP_DEBUG_DISPLAY کو null رکھنا false رکھنے کے برابر نہیں۔ null سے WordPress PHP کی display_errors سیٹنگ کو ہاتھ نہیں لگاتا اور جو کچھ سرور پر طے ہے وہی چلنے دیتا ہے۔ false اسے فعال طور پر بند کر دیتا ہے۔ پروڈکشن سائٹ پر false استعمال کریں اور ساتھ اوپر والی ini_set لائن بھی رکھیں تاکہ دوہری حفاظت ہو، کیونکہ کوئی پلگ ان درخواست کے آگے چل کر display_errors واپس آن کر سکتا ہے۔

طے شدہ مقام عوامی طور پر قابلِ رسائی ہے

wp-content/debug.log ویب روٹ کے اندر ہوتی ہے۔ عام WordPress انسٹالیشن میں کوئی چیز اس تک براہِ راست درخواستیں نہیں روکتی۔ عام Apache یا nginx سیٹ اپ پر https://yoursite.com/wp-content/debug.log فائل کو سادہ متن کے طور پر واپس کر دیتا ہے۔ ڈی بگ لاگز میں سرور کے مکمل پاتھ، پلگ ان اور تھیم کی اندرونی تفصیلات، اصل کوئری متن کے ساتھ ڈیٹابیس کی خرابیاں، اور کبھی کبھی ناکام فنکشنز میں سے گزرنے والی قدریں ہوتی ہیں۔ یہ ہر اُس شخص کے لیے مفت معلومات ہے جو URL کا اندازہ لگا لے — اور خودکار اسکینرز جو URLs سب سے پہلے آزماتے ہیں، یہ ان میں سے ایک ہے۔

اس سے نمٹنے کے دو طریقے ہیں۔ بہتر یہ ہے کہ لاگ کو منتقل کر دیا جائے۔

لاگ کو پاتھ دے کر منتقل کریں

WordPress 5.1 سے WP_DEBUG_LOG بولین کے بجائے سٹرنگ فائل پاتھ بھی قبول کرتا ہے۔ اسے ڈاکومنٹ روٹ سے باہر کہیں کی طرف موڑ دیں:

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

اس پاتھ کے لیے تین اصول ہیں۔ مکمل (absolute) پاتھ استعمال کریں — نسبتی پاتھ PHP کی ورکنگ ڈائریکٹری کے حساب سے حل ہوتا ہے، جو ہر درخواست اور ہر سرور پر بدلتی ہے، اس لیے آپ کو پتہ ہی نہیں چلے گا کہ فائل کہاں گئی۔ ڈائریکٹری پہلے سے موجود ہونی چاہیے؛ PHP اسے خود نہیں بنائے گا، اور اگر وہ فائل کھول نہ سکے تو خاموشی سے ناکام ہو جاتا ہے۔ اور ڈائریکٹری PHP یوزر کے لیے قابلِ تحریر ہونی چاہیے، جو شیئرڈ ہوسٹنگ پر وہ اکاؤنٹ نہیں ہوتا جس سے آپ SFTP پر لاگ اِن کرتے ہیں۔

اگر آپ کی ہوسٹنگ آپ کو ویب روٹ تک محدود رکھتی ہے اور اوپر لکھنے کی کوئی جگہ نہیں، تو طے شدہ پاتھ برقرار رکھیں اور اس کے بجائے سرور کی سطح پر رسائی روکیں۔ Apache پر:

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

یہ wp-content کے اندر والی .htaccess فائل میں جاتا ہے، روٹ والی میں نہیں — پرمالنکس محفوظ کرتے وقت WordPress روٹ کی .htaccess دوبارہ لکھ دیتا ہے اور آپ کا اضافہ مٹا سکتا ہے۔ nginx پر .htaccess کا کوئی وجود ہی نہیں؛ وہاں سرور کنفیگ میں لوکیشن بلاک درکار ہوتا ہے، جس کا مینیجڈ ہوسٹنگ پر عام طور پر مطلب سپورٹ سے کہنا ہوتا ہے۔

اس روک ٹوک سے کیا ملتا ہے، اس بارے میں صاف رہیں: فائل اب بھی ڈسک پر اُسی ڈائریکٹری میں پڑی ہے جسے ویب سرور پیش کرتا ہے۔ کسی بھی پلگ ان میں پاتھ ٹریورسل کی خامی اسے پھر بھی پڑھ سکتی ہے۔ اسے ویب روٹ سے باہر منتقل کرنا زیادہ مضبوط حل ہے۔

فائل پڑھنا اور لائیو دیکھنا

SSH پر، بگ دوبارہ پیدا کرتے ہوئے اسے لائیو دیکھیں:

tail -f wp-content/debug.log

دوسرے ٹیب میں خرابی دہرائیں اور نئی لائنیں لکھے جاتے ہی نظر آنے لگیں گی۔ صرف حالیہ واقعات دیکھنے کے لیے، یا کسی ایک پلگ ان تک فلٹر کرنے کے لیے:

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

PHP فائل کے آخر میں لکھتا ہے، اس لیے نیچے سے اوپر کی طرف پڑھیں۔ ہر اندراج پر UTC میں وقت درج ہوتا ہے، جو آپ کی WordPress ٹائم زون سیٹنگ سے میل نہیں کھائے گا — اس سے یہ گمان نہ کریں کہ آپ پرانے اندراج دیکھ رہے ہیں۔

WP-CLI کے ساتھ آپ فائل ہاتھ سے ایڈٹ کیے بغیر ان کونسٹنٹس کو بدل سکتے ہیں:

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

--raw فلیگ اہم ہے — اس کے بغیر قدر بولین کے بجائے سٹرنگ "true" کے طور پر لکھی جاتی ہے۔ پاتھ والی صورت میں --raw ہٹا دیں تاکہ وہ کوٹس میں سٹرنگ کے طور پر لکھی جائے۔

SSH نہیں ہے؟ فائل SFTP سے ڈاؤن لوڈ کریں یا ہوسٹ کے فائل مینیجر میں کھولیں۔ ایسے پلگ انز سے بچیں جو لاگ کو wp-admin کے اندر دکھاتے ہیں، الا یہ کہ آپ ان پر مکمل بھروسہ کرتے ہوں؛ آپ ایک پلگ ان کو ایسی فائل تک پڑھنے کی رسائی دے رہے ہیں جو سرور کی اندرونی تفصیلات سے بھری ہے۔

اگر آپ کو اپنے سیٹ اپ کے لیے بالکل درست wp-config بلاک چاہیے، بشمول ویب روٹ سے باہر کا محفوظ پاتھ اور اس سے میل کھاتا سرور رول، تو WordPress ڈی بگ لاگ جنریٹر اسے آپ کے لیے بنا دے گا۔

کام مکمل ہو جائے تو اسے بند کر دیں

WordPress کور میں کوئی چیز debug.log کو نہ گھماتی ہے نہ چھوٹا کرتی ہے۔ ایسی سائٹ پر جو ہر صفحہ لوڈ پر نوٹس پھینک رہی ہو، یہ بغیر کسی حد کے بڑھتی جاتی ہے اور ڈسک بھر سکتی ہے — جو سائٹ کو اُس بگ سے کہیں زیادہ بری طرح گرا دیتا ہے جس کے پیچھے آپ لگے تھے۔ لاگنگ آن کریں، مسئلہ دوبارہ پیدا کریں، لاگ پڑھیں، پھر WP_DEBUG کو واپس false کر دیں۔

فائل کو مٹائے بغیر خالی کرنے کے لیے:

: > wp-content/debug.log

جب لاگ خالی ہی رہے

ان باتوں کو ترتیب سے دیکھیں۔ WP_DEBUG کا false ہونا — سب سے عام وجہ، اور یہ باقی سب کچھ خاموشی سے بند کر دیتی ہے۔ کونسٹنٹ کا wp-config.php میں “stop editing” والی لائن سے نیچے ہونا۔ فائل پرمیشنز — PHP، wp-content میں یا آپ کی بتائی ہوئی کسٹم ڈائریکٹری میں لکھ نہیں سکتا۔ wp-config مکمل لوڈ ہونے سے پہلے کوئی فیٹل ایرر، مثلاً خود کنفیگ فائل میں سِنٹیکس کی غلطی، اتنی جلد ہو جاتی ہے کہ WordPress کی لاگنگ اسے پکڑ ہی نہیں سکتی؛ ایسی خرابیاں سرور کی اپنی PHP ایرر لاگ میں جاتی ہیں۔ آپ کے ہوسٹ کا اسے اوور رائیڈ کرنا — کچھ مینیجڈ پلیٹ فارمز PHP کی error_log سیٹنگ باندھ دیتے ہیں یا لاگنگ اپنے ڈیش بورڈ میں موڑ دیتے ہیں، ایسی صورت میں آپ کے کونسٹنٹس درست ہیں اور آؤٹ پٹ بس کہیں اور ہے۔ یہ فرض کرنے سے پہلے کہ آپ کی کنفیگ خراب ہے، ہوسٹ کا لاگ ویوَر دیکھ لیں۔