Playwright versus WordPress's "admin email confirmation" screen — how automation can clear the 6-month gate

If you drive the WordPress admin via Playwright for long enough, one day a screen you've never seen before will appear after login, and everything downstream stops working.

Is [email protected] still the correct admin email address?



[ Yes, the email is correct ]

[ Change the address ]

That's WordPress's admin email confirmation screen. Roughly every six months, after the admin user logs in, this confirmation screen gets injected — standard behavior since WP 4.9. A human just clicks once. An automation script can't see it without explicit handling.

Why automation gets stuck

A straightforward Playwright login looks like:

page.fill('#user_login', user)

page.fill('#user_pass', pwd)

page.click('input[type="submit"]')

page.wait_for_load_state('domcontentloaded')

# Assumes we're on the dashboard

page.goto('/wp-admin/plugins.php')

But on a "confirmation day," the URL right after wait_for_load_state is something like /wp-admin/profile.php?...action=confirm_admin_email... — the confirmation screen. You thought you were navigating to the plugins page, but the DOM you expected isn't there. Subsequent selectors fail, and everything downstream cascades into failure.

A specific selector identifies the screen

WordPress's confirmation screen has a uniquely-named submit button:

<input type="submit"

       name="correct-admin-email"

       value="Yes, the email is correct" />

If input[name="correct-admin-email"] exists on the page, you're on the confirmation screen. The same selector serves as both the detection signal and the click target, so handling is only a few lines:

admin_email_confirm = page.locator(

    'input[type="submit"][name="correct-admin-email"]'

)

if admin_email_confirm.count() > 0:

    logger.info("Confirmation screen detected — clicking 'email is correct'")

    admin_email_confirm.first.click()

    page.wait_for_load_state('domcontentloaded', timeout=30000)

Insert this after the post-login wait_for_load_state and before subsequent navigation. It runs transparently whether the screen appears or not.

Handler omission via code duplication

Internally, we had four places running this same login handling:

• The main maintenance login flow ✓


• The login used by visual_check (pre/post screenshot capture) ✓


• The login used for thumbnail capture ✓


• The login used by browser-based residual update (the path that handles plugins with proprietary updaters) ❌

The last one — added later — forgot to copy the confirmation-screen handler from the existing three. The downstream effect: when the confirmation screen showed up, automated updates for ACF Pro / Yoast SEO Premium / WP Rocket / Elementor Pro could be missed entirely.

A similar structural pattern appeared in our seven-format SSH private-key compat loader work: when the same logic lives in multiple copies, additions to one copy tend to drop functionality from others. The realistic mitigations are either deduplicating after the fact, or — at minimum — running tests that exercise the same behavior across every duplicate.

Regression-proofing through tests

Three tests went in with the fix:

1. 
   Confirmation screen present → click happens: With a mock returning the confirmation HTML, the click() call fires


2. 
   Confirmation screen absent → click does NOT happen: With normal dashboard HTML, the click is suppressed (no false positive)


3. 
   Click happens but auth still fails → still treated as a login failure: If the confirmation gets clicked but the dashboard never loads, the function does not incorrectly report success

Tests 2 and 3 specifically guard against "the new handler introducing a different kind of misbehavior." Negative tests that run alongside a feature addition are quietly effective at preventing regressions.

Takeaway — WordPress's "six-month trap"

Long-running Playwright operations against WordPress admin keep encountering screens you don't see during implementation but that appear half a year later and break everything. The admin-email confirmation screen is the canonical example: it's invisible during testing on a Monday, but on the day it appears, the whole flow falls over.

Two practices keep WordPress + Playwright automation stable for the long haul: write the confirmation screen into the code explicitly, and if your login code is duplicated across multiple call sites, make sure the same handling is in every one.