How to Submit a Plugin to WordPress.org: Practical Tips to Avoid Rejection

1. Ensure your readme.txt is properly formatted

The readme.txt file provides content that appears on your plugin’s WordPress.org page. It must follow the official structure with required fields such as:

• Plugin Name
• Contributors (must be WordPress.org usernames, not real names or company names)
• Tags, Requires at least, Tested up to, Stable tag, License
• Short Description and full description under == Description ==

Omitting these or using the wrong format can get your plugin rejected. Additionally, if you submit the plugin using a different WordPress.org account than what’s listed in Contributors, it will be flagged as a mismatch and possibly denied.

2. Make sure your account and email match your plugin’s identity

If your plugin represents a company or brand (e.g. Init HTML), the WordPress.org account used to submit it should have an email address under that domain, such as [email protected]. Submissions using Gmail, Hotmail, or other free services will likely be rejected unless ownership is clearly verified.

To resolve this easily, you can use Cloudflare Email Routing to create a domain-based email address and forward it to your Gmail inbox.

3. Use unique plugin names and function prefixes to show clear ownership

WordPress.org does not allow plugins that misuse third-party brand names. You can’t name your plugin “Facebook Auto Post” or use prefixes like meta_, google_, or wc_ unless you officially represent those companies.

For all functions and classes, use a custom and unique prefix related to your brand or plugin. For example:

function init_plugin_suite_live_search_render_results() {}

Avoid generic names like render(), get_data(), or output() to prevent conflicts with other plugins.

4. Run Plugin Check to validate WPCS compliance

Plugin Check is an official plugin that helps verify your code follows WordPress Coding Standards (WPCS). It alerts you to issues such as:

• Unescaped output (missing esc_html(), esc_attr(), etc.)
• Forms lacking wp_nonce_* security functions
• Incorrect hook usage or deprecated functions
• Code formatting errors (spacing, braces, alignment)

However, Plugin Check does not check plugin logic or legal compliance. It won’t detect missing register_uninstall_hook(), lack of a license.txt, or duplicate function names. You’ll need to audit those manually.

5. Avoid suspicious or policy-violating code

Plugins will be rejected if they contain potentially harmful or misleading code, including:

• Functions like eval(), exec(), base64_decode()
• Remote API calls to unknown domains or tracking scripts
• Obfuscated JavaScript/CSS or heavily minified code that hides intent

Keep your code clean, readable, and transparent in the spirit of open source.

6. Package your plugin in the correct .zip structure

When submitting, your zip file should contain a folder named exactly after your plugin slug, like this:

init-live-search/
├── init-live-search.php
├── readme.txt
├── assets/
├── includes/
└── ...

Do not zip your entire development environment or include unnecessary external libraries. The main plugin file should reside directly inside the named folder.

7. Final checklist before submission

• readme.txt formatted properly
• Your account is listed under Contributors
• Email address matches your plugin’s brand or domain
• All functions and classes have unique, branded prefixes
• No use of third-party brand names without authorization
• Passed Plugin Check with no critical issues
• No eval(), obfuscation, or questionable code practices

Conclusion

Submitting a plugin to WordPress.org is not overly difficult, but it requires careful attention to both technical and legal details. If everything is properly prepared from the start, your plugin will be approved quickly and stand on a solid foundation for long-term growth. Neglecting these aspects can lead to delays, rejections, or worse—compliance issues down the road. Standardize your submission process early and you’ll save yourself plenty of time and headaches.