mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-08 11:46:35 +00:00
kevinveenbirkenbachandClaude Opus 5.5
6df5f2be86
On a multisite network WP-CLI's `user create` runs wpmu_validate_user_signup(), which only accepts lowercase letters and digits. The MCP subscriber was declared as `mcp-wordpress`, so every variant with `multisite.enabled: true` (variant 1) stopped at "Create the subscriber the MCP adapter authenticates as" with "Usernames can only contain lowercase letters (a-z) and numbers." (WordPress#1 in runs 40625679270 and 40243434327). meta/users.yml now declares `mcpwordpress`. The users dict is the one place the login lives: the role tasks, the MCP basic-auth login (mcp_client_login) and the MCP client configs (mcp_servers) all read users[owner].username, and the owner key, hence the token-store key, stays mcp-web-app-wordpress. The email follows the login. On an existing single-site install the next deploy creates mcpwordpress, mints its application password and replaces the stored token; the old mcp-wordpress subscriber is left in place with its now untracked "mcp" application password. Remove it with `wp user delete mcp-wordpress`. test_multisite_usernames mirrors the multisite signup checks (charset, reserved names, 4-60 characters, not all digits): every account the role declares passes, and mcp-wordpress, `_`, `.`, uppercase, too short, all digits, admin and too long are refused. With the old login the test fails with WordPress's own message. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>