WordPress Plugin Review Checker
Scans your plugin's readme.txt and PHP source for the patterns behind common
wordpress.org Plugin Directory review rejections: a Stable tag that doesn't
match your plugin header's Version, missing required readme/header fields, a
$_GET/$_POST/$_REQUEST/$_COOKIE/$_SERVER
value echoed with no escaping function, and $_POST handling with no nonce check
anywhere in the file. Everything runs in this tab; nothing is uploaded. A command-line version
for CI is in the same
repository
(node check.mjs .).
Open your plugin's folder and select every
.php file plus readme.txt
(select-all works). Not at your project right now? instead.No files selected yet.
Common questions
Why does a Stable tag / Version mismatch matter for WordPress plugin review?
The Plugin Directory serves whichever version readme.txt's Stable tag names, not whatever you most recently committed or tagged. If Stable tag still says an old version, users downloading or auto-updating your plugin get that old build even after you've shipped a new one -- and reviewers flag the mismatch on submission. This tool reads both files and tells you if they disagree.
What counts as "unescaped output" in a WordPress plugin?
Printing a value from $_GET, $_POST, $_REQUEST, $_COOKIE, or $_SERVER with echo/print/printf and no escaping function (esc_html, esc_attr, esc_url, sanitize_text_field, absint, and similar) wrapped around it. WordPress's own plugin-review guidance treats unescaped output as a security issue regardless of whether the specific input happens to be exploitable today -- the fix is standard, and reviewers ask for it as a matter of course.
Why does processing $_POST need a nonce check?
Without a nonce (check_admin_referer, check_ajax_referer, or wp_verify_nonce), a form handler can't tell a request submitted by your own plugin's form from one a malicious site tricked a logged-in user's browser into sending (cross-site request forgery). Plugin review looks for a nonce check anywhere in a file that processes $_POST; this tool does the same file-level check.
Is my plugin's source code uploaded anywhere?
No. The browser tool reads the files you select using the File API and never sends them anywhere -- everything happens in memory in your tab. The CLI never makes a network call either.
Does a clean report mean my plugin will pass wordpress.org Plugin Review?
No. This is evidence from pattern-matching your readme.txt, plugin header, and PHP source against known field names and function calls -- it is not the review process, and it is a line-level heuristic, not data-flow analysis. It can miss an escaping function applied a few lines away from the echo, a nonce check that exists but never actually runs before the $_POST read it's meant to guard, or a field spelled non-standardly. Always re-check against the Plugin Directory's own current guidelines before submitting.
More on the most common of these: Fixing a readme.txt "Stable tag" mismatch. Already run wordpress.org's own Plugin Check? See how it compares to this checker. Just reading the guidelines and checking your own files by eye? See what that read-through is most likely to miss.