WordPress Plugin Submission Requirements

CodingRepo reviews WordPress plugins as source-code products. These requirements are designed to help authors find and fix problems locally before any software is uploaded. They are informed by established marketplace and WordPress practices, but they are CodingRepo’s own submission rules and review workflow.

CodingRepo does not accept compiled code in WordPress plugins. Every executable behavior must be available as readable, maintainable source. Do not submit native binaries, bytecode, encoded or encrypted PHP, obfuscated logic, opaque generated bundles, or any other code our reviewers cannot inspect directly.

Run the local agent preflight first

Download the CodingRepo WordPress Plugin Preflight Skill, add the skill folder to your coding agent, and ask it to scan the plugin’s source repository and intended release package. The skill produces an evidence-based report with file paths, severity, why each issue matters, a local remediation, and a way to verify the fix.

1. Run the skill against the complete source repository.
2. Make sure the agent also inspects the exact ZIP you plan to submit.
3. Address every blocker and re-run the scan.
4. Keep the final report for your records and upload only after the package is ready.

The preflight report is guidance, not marketplace approval. CodingRepo examines every uploaded product with multiple independent agents. Those agents may focus separately on security, WordPress behavior, packaging and provenance, privacy, maintainability, and buyer readiness. Human review or additional specialist review may also be used. We may request changes or decline a product even when a local scan found no blockers.

Submit readable source only

• Include one clearly identified plugin with a valid plugin header and consistent version information.
• Include readable source for PHP, JavaScript, CSS, templates, configuration, migrations, installer behavior, and every feature described in the listing.
• Do not include compiled, encoded, encrypted, obfuscated, or otherwise non-reviewable code.
• Do not include passwords, API keys, tokens, customer data, environment files, logs, caches, backups, unrelated archives, or development-machine artifacts.
• Identify third-party libraries and include compatible license notices.
• Make the submitted package match the product version, screenshots, documentation, and listing claims.

Follow WordPress APIs and conventions

Use public WordPress APIs and documented hooks. Do not modify WordPress core, take over unrelated administration screens, or replace bundled libraries with conflicting copies. Prefix or namespace code and stored data so the plugin does not collide with other products.

Declare realistic minimum WordPress and PHP versions. Check requirements safely, fail with a useful message, and avoid partially activating a plugin that cannot run in the current environment.

Secure every request and output

• Check the correct capability for every privileged action. A nonce verifies intent; it does not grant permission.
• Sanitize and validate input, escape output for its final HTML, attribute, URL, JavaScript, or SQL context, and prepare all dynamic database queries.
• Protect REST routes, AJAX actions, forms, webhooks, scheduled jobs, uploads, archives, downloads, redirects, filesystem paths, and remote requests.
• Prevent unauthorized access, injection, path traversal, cross-site request forgery, server-side request forgery, and unsafe file execution.
• Do not load executable code from a remote service or conceal telemetry, licensing callbacks, or external dependencies.

Keep data and lifecycle behavior predictable

Use WordPress data APIs where practical. Custom tables must have a justified purpose, consistent prefixes, safe migrations, and explicit upgrade handling. Activation and upgrades must be repeatable. Deactivation must not delete user data. If permanent deletion is offered, make it an explicit uninstall or administrator-controlled choice and document exactly what is removed.

Collect and retain only data needed for the stated feature. Disclose external services, personal-data transfers, telemetry, and retention behavior. Support appropriate export and deletion workflows when the plugin stores personal data.

Ship buyer-ready documentation

• Explain installation, configuration, permissions, dependencies, supported versions, external accounts, and known limitations.
• Document support, updates, licensing, uninstall behavior, and any paid service required for a listed feature.
• Provide reproducible tests or verification steps for critical workflows.
• Resolve plugin-generated PHP warnings, notices, JavaScript errors, failed requests, and broken responsive or accessible interactions.
• Keep user-facing strings translatable and escape translated output correctly.

Pre-upload checklist

• The local skill report has no unresolved blockers.
• The exact submission ZIP was inspected, not only the development checkout.
• No compiled code or other non-reviewable executable artifact is present.
• No secrets, personal data, logs, caches, backups, or unrelated files are present.
• Version numbers, requirements, documentation, listing copy, and package contents agree.
• Installation, activation, core workflows, deactivation, upgrade, and uninstall were tested on supported versions.

Reference material

Authors may also consult the WordPress Detailed Plugin Guidelines, the WordPress Plugin Security Handbook, the WordPress PHP Coding Standards, and the Envato WordPress Plugin Requirements. Those documents are useful references, but CodingRepo applies the requirements and review process stated on this page.