To publish a WordPress plugin in the official directory, finish and test a complete plugin, choose a permanent name and slug, prepare a valid readme.txt and plugin header, submit a ZIP for manual review, answer any reviewer questions, and—after approval—place the release in the Subversion repository WordPress.org provides. Approval is not automatic, and directory publication carries licensing, trademark, security, privacy, and support obligations.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What publication on WordPress.org actually involves
The WordPress.org Plugins Directory is both a discovery channel and a hosting service. Users can find a listing, install the plugin from the WordPress dashboard, receive directory-driven updates, read reviews, and use the support area. In return, your code must comply with the directory guidelines and be stored in the repository assigned to you after approval.
As an Amazon Associate I earn from qualifying purchases.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchThe process has four distinct phases:
- Complete, test, document, and legally clear the plugin.
- Submit an account-backed application with a ZIP that could be uploaded manually.
- Work through the manual review and correct anything the reviewers identify.
- Publish approved files through the assigned Subversion repository and maintain later releases there.
Do not treat submission as a way to reserve an idea or unfinished code. The detailed guidelines state that a complete plugin must be available when you submit it.
Finish the plugin before opening a submission
Define a complete first release
A reviewer should be able to install the ZIP on a clean WordPress site and use the advertised feature without private files, missing build artifacts, or an account that you have not documented. Finish the normal user journey, settings screens, activation behavior, uninstall behavior, error handling, and any required external connection before submitting.
#1 Best Overall
- Include every PHP, JavaScript, CSS, image, translation, and build file required at runtime.
- Remove development-only credentials, test data, local paths, and debugging output.
- Make the feature usable without artificial restrictions on functionality that WordPress itself provides.
- Document any required service, API key, account, quota, or remote dependency before a user installs the plugin.
Test across realistic hosting conditions
The Plugin Handbook recommends testing once and testing again because plugins run with different themes, PHP versions, caching layers, security settings, database configurations, and hosting environments. At minimum, test activation, upgrade, deactivation, and uninstall on a fresh site and on a site that already contains representative content.
- Check the administrator screens at the roles your plugin supports; verify that unauthorized users cannot reach privileged actions.
- Exercise empty states, malformed input, failed network calls, expired credentials, and unavailable APIs.
- Test with a standard theme and with a second theme that changes markup or script loading.
- Confirm that enabling and disabling the plugin does not leave fatal errors, broken scheduled tasks, or orphaned database data.
- Run the production build, install the resulting ZIP, and test that exact ZIP rather than only a development checkout.
Choose the name and slug before you submit
The submitted name creates a permanent URL decision
The name entered on the Add Your Plugin form determines the directory slug and URL. The plugin URL cannot be changed after submission, even though the display name can later be edited. Decide on spelling, punctuation, and the short slug before sending the application.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Search the directory, the wider WordPress ecosystem, and relevant trademark records for confusingly similar names. A distinctive name reduces the chance of a naming dispute and makes the listing easier to identify. Do not imply an official relationship with WordPress, another project, or a company unless you have the right to do so.
Keep the public name consistent
Use the same product identity in the main plugin header, readme.txt, settings screens, documentation, and ZIP folder. A mismatch makes review and support harder and can create an unintended slug. If you later rebrand, remember that changing the display name does not change the original directory URL.
Prepare the files WordPress.org expects
Main plugin file and header
Your entry-point PHP file needs a valid WordPress plugin header. The minimum required field is the plugin name; adding complete metadata makes the listing and administration screen clearer.
<?php
/**
* Plugin Name: Example Content Tools
* Description: Adds a documented content utility to WordPress.
* Version: 1.0.0
* Requires at least: 6.0
* Requires PHP: 7.4
* Author: Example Studio
* License: GPL-2.0-or-later
* License URI: https://www.gnu.org/licenses/gpl-2.0.html
*/
The values in this example are a format demonstration, not requirements for a particular version. Use versions and compatibility claims that you actually test. Keep executable code outside the header comment and make the file load safely when WordPress includes it.
Write a useful readme.txt
The directory uses readme.txt as its standard reference point. Write for someone deciding whether to install the plugin and for someone who needs to recover from a configuration problem. Validate the finished file before submission.
=== Example Content Tools ===
Contributors: your-directory-id
Tags: content, editor, workflow
Requires at least: 6.0
Tested up to: 6.x
Requires PHP: 7.4
Stable tag: 1.0.0
License: GPL-2.0-or-later
License URI: https://www.gnu.org/licenses/gpl-2.0.html
== Description ==
Explain the problem solved, the main features, and important limitations.
== Installation ==
1. Install and activate the plugin.
2. Open the documented settings screen.
3. Configure the required options.
== Frequently Asked Questions ==
Answer setup, compatibility, data, and account questions.
== Screenshots ==
Describe each screenshot if you include any.
== Changelog ==
= 1.0.0 =
* Initial release.
Include a concise description, installation and configuration instructions, links or instructions for required services, support channels and boundaries, and release information. State what the plugin does not do when that prevents a predictable misunderstanding. Keep the stable tag and changelog synchronized with the release you submit.
Explain support and external services
Tell users where support is provided, what information they should include in a report, and which issues are outside your support scope. If the plugin contacts an external service, identify that service, explain setup and failure behavior, and document terms that affect use. A user should not discover a required account or remote dependency only after activation.
Clear licensing, trademarks, privacy, and security
Use a GPL-compatible license throughout
Directory rules apply to more than your PHP files. Code, data, images, fonts, bundled libraries, and other included components must use the GNU General Public License or a license compatible with it. You are responsible for checking every third-party component and preserving required notices.
- Record the license and version for bundled libraries and assets.
- Remove a dependency if its terms are incompatible with directory distribution.
- Include attribution and license text where the component requires it.
- Confirm that your service or API terms permit the way your plugin connects, stores, and displays data.
Protect users and their data
Sanitize and validate input, escape output for its context, protect state-changing requests with capability checks and nonces, and avoid exposing secrets in logs or JavaScript. Explain what data leaves the site, why it is sent, how long it is retained, and how a site owner can disconnect the service. Test failed authentication and revoked credentials as carefully as successful requests.
Respect names and public-site behavior
Trademark conflicts, misleading project names, unauthorized public-site links, and artificial limits on built-in functionality can block approval or lead to removal later. The directory is not a place to force unrelated promotional links into a site’s public output. Make every front-end link necessary, disclosed, and authorized.
Create the submission package
Use a monitored WordPress.org account
Register or sign in with an email address you monitor. A company should use an official company address so review questions and repository notices remain accessible if a team member changes roles. Keep the account details current; losing access can make maintenance of an approved plugin difficult.
Build a clean ZIP
Submit a complete ZIP that a reviewer could manually upload to WordPress. Install that archive on a clean test site before sending it. The archive should contain the plugin’s production files, not an outer folder full of source-control metadata, local configuration, node modules, test fixtures, or secrets.
Recommended Free Tools
- Confirm the main plugin file is discoverable in the installed plugin directory.
- Confirm
readme.txtis present and the validator accepts its format. - Check that images, translations, compiled assets, and required libraries are included.
- Open the ZIP as a different person would and verify that no private keys or customer data are present.
Submit the overview and ZIP
On the Add Your Plugin page, provide the requested short overview and upload the archive. Describe the actual feature set and important dependencies plainly. Do not submit a placeholder, a framework skeleton, or a plugin whose advertised functionality is still planned.
Understand manual review and timing
Plan for a queue, not a guaranteed date
WordPress.org publishes two different estimates. The Plugin Handbook says queued submissions are reviewed within 14 business days, while the current Add Your Plugin page says WordPress.org attempts review within five business days and notes that complexity affects timing. Treat both as estimates rather than a promise. A complicated integration, licensing question, or correction round can extend the calendar.
Respond to review feedback precisely
Keep the submission email available and answer the reviewer in the same thread. When a reviewer identifies a problem, reproduce it, make the smallest complete fix, retest the affected path, and explain exactly what changed. If the issue concerns a dependency, trademark, privacy disclosure, or service term, provide the relevant permission or revise the implementation instead of arguing from intent.
Do not send a new, unrelated plugin while an existing review is unresolved. Keep a changelog of requested changes so the ZIP, readme, and source tree remain synchronized when you resubmit.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteRank #4
Publish the approved plugin through Subversion
Wait for the repository assignment
After approval, WordPress.org provides access to a Subversion repository. The repository is where the directory hosts the approved code; approval alone does not mean your files are publicly available. Follow the repository instructions delivered with your approval notice.
Upload the release and readme
Use a Subversion client to place the plugin files and readme.txt in the structure specified by the repository instructions, then commit the changes. Keep the release that users install identical to the tested ZIP. Tag a version when the repository workflow calls for it, and reserve the asset area for directory screenshots or other permitted listing assets.
- Copy only production files into the release directory.
- Check that the stable tag in
readme.txtpoints to the version you intend users to receive. - Verify that the committed readme, plugin header, and changelog describe the same release.
- After the directory processes the commit, install the listing from a separate site and test the update path.
Maintain releases as a repository product
Future updates use the same repository and compliance obligations. Review dependency licenses again, test upgrades from the previous public version, update compatibility metadata, and document any data migration. Removing a vulnerable component quickly is part of publishing, not an optional postscript.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Directory publication versus private distribution
A ZIP sold or shared from your own site gives you more control over packaging and monetization, while directory publication exchanges some of that control for discovery and WordPress-integrated delivery.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
| Decision area | WordPress.org directory | Private distribution |
|---|---|---|
| Review and compliance | Manual review and continuing directory rules, including GPL compatibility, trademarks, security, privacy, and service terms. | You control acceptance, but you still remain responsible for legal, security, privacy, and license compliance. |
| Discovery and updates | Directory search, dashboard installation, reviews, statistics, support tools, and the standard update path. | You must provide discovery, download delivery, update checks, and support infrastructure. |
| Release workflow | Approved code and readme are published through the assigned Subversion repository. | You choose storage, versioning, and deployment tools. |
| Brand and URL control | The submitted name fixes the directory slug and URL; the display name can change later. | You choose the URL and can generally change it, subject to your own migration work. |
| Monetization control | Must follow directory rules and cannot impose artificial restrictions on built-in functionality or add unauthorized public-site links. | You set pricing, licensing presentation, and delivery terms within applicable law and third-party licenses. |
Choose the directory when broad WordPress discovery, dashboard installation, and standardized support matter more than complete control over delivery. Choose private distribution when a closed product, custom entitlement system, or non-directory workflow is essential; do not assume private distribution removes the need to secure code or honor third-party licenses.
Common approval blockers and their fixes
Incomplete functionality
Symptom: the listing promises features that are absent, disabled, or dependent on an undocumented private service. Fix: finish the advertised path, include required files, explain dependencies, and submit only after the clean-site test succeeds.
Unclear or conflicting metadata
Symptom: the header, readme, ZIP folder, and stable tag use different names or versions. Fix: choose one identity and version, regenerate the production archive, validate the readme, and reinstall that exact archive.
License or trademark uncertainty
Symptom: a bundled image, library, API, or product name has terms you cannot prove are compatible. Fix: obtain documented permission, replace the component or name, and retain the license record with the project.
Security and privacy gaps
Symptom: privileged actions lack capability checks, remote data handling is unexplained, or secrets appear in logs or source. Fix: secure the request and storage paths, disclose data flows and retention, remove secrets, and test both success and failure cases.
Repository misunderstanding
Symptom: the plugin was approved but never appears, or an update does not contain the files you tested. Fix: complete the assigned Subversion upload and commit, verify the stable tag and readme, then install from the public listing to confirm the delivered build.
A practical release checklist
- Distinctive name checked for trademark and project-name conflicts.
- Permanent slug and URL reviewed before submission.
- Complete production plugin tested on clean and existing sites.
- Activation, upgrade, deactivation, uninstall, permissions, and error paths tested.
- Main plugin file contains a valid header with at least the plugin name.
readme.txtincludes description, installation/configuration, support, service instructions, metadata, and release information.- Readme validated; header, stable tag, changelog, and ZIP version agree.
- Code, data, images, and third-party libraries have GPL-compatible licensing.
- Security, privacy, API terms, and required disclosures are documented.
- Submission account uses a monitored email address.
- ZIP contains everything needed for manual upload and nothing private.
- Review estimates are treated as variable, with time reserved for corrections.
- After approval, the tested release and readme are committed to the assigned Subversion repository.
Following this sequence turns publication into a repeatable release process: make the plugin complete, make its identity permanent and unambiguous, document what users need, satisfy the directory’s legal and technical rules, and keep the repository release synchronized with every update.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →
