WordPress کا بلٹ ان ایڈمن ای میل تصدیق اسکرین—جو ورژن 5.3 سے ہر چند ماہ بعد نظر آتی ہے—ان سائٹس پر Playwright آٹومیشن کو ناکام بنا دیتی ہے جہاں SSH تک رسائی نہیں ہوتی اور پلگ انز کو اپ ڈیٹ کرنا ہوتا ہے۔ یہ اضافی مرحلہ اسکرپٹس کو ایک ایسے بٹن کا انتظار کرنے پر مجبور کرتا ہے جو کبھی ظاہر ہی نہیں ہوتا، جس کی وجہ سے ٹائم آؤٹ اور ڈیپلائمنٹس رک جاتی ہیں۔

رکاوٹ کی وجہ کیا ہے

جب ایک Playwright اسکرپٹ wp-admin میں لاگ ان ہوتا ہے تو وہ توقع کرتا ہے کہ ڈیش بورڈ فوری طور پر لوڈ ہو جائے گا۔ اس کے بجائے، WordPress کبھی کبھار ایک ایسے صفحے پر ری ڈائریکٹ کر دیتا ہے جس کے URL میں adminhash= شامل ہوتا ہے۔ وہ صفحہ پوچھتا ہے، "کیا یہ اب بھی آپ کا پتہ ہے؟" جس میں دو بٹن ہوتے ہیں: Yes, this is my address اور I’ll wait۔ ایک انسان "I’ll wait" پر کلک کرتا ہے اور بعد میں کام جاری رکھتا ہے؛ جبکہ ایک خودکار اسکرپٹ ڈیش بورڈ کے عناصر کو تلاش کرتا رہتا ہے، انہیں کبھی نہیں پا سکتا، اور آخر کار ٹائم آؤٹ ہو جاتا ہے۔

یہ پرامپٹ کیوں موجود ہے

WordPress نے یہ پرامپٹ اس بات کی تصدیق کے لیے شامل کیا ہے کہ ایڈمن ای میل ایڈریس اب بھی قابل رسائی ہے۔ یہ سائٹ کی سرگرمی سے قطع نظر، تقریباً ہر چند ماہ بعد ظاہر ہوتا ہے، اور اسے ان سائٹ مالکان کے لیے ایک سیکیورٹی چیک کے طور پر ڈیزائن کیا گیا ہے جنہوں نے شاید اس ایڈریس تک رسائی کھو دی ہو۔

کون متاثر ہوتا ہے

  • Developers جو پلگ ان اپ ڈیٹس کرنے، UI ٹیسٹ چلانے، یا بڑے پیمانے پر ایڈمن ٹاسک انجام دینے کے لیے Playwright پر انحصار کرتے ہیں۔
  • Hosting providers جو SSH پر پابندی لگاتے ہیں، جس سے صارفین کو براؤزر کے ذریعے آٹومیشن کرنے پر مجبور ہونا پڑتا ہے۔
  • Site owners جنہیں اپ ڈیٹس میں تاخیر کا سامنا کرنا پڑتا ہے کیونکہ آٹومیشن کبھی اپ ڈیٹ اسکرین تک نہیں پہنچ پاتی۔

اس کا نقصان صرف چند سیکنڈوں کا ضیاع نہیں ہے؛ بار بار ہونے والی ناکامیاں شیڈول شدہ مینٹیننس ونڈوز کو روک سکتی ہیں اور دستی مداخلت (manual intervention) پر مجبور کر سکتی ہیں۔

غیر مطلوبہ اسکرین کی شناخت کرنا

موجودہ URL میں adminhash= کی موجودگی ایک قابل اعتماد اشارہ ہے۔ یہ اسٹرنگ صرف ای میل تصدیق والے صفحے پر ظاہر ہوتی ہے، عام ڈیش بورڈ یا کسی دوسرے ایڈمن اسکرین پر نہیں۔

ایک سادہ بائی پاس

لاگ ان مرحلے کے فوراً بعد ایک چیک شامل کریں۔ اگر 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) رہتا ہے۔

بائی پاس کب استعمال کریں

ان خودکار ورک فلو کے لیے جنہیں انسانی نگرانی کے بغیر چلنا چاہیے—جیسے کہ رات کے وقت پلگ ان اپ ڈیٹس یا کنٹینیوس انٹیگریشن (CI) UI ٹیسٹ—یہ بائی پاس عملی ہے۔ یہ تصدیقی مرحلے کو کسی اچانک ناکامی کے بجائے ایک متوقع موڑ کے طور پر لیتا ہے۔

مخالف نقطہ نظر

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

مستقبل میں کن باتوں کا خیال رکھیں

  • WordPress URL کا پیٹرن تبدیل کر سکتا ہے یا مزید تصدیقی مراحل شامل کر سکتا ہے، جس سے adminhash= چیک ناکام ہو جائے گا۔ کور ریلیز نوٹس پر نظر رکھیں۔
  • Playwright کا سلیکٹر انجن ارتقاء پذیر ہے؛ اس بات کو یقینی بنائیں کہ کسی بھی UI ری ڈیزائن کے بعد ٹیکسٹ سلیکٹر "text=I'll wait" بٹن سے مطابقت رکھتا رہے۔
  • اگر آپ بہت سی سائٹس کا انتظام کرتے ہیں، تو کوڈ کے دوہراؤ سے بچنے کے لیے بائی پاس لاجک کو ایک مشترکہ لائبریری میں مرکزی حیثیت دینے پر غور کریں۔

ایڈمن ای میل کنفرمیشن پیج کو واضح طور پر ہینڈل کر کے، ڈویلپرز کبھی کبھار ہونے والے ٹائم آؤٹ کو اپنے Playwright اسکرپٹس کا ایک معمول کا حصہ بنا لیتے ہیں، جس سے WordPress آٹومیشن قابل اعتماد رہتی ہے، چاہے پلیٹ فارم کوئی غیر متوقع سیکیورٹی پرامپٹ ہی کیوں نہ دے دے۔

Source: https://dev.to/susumun/browser-based-updates-getting-stuck-on-the-confirm-your-admin-email-screen-why-playwright-6io