WordPress चा इन-बिल्ट admin-email verification स्क्रीन—जो व्हर्जन 5.3 पासून दर काही महिन्यांनी दिसतो—Playwright ऑटोमेशनमध्ये अडथळा निर्माण करतो, विशेषतः अशा साइट्सवर जिथे SSH ॲक्सेस नाही आणि प्लगइन्स अपडेट करायचे आहेत. ही अतिरिक्त पायरी स्क्रिप्टला अशा बटणासाठी थांबण्यास भाग पाडते जे कधीच दिसत नाही, ज्यामुळे टाइमआउट आणि डिप्लॉयमेंटमध्ये विलंब होतो.
अडथळा कशामुळे येतो
जेव्हा Playwright स्क्रिप्ट wp-admin मध्ये लॉग इन करते, तेव्हा डॅशबोर्ड लगेच लोड होईल अशी ती अपेक्षा करते. त्याऐवजी, WordPress कधीकधी अशा पेजवर रिडायरेक्ट करते ज्याच्या URL मध्ये adminhash= असते. ते पेज विचारते, “Is this still your address?” (हा अजूनही तुमचा पत्ता आहे का?) आणि त्यासोबत दोन बटणे असतात: Yes, this is my address आणि I’ll wait. एखादा माणूस “I’ll wait” वर क्लिक करतो आणि नंतर प्रक्रिया पुढे नेतो; परंतु अनअटेंडेड (unattended) स्क्रिप्ट डॅशबोर्डच्या एलिमेंट्स शोधत राहते, ते तिला कधीच सापडत नाहीत आणि शेवटी टाइमआउट होते.
ही सूचना का येते
ॲडमिन ईमेल पत्ता अजूनही कार्यरत आहे की नाही हे तपासण्यासाठी WordPress ने ही सूचना जोडली आहे. साइटच्या हालचालींचा विचार न करता, ही सूचना साधारणपणे दर काही महिन्यांनी येते. ज्या साइट मालकांना त्यांच्या ईमेलचा ॲक्सेस गमावला असू शकतो, त्यांच्यासाठी ही एक सुरक्षा तपासणी (security check) म्हणून डिझाइन केलेली आहे.
कोणावर परिणाम होतो
- डेव्हलपर्स (Developers) जे प्लगइन अपडेट्स पुश करण्यासाठी, UI टेस्ट्स चालवण्यासाठी किंवा मोठ्या प्रमाणावरील ॲडमिन टास्क करण्यासाठी Playwright वर अवलंबून आहेत.
- होस्टिंग प्रोव्हायडर्स (Hosting providers) जे SSH वर निर्बंध आणतात, ज्यामुळे वापरकर्त्यांना ब्राउझरद्वारे ऑटोमेशन करणे भाग पडते.
- साइट मालक (Site owners) ज्यांना अपडेट्स मिळण्यास उशीर होतो कारण ऑटोमेशन कधीच अपडेट स्क्रीनपर्यंत पोहोचू शकत नाही.
याचा खर्च केवळ काही सेकंदांचा अपव्यय इतकाच नाही; वारंवार होणाऱ्या अपयशामुळे नियोजित मेंटेनन्स विंडो (maintenance windows) थांबवू शकतात आणि मॅन्युअल हस्तक्षेप (manual intervention) करावा लागू शकतो.
नको असलेली स्क्रीन कशी ओळखाल
सध्याच्या URL मध्ये adminhash= असणे हा एक खात्रीशीर निर्देशक आहे. ही स्ट्रिंग फक्त ईमेल-व्हेरिफिकेशन पेजवर दिसते, नियमित डॅशबोर्डवर किंवा इतर कोणत्याही ॲडमिन स्क्रीनवर नाही.
एक सोपा उपाय (Bypass)
लॉगिन स्टेपनंतर लगेच एक चेक समाविष्ट करा. जर URL मध्ये adminhash= असेल, तर “I’ll wait” बटणावर क्लिक करा आणि प्रक्रिया पुढे नेण्यापूर्वी पेज स्थिर होण्याची प्रतीक्षा करा.
def ensure_past_email_check(page):
if "adminhash=" in page.url:
page.click("text=I'll wait")
page.wait_for_load_state("networkidle")
प्रत्येक यशस्वी लॉगिननंतर लगेच ensure_past_email_check(page) कॉल करा. जेव्हा व्हेरिफिकेशन स्क्रीन दिसत नाही, तेव्हा हे फंक्शन काहीही करत नाही, ज्यामुळे स्क्रिप्ट वेगवान आणि निश्चित (deterministic) राहते.
हा उपाय कधी वापरावा
मानवी देखरेखीशिवाय चालणाऱ्या ऑटोमेटेड वर्कफ्लोसाठी—जसे की नाईटली प्लगइन अपडेट्स किंवा continuous-integration UI टेस्ट्स—हा उपाय व्यावहारिक आहे. हे व्हेरिफिकेशन स्टेपला एखाद्या अनपेक्षित अपयशाऐवजी एका अंदाजित वळणासारखे (predictable detour) हाताळते.
प्रतिवाद (Counter-point)
काही ॲडमिनिस्ट्रेटर असा युक्तिवाद करतात की ही सूचना आपोआप नाकारल्यामुळे ईमेल-डिलिव्हरीची खरी समस्या लपली जाऊ शकते. जर ॲडमिन ईमेल खरोखरच पोहोचण्यायोग्य नसेल, तर साइट महत्त्वाच्या सूचना गमावू शकते. अशा परिस्थितीत, अधिक सूक्ष्म दृष्टिकोन—जसे की घटनेची नोंद करणे (logging the event), अलर्ट पाठवणे किंवा ऑटोमेशन थांबवणे—अधिक योग्य ठरू शकतो.
पुढील गोष्टींकडे लक्ष द्या
- WordPress URL पॅटर्न बदलू शकते किंवा अतिरिक्त व्हेरिफिकेशन स्टेप्स जोडू शकते, ज्यामुळे
adminhash=चेक निकामी होऊ शकतो. कोअर रिलीज नोट्सवर (core release notes) लक्ष ठेवा. - Playwright चे सिलेक्टर इंजिन (selector engine) विकसित होत असते; कोणताही UI रीडिजाइन झाल्यानंतर
"text=I'll wait"हा टेक्स्ट सिलेक्टर बटणाशी जुळत असल्याची खात्री करा. - जर तुम्ही अनेक साइट्स व्यवस्थापित करत असाल, तर कोडची पुनरावृत्ती टाळण्यासाठी शेअर केलेल्या लायब्ररीमध्ये (shared library) बायपास लॉजिक केंद्रीकृत करण्याचा विचार करा.
ॲडमिन-ईमेल कन्फर्मेशन पेजची स्पष्टपणे हाताळणी करून, डेव्हलपर्स अधूनमधून येणाऱ्या टाइमआउटला त्यांच्या Playwright स्क्रिप्टचा एक नियमित भाग बनवू शकतात, ज्यामुळे प्लॅटफॉर्म अनपेक्षित सुरक्षा सूचना देत असतानाही WordPress ऑटोमेशन विश्वसनीय राहते.