WordPress Debug Log Location: debug.log कहाँ होती है और इसे कैसे हटाएँ

WordPress डिफ़ॉल्ट रूप से अपना debug log wp-content/debug.log में लिखता है — डिस्क पर पूरा पाथ /path/to/your/site/wp-content/debug.log जैसा होता है। यह फाइल तब तक बनती ही नहीं जब तक कुछ सचमुच लॉग न हो, और लिखी तभी जाती है जब wp-config.php में WP_DEBUG true हो और WP_DEBUG_LOG चालू हो। यह डिफ़ॉल्ट जगह एक असली सिक्योरिटी समस्या भी है, क्योंकि ज्यादातर होस्ट पर कोई भी इसे ब्राउज़र में खोलकर ले जा सकता है।

तीन constants और हर एक का काम

तीनों wp-config.php में उस लाइन के ऊपर जाते हैं जिस पर लिखा है /* That's all, stop editing! Happy blogging. */। उस लाइन के नीचे जोड़ी गई कोई भी चीज WordPress के बूट हो जाने के बाद चलती है और अनदेखी रह जाती है।

Constant	डिफ़ॉल्ट	यह क्या करता है
WP_DEBUG	false	मुख्य स्विच। PHP की error रिपोर्टिंग बढ़ाकर notices, warnings और deprecations दिखाता है। इसके बिना इस सूची की कोई चीज काम नहीं करती।
WP_DEBUG_LOG	false	errors को एक फाइल में भेजता है। true का मतलब wp-content/debug.log। स्ट्रिंग दी जाए तो उसे लिखने का फाइल पाथ माना जाता है।
WP_DEBUG_DISPLAY	true	errors को पेज के HTML में छापता है, जो हर विजिटर को दिखती हैं।

जिस हिस्से में लोग गलती करते हैं वह है आपसी निर्भरता। WP_DEBUG_LOG को WordPress के स्टार्टअप कोड में WP_DEBUG वाली शाखा के अंदर ही पढ़ा जाता है। अगर WP_DEBUG false है, तो WP_DEBUG_LOG को true करने से कुछ भी नहीं होता — न फाइल, न error, न चेतावनी। अगर आपने WP_DEBUG_LOG जोड़ा है और कोई 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() जोड़ने के बजाय उसी मौजूदा लाइन को बदलें। एक ही constant को दो बार परिभाषित करने पर PHP warning आती है, जो डिस्प्ले चालू वाली साइट पर सीधे आपके पेज के सबसे ऊपर आ बैठती है।

प्रोडक्शन में WP_DEBUG_DISPLAY false क्यों होना चाहिए

डिस्प्ले चालू होने पर PHP errors HTML जवाब में छप जाती हैं। किसी theme से आई एक अकेली deprecation notice आपके सर्वर का पूरा फाइल सिस्टम पाथ हर विजिटर को दिखा देती है। डेटाबेस की एक error टेबल के नाम और query के टुकड़े छाप देती है। इससे भी बुरा, headers भेजे जाने से पहले निकला आउटपुट redirects तोड़ देता है, साफ JSON की उम्मीद करने वाले REST और AJAX जवाब तोड़ देता है, और वह सफेद स्क्रीन पैदा कर सकता है जिसका दोष लोग बाद में किसी plugin पर मढ़ते हैं।

एक बारीकी जान लेने लायक है: WP_DEBUG_DISPLAY को null करना false करने जैसा नहीं है। null WordPress से कहता है कि PHP की display_errors सेटिंग को छेड़े बिना वही मान ले जो सर्वर पर कॉन्फ़िगर है। false उसे सक्रिय रूप से बंद कर देता है। प्रोडक्शन साइट पर false इस्तेमाल करें और ऊपर वाली ini_set लाइन दोहरी सुरक्षा के तौर पर जोड़ें, क्योंकि कोई plugin request के बाद वाले हिस्से में display_errors दोबारा चालू कर सकता है।

डिफ़ॉल्ट जगह सार्वजनिक रूप से डाउनलोड की जा सकती है

wp-content/debug.log web root के अंदर बैठी होती है। स्टॉक WordPress इंस्टॉल में ऐसा कुछ नहीं है जो उस तक सीधी request रोके। सामान्य Apache या nginx सेटअप पर https://yoursite.com/wp-content/debug.log फाइल को प्लेन टेक्स्ट में लौटा देता है। Debug logs में सर्वर के पूरे पाथ, plugin और theme की आंतरिक जानकारी, असली query टेक्स्ट के साथ डेटाबेस errors, और कभी-कभी फेल होते फंक्शनों से गुजरी वैल्यूज होती हैं। जो कोई URL का अंदाजा लगा ले, उसके लिए यह मुफ्त की टोह है — और स्वचालित स्कैनर सबसे पहले जिन URLs को आजमाते हैं, यह उनमें से एक है।

इससे निपटने के दो तरीके हैं। बेहतर तरीका है log को कहीं और ले जाना।

पाथ देकर log को हटाएँ

WordPress 5.1 से WP_DEBUG_LOG boolean की जगह स्ट्रिंग फाइल पाथ भी स्वीकार करता है। इसे document root के बाहर कहीं इंगित करें:

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

उस पाथ के लिए तीन नियम। पूरा (absolute) पाथ इस्तेमाल करें — सापेक्ष पाथ PHP की working directory के हिसाब से हल होता है, जो हर request और हर सर्वर पर बदलता है, इसलिए आपको पता ही नहीं चलेगा कि फाइल कहाँ गई। डायरेक्टरी पहले से मौजूद होनी चाहिए; PHP उसे बनाएगा नहीं, और फाइल न खुल पाने पर चुपचाप फेल हो जाएगा। और डायरेक्टरी पर PHP यूजर के लिए लिखने की अनुमति होनी चाहिए, जो शेयर्ड होस्टिंग पर वह अकाउंट नहीं होता जिससे आप SFTP पर लॉगिन करते हैं।

अगर आपकी होस्टिंग आपको web root तक ही सीमित रखती है और उसके ऊपर लिखने की कोई जगह नहीं है, तो डिफ़ॉल्ट पाथ रहने दें और सर्वर स्तर पर एक्सेस ब्लॉक करें। Apache:

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

यह wp-content के अंदर वाली .htaccess फाइल में जाता है, रूट वाली में नहीं — permalinks सेव करने पर WordPress रूट की .htaccess दोबारा लिखता है और आपका जोड़ा हुआ हिस्सा मिटा सकता है। nginx पर .htaccess का कोई मतलब नहीं होता; वहाँ सर्वर कॉन्फ़िग में location ब्लॉक चाहिए, जिसका मैनेज्ड होस्टिंग पर आमतौर पर मतलब है सपोर्ट से कहना।

ब्लॉक करने से क्या मिलता है, इस बारे में ईमानदार रहें: फाइल अब भी डिस्क पर उसी डायरेक्टरी में है जिसे वेब सर्वर परोसता है। किसी भी plugin में path-traversal की एक खामी उसे अब भी पढ़ सकती है। उसे web root से बाहर ले जाना ज्यादा मजबूत हल है।

फाइल पढ़ना और tail करना

SSH पर, बग दोहराते हुए उसे लाइव देखें:

tail -f wp-content/debug.log

दूसरे टैब में error दोहराएँ और नई लाइनें लिखते ही दिखने लगेंगी। सिर्फ हाल की गतिविधि देखने के लिए, या किसी एक plugin तक छानने के लिए:

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

PHP फाइल के अंत में जोड़ता जाता है, इसलिए नीचे से ऊपर की ओर पढ़ें। हर एंट्री का टाइमस्टैम्प UTC में होता है, जो आपकी WordPress टाइमजोन सेटिंग से मेल नहीं खाएगा — इससे यह भ्रम न पालें कि आप पुरानी एंट्रियाँ देख रहे हैं।

WP-CLI से आप फाइल हाथ से एडिट किए बिना ये constants बदल सकते हैं:

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

--raw फ्लैग मायने रखता है — इसके बिना वैल्यू boolean की जगह "true" स्ट्रिंग के रूप में लिखी जाती है। पाथ वाले रूप के लिए --raw हटा दें ताकि वह कोट में स्ट्रिंग की तरह लिखा जाए।

SSH नहीं है? फाइल SFTP से डाउनलोड करें या होस्ट के फाइल मैनेजर में खोलें। ऐसे plugins से बचें जो log को wp-admin के अंदर दिखाते हैं, जब तक आप उन पर पूरा भरोसा न करते हों; आप एक plugin को सर्वर की आंतरिक जानकारी से भरी फाइल पढ़ने का अधिकार दे रहे होते हैं।

अगर आप अपने सेटअप के लिए ठीक-ठीक wp-config ब्लॉक चाहते हैं, जिसमें root से बाहर का सुरक्षित पाथ और उससे मेल खाता सर्वर नियम भी हो, तो WordPress debug log generator उसे आपके लिए बना देगा।

काम खत्म होने पर इसे बंद कर दें

WordPress core में ऐसा कुछ नहीं है जो debug.log को घुमाए या छोटा करे। हर पेज लोड पर notice फेंकने वाली साइट पर यह बिना सीमा बढ़ती जाती है और डिस्क भर सकती है — जिससे साइट उस बग से भी ज्यादा बुरी तरह बैठ जाती है जिसे आप ढूँढ रहे थे। लॉगिंग चालू करें, समस्या दोहराएँ, log पढ़ें, फिर WP_DEBUG वापस false कर दें।

फाइल को मिटाए बिना खाली करने के लिए:

: > wp-content/debug.log

जब log खाली ही रह जाए

इन्हें इसी क्रम में जाँचें। WP_DEBUG false है — सबसे आम वजह, और यह चुपचाप बाकी सब कुछ बंद कर देती है। constant wp-config.php में “stop editing” लाइन के नीचे है। फाइल permissions — PHP wp-content में, या आपकी बताई हुई कस्टम डायरेक्टरी में, लिख नहीं पा रहा। wp-config के पूरा लोड होने से पहले ही कोई fatal error, जैसे खुद कॉन्फ़िग फाइल में सिंटैक्स की गलती, इतनी जल्दी होती है कि WordPress की लॉगिंग उसे पकड़ ही नहीं पाती; वे सर्वर के अपने PHP error log में जाती हैं। आपका होस्ट इसे ओवरराइड कर रहा है — कुछ मैनेज्ड प्लेटफॉर्म PHP की error_log सेटिंग तय कर देते हैं या लॉगिंग को अपने डैशबोर्ड में भेज देते हैं, जिस स्थिति में आपके constants सही हैं और आउटपुट बस कहीं और है। अपना कॉन्फ़िग खराब मानने से पहले होस्ट का log व्यूअर देखें।