wp-admin-browser

WordPress Admin via Browser (Chrome DevTools MCP)

Model note: Primarily MCP tool calls — navigate, fill, click. haiku works for simple CRUD flows. Complex UI sequences (multi-step forms, dynamic AJAX state) use sonnet to handle unexpected DOM states.

When to use

• "Log in to the WordPress admin", "navigate to Settings > General", "create a test user".
• "Submit a form in WP admin", "upload a file via the media library", "save plugin settings".
• "Create a temporary admin account for testing instead of using the main admin user".
• "Verify a feature works end-to-end through the browser UI".

Not for: Headless automated testing without a real browser — use wp-plugin-testing. PHP code changes and plugin logic that don't require browser interaction.

Core Rules — Non-Negotiable

1. Never touch the main admin user. Always create a temporary admin for testing.
2. All data operations go through the browser UI. No WP-CLI, no direct DB, no REST API calls to mutate data — use WordPress forms.
3. Navigate via menus, not hardcoded URLs. Click the menu item; don't jump straight to /wp-admin/users.php?action=....
4. Use fill_form + click for all inputs. Never skip the form and post directly.

---

Step 1 — Log In

// POST to wp-login.php via fetch (fastest, no UI needed for login itself)
async () => {
  const res = await fetch('/wp-login.php', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: new URLSearchParams({
      log: 'YOUR_USER',
      pwd: 'YOUR_PASS',
      'wp-submit': 'Log In',
      redirect_to: '/wp-admin/',
      testcookie: '1',
    }),
    credentials: 'include',
    redirect: 'follow',
  });
  return { ok: res.ok, url: res.url };
}

Login via fetch is acceptable because it's a pure auth step — no data mutation.

---

Step 2 — Create a Temporary Admin User

Always create a temp user before any testing that requires admin actions.

Navigate to Users → Add New via menu clicks, not direct URL.