जवाब स्पष्ट रूप से हाँ है, मुझे चिंता करनी चाहिए । कुछ शोध के बाद, मैंने पाया है कि चेतावनी उस सर्वर पर गलतफहमी से संबंधित है जिसे वर्डप्रेस होस्ट किया गया है (यानी, मेरे सर्वर की समस्या, वर्डप्रेस नहीं)।
आम गलतफहमी:
- सर्वर में DNS नहीं है, और इसलिए यह पता नहीं लगा सकता है कि "example.com" कौन है, भले ही यह स्वयं है।
- सर्वर प्रशासक, सुरक्षा में गुमराह करने की कोशिश में, "लूपबैक" अनुरोधों को अवरुद्ध कर चुके हैं, इसलिए यह वास्तव में खुद को कॉल बैक नहीं कर सकता है।
- सर्वर "mod_security" या इसी तरह की कोई चीज़ चला रहा है, जो ब्रेन-डेड कॉन्फ़िगरेशन के कारण कॉल को सक्रिय रूप से ब्लॉक करता है।
मेरे मामले में समस्या वास्तव में मेरे फ़ायरवॉल (pfSense) के कारण हुई थी, जिसमें डिफ़ॉल्ट रूप से "NAT अक्षम करें" (सामान्य कारण # 2 के रूप में सूचीबद्ध) है।
सर्वर पर ही, मैंने टेलनेट का उपयोग करके खुद तक पहुंचने की कोशिश की, और परिणाम इस प्रकार था:
$ telnet external.server.hostname.com 19235
XXX.XXX.XXX.XXX की कोशिश कर रहा है ...
टेलनेट: दूरस्थ होस्ट से कनेक्ट करने में असमर्थ: कनेक्शन समयबद्ध
इसे ठीक करने के लिए, मुझे अपने फ़ायरवॉल पर डिसएबल NAT प्रतिबिंब को अनचेक करना पड़ा । मेरे मामले में, यह सिस्टम-> उन्नत-> फ़ायरवॉल / NAT के तहत pfSense के वेब इंटरफ़ेस में था।
स्रोत: http://forum.pfsense.org/index.php?topic=3473.0
अब मैं अपने आप को (सर्वर पर ही) फ़ायरवॉल के माध्यम से ठीक से कनेक्ट कर सकता हूं:
$ telnet external.server.hostname.com 19235
XXX.XXX.XXX.XXX की कोशिश कर रहा है ...
External.server.hostname.com से जुड़ा।
पलायन चरित्र '^] है।
और मुझे अब wp-cron के बारे में PHP की चेतावनी नहीं मिल रही है।
यह कैसे काम करता है, इसके बारे में विस्तृत जवाब पढ़ने के बाद मुझे लगा ।wp_cron
संक्षिप्त उत्तर: इसे अपनी wp-config.php फ़ाइल में परिभाषित करें: परिभाषित करें ('ALTERNATE_WP_CRON', सत्य);
मसोचवादियों के लिए वास्तव में लंबा जवाब: अनुसूचित पद अब नहीं हैं, और कभी भी "टूट" नहीं गए हैं। वर्डप्रेस के डेवलपर्स इसे ठीक नहीं कर सकते क्योंकि ठीक करने के लिए कुछ भी नहीं है।
समस्या इस तथ्य में निहित है कि आपका सर्वर, किसी कारण से, wp-cron प्रक्रिया को ठीक से निष्पादित नहीं कर सकता है। यह प्रक्रिया वर्डप्रेस का टाइमिंग मैकेनिज्म है, यह निर्धारित पोस्ट्स से लेकर XMLRPC पिंग्स आदि के लिए पिंगबैक भेजने तक सब कुछ संभालती है।
जिस तरह से यह काम करता है वह बहुत सरल है। जब भी कोई वर्डप्रेस पेज लोड होता है, तो आंतरिक रूप से वर्डप्रेस यह देखने के लिए जांचता है कि क्या इसे wp-cron से फायर करने की जरूरत है (वर्तमान समय की तुलना करते हुए wp-cron चला गया)। अगर इसे wp-cron को चलाने की आवश्यकता है, तो यह wp-cron.php फ़ाइल को कॉल करते हुए, अपने आप को एक HTTP कनेक्शन बनाने की कोशिश करता है।
यह कनेक्शन अपने आप में एक कारण से है। wp-cron में बहुत काम करना है, और उस काम में समय लगता है। उपयोगकर्ता को अपने वेबपेज को देखने में देरी करना, जबकि यह सामान का एक गुच्छा होता है, एक बुरा विचार है, इसलिए उस कनेक्शन को स्वयं बनाकर, यह एक अलग प्रक्रिया में wp-cron प्रोग्राम चला सकता है। चूंकि वर्डप्रेस स्वयं wp-cron के परिणाम के बारे में परवाह नहीं करता है, यह केवल एक सेकंड का इंतजार करता है, फिर उपयोगकर्ता के लिए वेबपृष्ठ प्रदान करने के लिए वापस जाता है। इस बीच, wp-cron लॉन्च किया गया है, अपना काम तब तक करता है जब तक कि यह खत्म न हो जाए या यह निष्पादन के समय से बाहर न हो जाए।
यह HTTP कनेक्शन वह जगह है जहाँ कुछ बुरी तरह से कॉन्फ़िगर की गई प्रणाली विफल हो जाती है। असल में, वर्डप्रेस एक वेब ब्राउज़र की तरह काम कर रहा है। यदि आपकी साइट
http://example.com/blog थी , तो WP प्रक्रिया शुरू करने के लिए http://example.com/blog/wp-cron.php पर कॉल करेगा
। हालाँकि, कुछ सर्वर किसी कारणवश ऐसा नहीं कर सकते हैं। संभावित कारणों में से:
- सर्वर में DNS नहीं है, और इसलिए यह पता नहीं लगा सकता है कि "example.com" कौन है, भले ही यह स्वयं है ।
- सर्वर प्रशासक, सुरक्षा में गुमराह करने की कोशिश में, "लूपबैक" अनुरोधों को अवरुद्ध कर चुके हैं, इसलिए यह वास्तव में खुद को कॉल बैक नहीं कर सकता है।
- सर्वर "mod_security" या इसी तरह की कोई चीज़ चला रहा है, जो ब्रेन-डेड कॉन्फ़िगरेशन के कारण कॉल को सक्रिय रूप से ब्लॉक करता है।
- कुछ और।
मुद्दा यह है कि जो भी कारण से, आपका वेब सर्वर कुछ गैर-मानक तरीके से कॉन्फ़िगर किया गया है जो वर्डप्रेस को अपना काम करने से रोक रहा है। वर्डप्रेस बस इसे ठीक नहीं कर सकता।
हालाँकि, यदि आपके पास यह स्थिति है, तो वर्कअराउंड है। अपनी wp-config.php फ़ाइल में परिभाषित करने के लिए इसे जोड़ें:
परिभाषित ('ALTERNATE_WP_CRON', सत्य);
यह वैकल्पिक विधि एक पुनर्निर्देशन दृष्टिकोण का उपयोग करती है, जो क्रोन को चलाने की आवश्यकता होने पर उपयोगकर्ताओं के ब्राउज़र को पुनर्निर्देशित करता है, जिससे कि वे तुरंत साइट पर वापस आ जाते हैं, जबकि क्रोन कनेक्शन में चलना जारी रखते हैं। यह तरीका थोड़ा इफ़्फ़्फ़ी होता है कभी-कभी, यही कारण है कि यह डिफ़ॉल्ट नहीं है।
स्रोत: http://wordpress.org/support/topic/scheduled-posts-still-not-working-in-282#post-1175405
जैसा कि इस महान और विस्तृत पोस्ट में कहा गया है, यदि आपके पास अपने सर्वर कॉन्फ़िगरेशन पर कोई नियंत्रण नहीं है या, यदि लागू हो, तो पर्यावरण - एक वर्कअराउंड डालना है
परिभाषित ('ALTERNATE_WP_CRON', सत्य);
अपनी wp-config.php फ़ाइल में।
allow_url_fopenचालू है?