हाल ही में, मुझे एक दिलचस्प छोटी समस्या का पता चला। मैं अपनी केवल-पुस्तकों वाली वेबसाइट पर वर्डप्रेस चलाता हूं, और स्वाभाविक रूप से, यह सुनिश्चित करने के लिए परीक्षण किए जाने की आवश्यकता है कि सब कुछ हंकी-डोरी है, इससे पहले कि डोमेन में कोई भी बदलाव पेश किया जाए। ऐसा ही एक परिवर्तन था वर्डप्रेस 5.2 में साइट हेल्थ चेक टूल की शुरूआत, जो आपको किसी भी महत्वपूर्ण समस्या और आपके सेटअप के लिए अनुशंसित कार्यों के बारे में बताता है।
अपने आप में, यह ठीक है, लेकिन फिर मैंने 5.4 के अपडेट के साथ दिखाई देने वाली कुछ गंभीर त्रुटियों पर ध्यान दिया, जो डोमेन के साथ अचानक नई समस्या का संकेत देती हैं। त्रुटियाँ थीं:REST API में एक त्रुटि आई और आपकी साइट लूपबैक अनुरोध को पूरा नहीं कर सकी। इन दोनों के लिए विवरण पढ़ा गया:त्रुटि:cURL त्रुटि 28:10000 मिलीसेकंड के बाद 0 बाइट्स प्राप्त होने के बाद ऑपरेशन का समय समाप्त हो गया (http_request_failed)। अजीब। आइए डिबग करें।
समस्या के बारे में विस्तार से
गंभीर मुद्दे खतरनाक लगते हैं। लेकिन फिर, वास्तविक प्रभाव क्या है, यह समझने के लिए आपको संभावित समस्याओं को ध्यान से देखने की आवश्यकता है। अक्सर, कंपनियां इस बात को लेकर बहुत सख्त होती हैं कि वे किस तरह से बग और समस्याओं का इलाज करती हैं, क्योंकि कोई भी उन मुद्दों के साथ बहुत ढीले होने का आरोप नहीं लगाना चाहता है जो सुरक्षा जटिलताओं का कारण बन सकते हैं। तो आइए एक नजर डालते हैं स्टेटस रिपोर्ट पर:
पहला अंक इस प्रकार है:
REST API में एक त्रुटि आई
REST API एक तरह से वर्डप्रेस और अन्य एप्लिकेशन है, जो सर्वर के साथ संचार करते हैं। एक उदाहरण ब्लॉक एडिटर स्क्रीन है, जो आपके पोस्ट और पेजों को प्रदर्शित करने और सहेजने के लिए इस पर निर्भर करता है।
एक त्रुटि के कारण REST API अनुरोध विफल हो गया।
त्रुटि:cURL त्रुटि 28:10001 मिलीसेकंड के बाद 0 बाइट्स प्राप्त होने के बाद ऑपरेशन का समय समाप्त हो गया (http_request_failed)
दूसरे में निम्न पाठ है:
आपकी साइट लूपबैक अनुरोध को पूरा नहीं कर सकी
लूपबैक अनुरोधों का उपयोग शेड्यूल किए गए ईवेंट चलाने के लिए किया जाता है, और कोड स्थिरता को सत्यापित करने के लिए थीम और प्लगइन्स के लिए अंतर्निहित संपादकों द्वारा भी उपयोग किया जाता है।
आपकी साइट के लिए लूपबैक अनुरोध विफल हो गया, इसका मतलब है कि उन पर निर्भर सुविधाएं वर्तमान में उम्मीद के मुताबिक काम नहीं कर रही हैं।
त्रुटि:cURL त्रुटि 28:10001 मिलीसेकंड के बाद 0 बाइट्स प्राप्त होने के बाद ऑपरेशन का समय समाप्त हो गया (http_request_failed)
पहली त्रुटि हमें बताती है कि यह एक तरीका है जिसका उपयोग वर्डप्रेस सर्वर के साथ संवाद करने के लिए करता है - इसका मतलब है कि अन्य तरीके भी हैं। त्रुटि स्पष्ट नहीं है कि क्या यह वास्तव में विभिन्न कार्यों को निष्पादित करते समय संभावित समस्याएं पैदा करेगा।
यह विशेष रूप से ब्लॉक संपादक का उल्लेख करता है - वर्डप्रेस 5.0 में पेश की गई पूरी नई गुटेनबर्ग चीज़, जिसका मैं उपयोग नहीं करता, और इसके बजाय भयानक क्लासिक संपादक पर भरोसा करता हूं। तो शायद यह शुरू करने के लिए एक गैर-मुद्दा है। फिर, वास्तविक कार्यक्षमता का प्रश्न है - उल्लिखित कार्यों में से कोई भी प्रभावित नहीं होता है। वर्डप्रेस काम करता है और सब कुछ वैसा ही करता है जैसा उसे करना चाहिए। शायद एक झूठी सकारात्मक? हम जल्द ही देखेंगे।
दूसरी त्रुटि अनुसूचित घटनाओं के बारे में बात करती है - जैसे पृष्ठभूमि अद्यतन, रातोंरात कार्य, आदि। दोबारा, यदि आपने कोई भी कॉन्फ़िगर नहीं किया है, तो यह एक गैर-मुद्दा है। यदि आप करते हैं, और वे सही ढंग से चलते हैं, तो समस्या आपको प्रभावित नहीं करती है। त्रुटि "अपेक्षित रूप से काम कर रही है" कहती है - लेकिन यह एक बहुत ही निर्धारिती, सटीक कथन नहीं है। यह समस्या निवारण को और कठिन बना देता है।
समस्या का स्रोत
लेकिन आइए एक पल के लिए मान लें कि ये वास्तव में वास्तविक समस्याएं हैं। सवाल यह है कि आप समस्या निवारण कैसे करते हैं कि वे कहाँ से निकलते हैं? कोई आसान बात नहीं है, और वास्तविक त्रुटि संदेशों में ऐसा कुछ भी नहीं है जो आपको सही दिशा में ले जा सके।
इसलिए मुझे जो करना था वह मैन्युअल रूप से प्रत्येक गैर-डिफ़ॉल्ट घटक को एक-एक करके बंद करना था, और फिर स्वास्थ्य जांच को फिर से चलाना था, यह देखने के लिए कि क्या कोई विशेष तत्व गलती पर था। सौभाग्य से, मैं फुरसत के समय इसका परीक्षण कर सकता था, लेकिन उत्पादन सेटअप में प्रभाव की कल्पना करें।
अब ... थोड़ी देर के बाद, मैंने हर एक प्लगइन और थीम की कोशिश की थी जिसका मैं उपयोग कर रहा था, और इनमें से कोई भी परिणाम को प्रभावित नहीं कर रहा था। वर्डप्रेस ने शिकायत जारी रखी। फिर, मैंने अपनी खोज का विस्तार करने का निर्णय लिया। मैं व्यवस्थापक पृष्ठ पर अभिगम नियंत्रण की द्वितीयक परत के रूप में मूल प्रमाणीकरण और कुछ अन्य उपयोगी विवरणों के साथ एक .htaccess फ़ाइल का उपयोग कर रहा हूं। लो और निहारना, मूल भाग को हटाकर इसे ठीक कर दिया। अब और स्वास्थ्य जांच त्रुटियां नहीं!
AuthType बेसिक
AuthName प्रतिबंधित
AuthUserFile /home/mastablasta/wp-admin/passwd
मान्य-उपयोगकर्ता की आवश्यकता है
तो ऐसा लगेगा - WordPress Site Health को .htaccess फ़ाइलें पसंद नहीं हैं। मैंने ठीक से पता नहीं लगाया है कि यह कैसे चेक को ट्रिप करता है, लेकिन फिर, मुझे इसकी आवश्यकता नहीं है। एक, मुझे पता है कि समस्या का स्रोत क्या है। दो, त्रुटियां उस कार्यक्षमता को प्रभावित नहीं करती हैं जो मुझे चाहिए और चाहिए, इसलिए यह एक गैर-मुद्दा है।
निष्कर्ष
यह स्पष्ट है कि साइट स्वास्थ्य में समस्याएं आंतरिक हैं - आखिरकार, वे केवल वर्डप्रेस 5.4 की ओर बढ़ने के साथ ही शुरू हुईं। बेशक, कहीं न कहीं कोड का कुछ हिस्सा बदल गया है, लेकिन फिर, अनिवार्य रूप से, यदि एक मुख्य उत्पाद का व्यवहार अचानक अपडेट से ठीक पहले की तुलना में मौलिक रूप से भिन्न होता है, और साइट की कार्यक्षमता के अन्य तत्वों में कोई बड़ी समस्या नहीं है, तो यह है काफी संभावना है कि समस्या उक्त मुख्य उत्पाद अपडेट से उपजी है।
मुझे इस साइट-मुद्दे-पर-एक-नज़र की तरह का विचार पसंद है, लेकिन मैं झूठी सकारात्मकताओं से खुश नहीं हूं, या हंस का पीछा करता हूं कि त्रुटियों ने मेरे लिए बनाया है, भले ही केवल संक्षेप में। त्रुटियों को सार्थक होने की आवश्यकता है। अगर मुझे कोई अंतर्दृष्टि नहीं है कि त्रुटि प्रकट होने के तरीके से क्या गलत हो सकता है, तो वास्तव में तकनीकी विवरण दिखाने का कोई मतलब नहीं है। CURL त्रुटि 28 और .htaccess बहुत दूर दिखाई देते हैं। वैसे भी, हम यहाँ हैं। यदि आप इसी तरह की समस्या से प्रभावित हैं, तो अपनी साइट के कॉन्फ़िगरेशन पर एक नज़र डालें, देखें कि क्या आप मूल प्रमाणीकरण का उपयोग कर रहे हैं, और शायद उसी बग से पीड़ित हैं। हम यहाँ कर रहे हैं।
चीयर्स।