What Plugin Check can’t see in a real wp-admin

Plugin Check (and the checks WordPress.org runs on upload) is good at a specific job: does this zip look like a plugin the directory can accept? Headers, text domain, discouraged APIs, readme shape, a pile of static smells. Run it. Fix what it finds. Do not confuse that with someone opened wp-admin and completed the job your plugin claims to do.

Those are different questions. Plugin authors mix them up because both live under “QA,” and because a passing check feels like a ship gate. wp-admin does not care about your PHPCS score.

What Plugin Check is actually for

Treat it as a directory and hygiene gate, not a user test:

• Plugin headers, naming, and load order that make WordPress load you at all
• i18n wiring, escaping patterns, and obvious unsafe APIs
• Readme / trademark / “this will get bounced on upload” issues
• Deprecated calls and other static “you will regret this on the next WP release” flags

That work is real. Reviewers and the plugin directory lean on it. A human sitting in wp-admin cannot see a missing text domain. Plugin Check cannot see a human stall.

What a real wp-admin pass still has to answer

Give a stranger wp-admin on a clean site with your plugin activated. Ask them to do the thing on the listing. Watch. The failures that matter for ship are usually not fatal errors.

They cannot find the product

The plugin is “active.” There is no obvious menu, or the menu is nested under Settings with a name only you use, or the first screen is a wall of tabs. Plugin Check does not score information architecture. Users do: they close the tab.

The control exists; the label lies

A checkbox saves. Nobody knows whether it applies to posts, to the whole site, or only after a cron run. Empty states say nothing. Success notices look like errors. That is still a failed path — the function worked and the person did not.

Roles and capabilities from the wrong chair

You tested as administrator. Shop managers, editors, or a client’s “almost admin” user hit a blank screen, a missing submenu, or a nonce failure. Static analysis does not sit in those roles. A brief that says “repeat the path as Editor” does.

Clicks that never hit PHP

Admin JS, Gutenberg panels, media modals, “save” that returns 200 and does not persist from the user’s point of view. Plugin Check is not a browser. If the bug is a click path, you need a click path — with a recording, not a lint report.

The rest of wp-admin is the environment

Your plugin is never alone for long: a theme, WooCommerce, a page builder, an SEO plugin, object cache. Plugin Check looks at your zip. Humans bring the mess. A green check is not the same as “plays nice with the rest of wp-admin.”

A wp-admin brief Plugin Check cannot replace

Keep it short and observable. Example mission:

• Log in to wp-admin on a site where the plugin is already active.
• Find the plugin’s primary screen without using the listing description.
• Complete one named job (create X, connect Y, save Z) until you see a definite success state.
• Note where you stalled, and mark that moment on the recording.

Form fields should match that list: found it / blocked; completed the job / no; where it broke; severity. Drop “what did you think of the plugin?” — that is not a ship question.

Keep this pass to one job

After Plugin Check is green, the question is narrow: can a person use wp-admin the way your readme implies? Do not load that session with every other risk — every PHP version, a full uninstall audit, every plugin combination. Those are real, and they deserve their own missions. One cold walkthrough of the primary admin path is enough for this gate.

On QATested

WordPress plugin testing on QATested is built for that wp-admin pass: upload the zip, each tester gets an isolated sandbox with the plugin installed and activated, then a recording plus a structured form you can approve or reject. How to set one up: WordPress plugin sandboxes.

Related: what human testing still reveals · brief, high-signal tests.