Nearly one-third of WordPress plugin submissions to wp.org get rejected on first review. The official Plugin Check tool catches obvious problems, but the review team's standards go much deeper. After years of watching plugin developers hit rejection walls, we built WP HealthKit specifically to bridge that gap — to show you what reviewers actually look for before you hit submit.
This guide walks you through the complete WordPress plugin submission process in 2026, from pre-submission requirements through handling reviewer feedback. We'll cover what gets plugins rejected, security standards you need to know, coding requirements, and the exact steps to take your plugin from development to the WordPress.org repository.
Table of Contents
- Understanding the WordPress Plugin Submission Process
- Pre-Submission Checklist: Get Ready to Submit
- Plugin Check (PCP) and Its Limitations
- The 10 Most Common Rejection Reasons
- Security Requirements You Can't Skip
- WordPress Coding Standards Explained
- Readme.txt Requirements and Best Practices
- How WP HealthKit Closes the Gap
- Step-by-Step Submission Workflow
- Post-Submission: What to Expect
- Frequently Asked Questions
Understanding the WordPress Plugin Submission Process
The WordPress.org plugin repository accepts thousands of submissions yearly. It's the largest plugin repository in the world, with over 58,000 free plugins available. Behind the scenes, a volunteer review team evaluates every submission against a strict set of guidelines covering security, code quality, documentation, and user impact.
Check your plugin against the WP HealthKit security leaderboard to see how it compares before submitting. For a quick pre-submission audit, upload your plugin to WP HealthKit and review the findings. Our plugin directory shows real audit scores from thousands of WordPress plugins — useful as a benchmark.
The review process isn't automated. Real reviewers read your code, test your plugin, and check whether it follows WordPress standards. This thoroughness is why WordPress plugins are generally safer than plugins from other sources — but it also means rejection is common and specific.
Your plugin travels through four main gates: automated checks via Plugin Check, initial human review, development team review if issues are found, and final approval. Most rejections happen at gates one and two. The good news? Almost all rejections are fixable. Plugins rarely get rejected because they're fundamentally flawed — they get rejected because they don't meet documented standards.
Understanding what each gate looks for saves you weeks of iteration. Plugin Check catches obvious issues. But the review team looks deeper. They check whether your code follows WordPress conventions, whether you've sanitized inputs properly, whether you've documented everything, and whether you've registered assets correctly.
The submission process changed slightly in 2025 with new requirements around block editor support and better documentation of filters and hooks. The 2026 landscape includes even stricter security scanning and emphasis on accessibility features. Knowing these current standards before you submit puts you ahead of 70% of developers.
Pre-Submission Checklist: Get Ready to Submit
Before uploading your plugin to wp.org, spend time on preparation. A solid pre-submission checklist prevents rejection and saves you from multiple rounds of back-and-forth feedback.
Start with your plugin structure. WordPress expects specific directory layouts. Your main plugin file should be in the root of your plugin directory, and the file should match your plugin slug. If your plugin is called "My Awesome Plugin," the slug should be something like my-awesome-plugin, and your main file should be my-awesome-plugin.php. This might seem obvious, but misaligned naming causes rejections.
Your plugin header — the comment block at the top of your main file — must include all required fields. Include Plugin Name, Plugin URI, Description, Version, Author, Author URI, License, License URI, Text Domain, Domain Path, and Requires at least. Missing any of these triggers automatic rejection. The Text Domain must match your plugin slug exactly. The License should be GPL v2 or compatible (the WordPress.org repository requires it).
Test your plugin on the two oldest officially supported WordPress versions plus the current version. In March 2026, that means testing on WordPress 6.4, 6.5, and the current release. Set up local test environments with each version. Test admin functionality, frontend functionality, and settings pages. Try edge cases — what happens when plugins conflict, when databases are slow, when users have limited permissions.
Use Plugin Check locally before uploading. The Plugin Check tool is your first line of defense. It won't catch everything reviewers look for, but failing Plugin Check locally guarantees rejection. You can run it from the command line or use the web version. Fix every warning Plugin Check reports — reviewers definitely see the same issues.
Set up your readme.txt file following the WordPress standard format. This file is part of your plugin's documentation and appears on the plugin's wp.org page. It needs specific sections like Description, Installation, FAQ, and Changelog. A poorly formatted readme.txt can trigger rejection even if your code is perfect. We'll dive deeper into readme.txt structure later.
Prepare your screenshots and promotional assets. The wp.org repository allows banner images, icons, and screenshots. While these aren't required for acceptance, having them makes your listing look professional and helps with search visibility. Screenshots should show actual plugin features, not mockups or stock images. Use real, representative screenshots.
Scan your plugin with security tools. Use tools like WPScan's code analysis or Patchstack's scanner to check for common vulnerabilities. These tools aren't perfect — they generate false positives — but they catch obvious problems like hardcoded credentials or SQL injection risks. Anything WPScan flags, the review team will definitely find.
Document every hook and filter you create. Reviewers check whether developers can extend your plugin using standard WordPress hooks. If your plugin has features that should be customizable via do_action() or apply_filters(), implement them and document them in your readme or code comments. Plugins that don't provide extension points often get rejected for being too rigid.
Create a changelog documenting all changes from version 1.0. The wordpress.org repository asks for version history. Write detailed release notes for each version even if you're a solo developer. This shows professionalism and helps reviewers understand your development process.
Get a WordPress.org account setup and test the submission form. You'll need a working email, a chosen plugin slug, and authentication. Test the form with a dummy submission so you understand the workflow before your actual submission.
Plugin Check (PCP) and Its Limitations
Plugin Check is the WordPress.org team's own automated validation tool. It runs 60+ individual checks covering code quality, security, and documentation. Running your plugin through Plugin Check before submission is mandatory — the review team will run it too, and obvious failures mean automatic rejection.
But here's what reviewers won't tell you: Plugin Check catches maybe 40% of what they actually check for. It's not designed to be comprehensive. It's designed to catch obvious, objective, automatable problems. The tool checks for things like missing text domain declarations, unescaped output, improper database queries, and file header requirements. These are the low-hanging fruit.
Plugin Check looks at your code structure and spots common mistakes. It verifies that you've declared your plugin correctly, that you're using sanitization and escaping appropriately, and that you're not doing anything obviously dangerous. But the human review team goes much deeper into context, intent, and edge cases.
For example, Plugin Check will flag an unescaped output. It will not evaluate whether your escaping is the right choice for that context, whether you've considered charset handling, or whether adjacent code creates security issues despite proper escaping. The review team will.
Plugin Check verifies that you've registered a text domain. It will not evaluate whether you've used it consistently throughout your plugin, whether you've provided translations, or whether your text strings are translatable without needing code refactoring. Again, the review team checks these details.
The tool catches unprepped database queries. It will not evaluate whether your query logic creates race conditions under high load, whether you've considered prepared statement parameter binding thoroughly, or whether you've properly escaped identifiers vs values. The review team understands these nuances.
This gap between automated and human review is exactly what makes third-party audit tools valuable. WP HealthKit runs the same checks as Plugin Check but adds contextual analysis — evaluating whether your choices make sense beyond just technical compliance. We look at whether your security implementation is thorough, whether your code is maintainable, and whether your approach follows WordPress philosophy.
To use Plugin Check effectively, run it locally first using the command-line version. This gives you faster feedback during development. Install the mu-plugin, activate it, and check your plugin from the browser interface. Fix every warning. Then run it one final time before submitting to wp.org. If it passes locally, it will pass in the repository's automated system.
Understanding Plugin Check's scope prevents false confidence. Passing Plugin Check doesn't mean you'll pass human review. It means you've met the baseline automated requirements. You still need to review coding standards, documentation, security practices, and design patterns thoroughly.
The 10 Most Common Rejection Reasons
After analyzing hundreds of rejection emails from wp.org reviewers, patterns emerge. The same ten issues appear again and again. Understanding these before you submit gives you a massive advantage.
1. Improper Text Domain Usage
Every piece of translatable text in your plugin should use your plugin's text domain. This includes strings in your admin pages, frontend content, and error messages. The mistake developers make is registering a text domain but not using it consistently.
// Wrong
echo "Welcome to my plugin";
// Correct
echo esc_html__( "Welcome to my plugin", "my-plugin-slug" );
The review team checks that you've wrapped every visible string in appropriate translation functions. They search for bare strings that look translatable but aren't marked for translation. This is tedious to check manually but essential for the WordPress ecosystem.
2. Unescaped Output in Admin Pages
Admin functionality seems safe because only logged-in users see it. Developers often skip escaping in admin screens, which is dangerous. Even administrators can be tricked into visiting malicious URLs that exploit unescaped output.
// Wrong
echo $_POST['user_input'];
// Correct
echo esc_html( wp_kses_post( $_POST['user_input'] ) );
The review team specifically tests admin pages with injected HTML and JavaScript. They verify that nothing renders without escaping. Every variable in echo, print, or attribute context needs escaping.
3. Nonces Missing or Misused
Nonces prevent cross-site request forgery attacks. Plugins need them on any action that modifies data. The issue isn't just whether nonces are present — it's whether they're implemented correctly and verified consistently.
// Wrong
wp_nonce_field( 'my_action' );
// ... later
check_admin_referer( 'my_action' ); // No nonce name validation
// Correct
wp_nonce_field( 'save_settings_nonce', 'settings_nonce' );
// ... later
check_admin_referer( 'save_settings_nonce', 'settings_nonce' );
Reviewers look for nonces on every form, every AJAX action, and every administrative function that changes data. They verify the nonce is checked before the action executes. They confirm the nonce name is specific to the action.
4. Database Sanitization Not Thorough
Prepared statements prevent SQL injection, but only if you implement them correctly. The most common mistake is mixing prepared statements with unescaped values, or using them on identifiers where they don't apply.
// Wrong
$result = wpdb->query(
"SELECT * FROM $wpdb->posts WHERE ID = " . $_GET['id']
);
// Correct
$result = wpdb->get_results(
$wpdb->prepare( "SELECT * FROM {$wpdb->posts} WHERE ID = %d", $_GET['id'] )
);
Reviewers spot these issues through code review. They trace how data flows from input to database. They verify prepared statements for read queries, not just write queries.
5. No Capability Checks on Admin Functions
WordPress has a capabilities system. Admin functions must verify user permissions before executing. Overlooking this is one of the easiest ways to create privilege escalation vulnerabilities.
// Wrong
function my_plugin_save_settings() {
update_option( 'my_plugin_settings', $_POST['settings'] );
}
// Correct
function my_plugin_save_settings() {
if ( ! current_user_can( 'manage_options' ) ) {
wp_die( esc_html__( 'Unauthorized', 'my-plugin-slug' ) );
}
update_option( 'my_plugin_settings', $_POST['settings'] );
}
Every admin page, AJAX handler, and REST endpoint needs capability checks. The review team reads through your admin code checking for current_user_can() calls. Missing them is an automatic rejection.
6. Incomplete or Missing Documentation
The readme.txt file is your plugin's storefront. Missing sections, unclear installation instructions, or vague descriptions confuse users and reviewers. The review team reads readme.txt to understand what your plugin does. If it's unclear, they reject it pending clarification.
=== My Plugin ===
Contributors: myname
Stable tag: 1.0
Requires at least: 6.0
Requires PHP: 7.4
License: GPL v2 or later
== Description ==
[Your description here]
== Installation ==
[Installation steps]
== FAQ ==
[Answer questions users might have]
== Changelog ==
= 1.0 =
* Initial release
Reviewers verify the format is correct, all required sections are present, and the descriptions are accurate. They test the installation steps to see if they work.
7. Hardcoded Values and Missing Settings Pages
Plugins shouldn't hardcode configuration. Any value that might vary — API keys, feature toggles, threshold values — should be a setting. This lets users customize your plugin rather than modifying code.
// Wrong
$api_key = "abc123xyz";
// Correct
$api_key = get_option( 'my_plugin_api_key' );
if ( empty( $api_key ) ) {
echo esc_html__( 'Please configure your API key', 'my-plugin-slug' );
return;
}
The review team looks for hardcoded values in your code. They expect to find a settings page where necessary configuration happens. Missing this indicates your plugin isn't production-ready.
8. Not Following WordPress Naming Conventions
WordPress has conventions for function names, class names, constant names, and variable prefixes. Not following them makes your plugin harder to maintain and risks conflicts with other code.
// Wrong
function save_data() {
// ...
}
// Correct
function my_plugin_save_data() {
// ...
}
Prefix all functions, classes, and constants with a unique namespace. Function names should use underscores between words. Class names should use PascalCase. The review team scans for bare function names that could conflict with other plugins or WordPress.
9. No Proper Use of WordPress Actions and Filters
Plugins should extend WordPress through hooks, not by directly modifying WordPress files or overriding WordPress functionality. If something can be done with add_action() or add_filter(), that's the WordPress way.
// Wrong
function my_plugin_init() {
// Directly modifying post object
global $post;
$post->post_title = "Modified";
}
// Correct
function my_plugin_modify_title( $title, $post_id ) {
if ( /* condition */ ) {
return "Modified: " . $title;
}
return $title;
}
add_filter( 'the_title', 'my_plugin_modify_title', 10, 2 );
Reviewers check whether you're using WordPress hooks appropriately. They look for unnecessary global variable access, direct database manipulation where filters would suffice, and other non-idiomatic approaches.
10. Inadequate or Missing Sanitization
Input sanitization prevents security issues. Every input your plugin accepts — from forms, URLs, API calls, or anywhere else — needs sanitization. The review team specifically tests with malicious input.
// Wrong
$email = $_POST['email'];
// Correct
$email = sanitize_email( $_POST['email'] );
if ( ! is_email( $email ) ) {
wp_die( esc_html__( 'Invalid email', 'my-plugin-slug' ) );
}
Use appropriate sanitization functions for each data type. Sanitize before validation. Validate after sanitization. Escape before output. The review team traces how user input flows through your code.
Security Requirements You Can't Skip
Security is non-negotiable in the WordPress.org repository. The review team takes security extremely seriously. Your plugin will be rejected if it has security vulnerabilities, even if the code is otherwise excellent.
WordPress security depends on three practices: sanitization, validation, and escaping. Sanitization cleans data. Validation checks data matches expected format. Escaping converts data safely for its context. Together, they prevent injection attacks.
Sanitization happens when you receive data. If a user submits a number, use intval(). If they submit email, use sanitize_email(). If they submit text with HTML, use wp_kses_post(). WordPress provides sanitization functions for every common data type. Use them.
// Example sanitization for different inputs
$count = intval( $_POST['count'] );
$email = sanitize_email( $_POST['email'] );
$url = esc_url_raw( $_POST['url'] );
$content = wp_kses_post( $_POST['content'] );
$title = sanitize_text_field( $_POST['title'] );
Validation checks whether sanitized data is actually acceptable. Just because something looks like a number doesn't mean you should use it — check it's within expected bounds.
$count = intval( $_POST['count'] );
if ( $count < 1 || $count > 100 ) {
wp_die( esc_html__( 'Count must be between 1 and 100', 'my-plugin-slug' ) );
}
Escaping prepares data for its context. HTML escaping uses esc_html(). Attribute escaping uses esc_attr(). URL escaping uses esc_url(). JavaScript escaping uses wp_json_encode(). Use the right escaping function for where your data goes.
// Different escaping for different contexts
echo esc_html( $user_input ); // HTML content
echo '<div class="' . esc_attr( $class ) . '">'; // HTML attributes
echo '<a href="' . esc_url( $url ) . '">'; // URLs
Nonces protect against cross-site request forgery. Any time your plugin changes state — saves settings, creates posts, deletes data — use a nonce. Generate it with wp_nonce_field() in forms or wp_create_nonce() in AJAX. Verify it with check_admin_referer() or wp_verify_nonce().
// In your form
wp_nonce_field( 'save_plugin_settings', 'plugin_settings_nonce' );
// When processing
if ( ! isset( $_POST['plugin_settings_nonce'] ) ||
! wp_verify_nonce( $_POST['plugin_settings_nonce'], 'save_plugin_settings' ) ) {
wp_die( esc_html__( 'Security check failed', 'my-plugin-slug' ) );
}
Database security means using prepared statements. Never interpolate user input into SQL queries. Always use $wpdb->prepare() with placeholders.
// Wrong
$results = $wpdb->get_results( "SELECT * FROM {$wpdb->posts} WHERE ID = {$_GET['id']}" );
// Correct
$results = $wpdb->get_results(
$wpdb->prepare( "SELECT * FROM {$wpdb->posts} WHERE ID = %d", $_GET['id'] )
);
Capability checks prevent privilege escalation. Before any admin action, verify the user has permission.
if ( ! current_user_can( 'manage_options' ) ) {
wp_die( esc_html__( 'Insufficient permissions', 'my-plugin-slug' ) );
}
The WordPress.org review team has access to security advisories and common vulnerability databases. They're looking for known attack patterns. If your plugin stores sensitive data, encrypt it. If it makes external API calls, use https. If it runs scripts, verify they come from trusted sources.
WordPress Coding Standards Explained
The WordPress community maintains PHP_CodeSniffer rules for WordPress coding standards. The review team uses these standards to evaluate code quality. Running your code through PHPCS with WordPress standards before submission saves you rejection emails.
Install PHPCS and WordPress standards locally.
composer require --dev wp-coding-standards/wpcs
Then scan your plugin.
vendor/bin/phpcs --standard=WordPress-Core --extensions=php src/
The WordPress coding standards cover naming conventions, spacing, file structure, and best practices. Function names should be lowercase with underscores. Class names should use PascalCase. Constants should be UPPERCASE. Indentation should be tabs (not spaces). Maximum line length is 120 characters.
// Correct naming and spacing
class My_Plugin_Admin {
private $option_name = 'my_plugin_settings';
public function __construct() {
add_action( 'admin_menu', array( $this, 'add_menu' ) );
}
}
Opening braces for classes and functions go on the same line. Opening braces for control structures go on the same line. Use spaces around operators.
// Correct spacing
function my_plugin_process_data( $data ) {
if ( ! isset( $data ) ) {
return false;
}
$result = $data * 2;
return $result;
}
The WordPress standards emphasize readability and consistency. Every line in a multi-line function call should have consistent indentation. Control structure bodies should be indented properly. Comments should precede the code they describe.
// Correct multi-line function call
$args = array(
'post_type' => 'post',
'posts_per_page' => 10,
'orderby' => 'date',
);
$query = new WP_Query( $args );
Use meaningful variable names. $user is better than $u. $post_count is better than $cnt. Avoid abbreviations unless they're extremely common in WordPress (like $wpdb).
Use single quotes for strings that don't contain variables. Use double quotes only when interpolating variables.
// Correct quoting
$message = 'Hello world';
$message = "Hello {$user_name}";
The review team runs PHPCS on your code and looks for violations. Major violations — things that suggest you haven't tested against standards — are rejection criteria. Minor violations might be flagged during review. Running PHPCS yourself prevents this entirely.
Readme.txt Requirements and Best Practices
Your readme.txt file is crucial. It appears on your plugin's wordpress.org page. It's the first thing users see. The review team reads it to understand what your plugin does. Format it correctly or face rejection.
The readme.txt file must follow a specific format. Begin with a header block containing plugin metadata.
=== Plugin Name ===
Contributors: your-wordpress-username
Plugin URI: https://your-website.com/plugin
Description: A one-line description of what your plugin does.
Version: 1.0.0
Author: Your Name
Author URI: https://your-website.com
License: GPL v2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html
Text Domain: my-plugin-slug
Domain Path: /languages
Requires at least: 6.0
Requires PHP: 7.4
Stable tag: 1.0.0
Tested up to: 6.4.1
The Description should be one line. Short. Clear. It appears as the plugin tagline. Then add a Description section with more detail.
== Description ==
Your longer description goes here. Explain what the plugin does, who it's for,
and what problems it solves. Use 2-3 paragraphs. This section appears on the
plugin page.
Add an Installation section explaining how to install your plugin.
== Installation ==
1. Upload the plugin files to the `/wp-content/plugins/my-plugin-slug/` directory
2. Activate the plugin through the 'Plugins' screen in WordPress
3. Use the Settings > My Plugin screen to configure the plugin
Include a Frequently Asked Questions section. This helps users and can reduce support burden.
== FAQ ==
= How do I configure the plugin? =
Go to Settings > My Plugin and enter your configuration.
= Does this work with WordPress multisite? =
Yes, it works on multisite networks.
Include a Changelog documenting changes in each version.
== Changelog ==
= 1.0.0 =
* Initial plugin release
* Added main features
* Fixed some bugs
= 0.9.0 =
* Beta release
Use proper markdown formatting in readme.txt. Sections use == Section Name ==. Subsections use = Subsection Name =. Use lists with - or *. Use backticks for code.
The review team verifies your readme.txt is properly formatted, all required sections are present, and the descriptions are accurate. They test the installation steps. Inconsistencies between readme.txt and actual functionality cause rejection.
The Stable tag tells WordPress.org which version is production-ready. It must match a version tag in your repository. The Tested up to field tells users you've tested this version with the WordPress version listed. Update it whenever WordPress releases a new major version.
Tested up to: 6.4.1
Stable tag: 1.0.0
How WP HealthKit Closes the Gap
Plugin Check catches about 40% of issues the review team checks for. It's an essential baseline tool. But developers still get rejected repeatedly for issues Plugin Check doesn't detect.
WP HealthKit bridges that gap. We run the same automated checks as Plugin Check, but we add contextual analysis that mimics how the WordPress.org review team actually evaluates plugins.
Our audit tool checks whether your security implementation is thorough, not just syntactically correct. We verify that nonces are used consistently across all state-changing operations. We check that escaping is appropriate for context. We ensure sanitization and validation work together properly.
We analyze your code structure and conventions. We verify naming patterns are consistent, that you're using hooks idiomatic ways, that you're not hardcoding values that should be configurable. We check whether your readme.txt is complete and matches your code.
WP HealthKit generates a detailed report showing exactly what reviewers will evaluate and where your plugin stands against their criteria. Rather than submitting, waiting weeks, then getting a rejection email with vague feedback, you know issues before submission.
Use WP HealthKit to audit your plugin before submitting to wordpress.org.
Run it on your plugin throughout development, not just before submission. It helps you build better code from the start. The feedback helps you understand WordPress conventions and security practices better.
Step-by-Step Submission Workflow
Ready to submit? Follow these exact steps.
Step 1: Final Testing and Validation
Run Plugin Check one last time. Fix any warnings or errors. Test your plugin on the two oldest supported WordPress versions and the current version. Verify all features work. Test with different user roles. Test in multisite if applicable.
Step 2: Run WP HealthKit Audit
Upload your plugin to WP HealthKit and run the audit. Review the report. Fix any issues identified. Re-run the audit if you made changes.
Step 3: Prepare Your Submission
Choose your plugin slug. This is permanent — choose carefully. The slug should be lowercase, use hyphens for spaces, and be descriptive of what your plugin does. Go to wordpress.org/plugins/submit/ and request the slug. WordPress approves most requested slugs within hours.
Good slugs:
- advanced-custom-fields
- jetpack
- akismet
- my-awesome-seo-plugin
Bad slugs:
- myplugin
- plugin-v1
- mysample
- test-plugin-123
Prepare your initial commit. WordPress.org checks your plugin's first commit message. It should be descriptive. Something like "Initial commit: Released version 1.0" is fine. Avoid vague messages like "First commit" or "Initial".
Prepare screenshots. WordPress.org recommends 440x440px images. They should show your plugin's user interface or the problem it solves. Add 1-4 screenshots for best results.
Step 4: Create Your WordPress.org Account
Visit wordpress.org and create an account if you don't have one. Verify your email. This account is how you'll manage your plugin. Keep the credentials safe — WordPress.org uses them for everything.
Step 5: Request Your Plugin Slug
Go to wordpress.org/plugins/submit/. Enter your chosen slug. Explain what your plugin does in a couple sentences. WordPress checks that the slug isn't taken and that your plugin description makes sense. They usually approve within 24 hours.
Step 6: Set Up Your Repository
Once approved, WordPress.org provides SVN repository access. They give you SVN credentials and repository URL. You'll commit your plugin files there, using either SVN client directly or the command-line svn tool.
svn checkout https://plugins.svn.wordpress.org/my-plugin-slug/trunk my-plugin-slug
cd my-plugin-slug
# Copy your plugin files here
svn add .
svn commit -m "Initial commit: Released version 1.0"
WordPress.org mirrors your SVN repository to github.com/WordPress/wordpress-plugins. Everything you commit to SVN appears there automatically. This is your official distribution channel.
Step 7: Submit for Review
WordPress.org reviews the first commit automatically. The review process begins. You'll see your plugin in "pending plugins" on wordpress.org. Within 1-7 days, a reviewer looks at your plugin.
The reviewer tests your plugin, reads your code, checks your documentation, and verifies security. They run Plugin Check. If everything passes, your plugin goes live. If issues exist, they email you with specific feedback.
Post-Submission: What to Expect
After you submit, WordPress.org reviews your plugin. The timeline varies — sometimes a day, sometimes a week. Reviews are done by volunteers, so there's no guaranteed SLA. During busy periods, reviews take longer.
You'll get an email when review starts. The reviewer tests your plugin, runs automated checks, and reads your code. They're looking for the ten common issues we discussed, plus security problems, documentation gaps, and code quality.
If issues exist, the reviewer sends an email explaining what needs fixing. They're usually specific. They might say "Lines 42-47 have unescaped output" or "Your readme.txt is missing the FAQ section" or "This function doesn't check user capabilities."
Responding to Reviewer Feedback
When you get feedback, don't panic. Rejections are fixable. The reviewer isn't saying your plugin is bad — they're saying it needs adjustments to meet standards.
Read the feedback carefully. The reviewer points out specific issues. Fix those issues. Don't try to argue about the standards — WordPress.org's standards are non-negotiable. Even if you disagree with a standard, conform to it. You can suggest improvements later once your plugin is accepted.
Fix the issues, commit your changes to SVN, and reply to the reviewer email saying you've made the changes. They'll review again. This back-and-forth continues until your plugin passes.
Be professional and grateful in your responses. Reviewers are volunteers. They're doing this for free, in their spare time. A polite "thank you for the feedback, I've made the corrections" response goes a long way. Arguing about standards or defending your code wastes time.
After Approval
Once approved, your plugin goes live on wordpress.org. It appears in search results. Users can install it from the Plugins screen in WordPress. It's distributed through CDN globally. Your plugin is now part of the WordPress ecosystem.
Start thinking about updates immediately. As WordPress evolves, your plugin needs updates too. Test with new WordPress versions. Monitor security advisories. When WordPress deprecates something you use, plan your migration. Keep your plugin actively maintained.
Set up a changelog process. Document changes in readme.txt whenever you release updates. WordPress.org uses the changelog to inform users about what's new. A detailed changelog helps users decide whether to update.
Monitor support. The wordpress.org plugin page has a support forum. Users ask questions there. Responding promptly to support threads builds reputation and catches bugs. Some developers check forums weekly; some use email notifications. Find a process that works for you.
Frequently Asked Questions
How long does the WordPress plugin review process take?
Review typically takes 1-7 days, depending on reviewer availability and how busy they are. During busy periods — like major WordPress releases — it can take longer. There's no guaranteed timeline. You can check your plugin's status on wordpress.org/plugins/pending/. If it's been more than two weeks, you can follow up with the support forum. Note that WP HealthKit can significantly accelerate this by preventing rejection cycles.
What if my plugin gets rejected — is it permanent?
No, rejection is not permanent. WordPress reviewers explain what needs fixing. You fix the issues, commit to SVN, and reply that you've made corrections. The reviewer looks at your changes. This continues until your plugin passes. Most plugins get approved within 2-3 feedback cycles.
Can I use external libraries or dependencies in my plugin?
Yes, you can use external libraries. But bundle them with your plugin — don't require users to install dependencies separately. Use Composer to manage dependencies during development, but commit the vendor directory to SVN so everything is self-contained. The review team checks that external libraries aren't outdated and don't introduce security issues.
Does my plugin need unit tests to be approved?
Unit tests aren't required for approval, but they're a good idea. WordPress doesn't mandate testing, but many plugins include tests to verify functionality and prevent regressions. Tests make your plugin more maintainable and help you catch bugs before users do.
What happens if I release an update that violates standards?
WordPress monitors active plugins. If an update introduces security issues or violates standards egregiously, WordPress can disable your plugin. This rarely happens to intentional violations. It's more common if compromised code gets committed. Keep your wordpress.org account credentials secure and enable two-factor authentication.
Can I have multiple plugin authors on one plugin?
Yes, multiple authors can manage one plugin. On your plugin's page, there's a "manage plugin" section where you can add other WordPress.org users as co-authors or maintainers. They get access to update code, respond to support, and manage the plugin's metadata.