What the WordPress.org Plugin Review Actually Checks

When I submitted SL Bank Pricing for WooCommerce to the official WordPress.org plugin directory, I expected a rubber stamp. What I got was closer to a code audit. Having now been through the process (and a major v2 rewrite since), here’s what the review team actually looks at — and how to pass on the first try.

1. Sanitize everything in, escape everything out

This is the number one rejection reason. Every value that crosses a trust boundary needs handling on both sides:

// In: sanitize at the point of capture.
$bank_name = sanitize_text_field( wp_unslash( $_POST['bank_name'] ?? '' ) );

// Out: escape at the point of output — even for values you saved yourself.
echo esc_html( $bank_name );
echo '<a href="' . esc_url( $account_url ) . '">';

The reviewers grep for echo $ and raw $_POST access. “I sanitized it on the way in” does not exempt you from escaping on the way out — they treat the database as untrusted, and so should you.

2. Nonces and capability checks on every action

Any form handler, AJAX endpoint or admin action needs both a nonce verification and a capability check. One without the other is a finding:

if ( ! current_user_can( 'manage_woocommerce' ) ) {
    wp_die( esc_html__( 'Not allowed.', 'sl-bank-pricing-for-woocommerce' ) );
}
check_admin_referer( 'slbp_save_settings' );

3. Prefix everything, and mind your footprint

Function names, classes, options, transients, script handles — all of it gets a unique prefix (mine is slbp_) or lives under a namespace. The review also checks that you clean up after yourself: my uninstall.php only erases options if the store owner explicitly opted in, which reviewers liked — deleting a merchant’s configuration by default is hostile.

4. No remote code, no tracking without consent, no sneaky loads

All JS and CSS must ship inside the plugin — no CDN-loaded libraries.
Enqueue only on the screens that need them. Loading your admin CSS on every wp-admin page is a finding.
Phone-home telemetry requires explicit opt-in and a privacy disclosure.

5. The readme is part of the review

readme.txt gets read by a human. Stable tag must match the plugin header, “Tested up to” must be current, and the description has to honestly say what the plugin does and doesn’t do. Mine states plainly that it displays pricing information and never processes payments — that single sentence pre-empted a whole category of reviewer questions.

Why it’s worth it

Passing the review is proof your code can survive scrutiny from strangers and run safely on thousands of sites. It sharpened how I write everything — client work included. If you’re sitting on a plugin idea, package it properly and submit it: the review team is strict, but the strictness is the value.

Questions about the process, or want a second pair of eyes on your submission? Get in touch.

What the WordPress.org Plugin Review Actually Checks (From Someone Who Passed It)