ブラウザ補完更新で「管理者メール確認」画面に詰まる罠 — Playwright が wp-admin 操作で止まる理由

SSH が使えないホスティング環境では、Playwright で wp-admin にログインしてプラグイン更新画面を直接操作する経路を用意している。多くの場面ではこれで問題なく動くが、ある日突然、プラグイン更新画面に到達する前のステップでスクリプトが止まることがある。

補足: Playwright はブラウザを自動操作するツール。人が手でクリックする操作を、コードで再現できる。

「管理者メール確認」画面とは

WordPress 5.3 以降、管理画面には半年に一度のタイミングで「管理者メールアドレスの確認」を求める画面が挟まる。サイト所有者が今でもそのメールアドレスにアクセスできるかを確認する、WordPress コア側の仕様だ。

このメールアドレスは今でも使用していますか?
[ はい、これでお願いします ]  [ 後で確認する ]

通常のログイン操作であれば、人が見て「後で確認する」を押せば済む。しかし Playwright スクリプトは「ログイン → wp-admin のプラグイン更新画面に直接遷移」という決まった手順しか想定していないため、この画面が挟まると次のステップに進めず、そこで処理が停止する。

何が起きるか

ログイン自体は成功している。だが遷移先 URL が wp-admin/index.php ではなく wp-admin/options-general.php?adminhash=... の確認画面になっているため、後続のプラグイン更新画面への goto() がこの確認画面によってリダイレクトされたり、想定したセレクタが見つからずタイムアウトする。

# ログイン直後に確認画面の有無をチェックする
if "adminhash=" in page.url:
    page.click("text=後で確認する")

ログイン後の遷移を待つ際に、URL に adminhash= が含まれているかどうかを見れば、この確認画面が挟まったことを検知できる。

半年ごとという周期の厄介さ

この画面は毎回出るわけではない。WordPress コアが「前回確認してから一定期間が経過した」と判断したときにだけ挟まる。つまり、何ヶ月も問題なく動いていた自動化が、ある日いきなり止まる形で現れる。発生頻度が低いからこそ、原因調査に時間がかかりやすい落とし穴になる。

対処方針

「後で確認する」ボタンを検知したら自動でクリックし、本来の更新フローに戻す処理を、ログイン直後の共通処理として常時挟んでおく。これにより、確認画面が出ても出なくても同じコードパスで先に進める。

def ensure_past_email_check(page):
    if "adminhash=" in page.url:
        page.click("text=後で確認する")
        page.wait_for_load_state("networkidle")

ログイン処理の直後に必ずこの関数を呼ぶようにしておけば、半年ごとの不意打ちに振り回されなくなる。

まとめ

Playwright の strict mode 違反と wp-admin の同一セレクタ問題と同じく、これは wp-admin の画面が必ずしも一直線に遷移しないという前提を、自動化スクリプト側がどこまで織り込めるかという話だ。SSH が使えない環境でブラウザ経由の保守を続けるなら、こうした「想定外の画面」を検知して通過させる仕組みは避けて通れない。同じく wp-admin を信用しすぎない発想は、ページのテキストから読み取ったバージョン番号の妥当性を検証する設計にも通じる。