iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
To publish a WordPress plugin in the official directory, finish and test the complete plugin, choose a name whose slug you can keep permanently, prepare a valid readme.txt and plugin header, submit a complete ZIP from a WordPress.org account, pass manual review, then release the approved files through the assigned Subversion (SVN) repository. Approval is not instant: WordPress.org pages currently describe review estimates ranging from five business days to 14 business days, with complexity and correction rounds affecting the actual schedule.
What publishing on WordPress.org actually involves
The WordPress.org Plugin Directory is both a discovery channel and a hosting service. After approval, WordPress.org stores the released plugin in an SVN repository and delivers it to users through the directory and WordPress administration screens. It is not enough to create a listing that points to a download on your own server. The approved code and directory readme must be maintained in the repository WordPress.org provides.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The process has six practical stages:
- Complete the plugin and test it on more than one hosting setup.
- Check licensing, third-party terms, trademarks, privacy behavior and security.
- Select a distinctive display name and permanent slug.
- Write and validate the readme, and package a complete ZIP.
- Submit through a WordPress.org account and work through manual-review feedback.
- After approval, upload the plugin and readme to SVN and create a release tag.
Skipping any of these steps can delay approval or lead to removal after publication.
Finish a complete plugin before you submit
Define the first release
A reviewer must be able to install the ZIP and use the advertised functionality immediately. Do not submit a skeleton, a partially implemented feature, a demo that depends on an unavailable service, or a package that requires files you have not included. WordPress.org’s detailed guidelines state that a complete plugin must be available at submission.
#1 Best Overall
Decide what belongs in version 1.0 and remove unfinished controls from the interface. If a cloud service, API key, paid account or external application is required, explain that dependency clearly and provide the setup path in the documentation. A plugin may connect to an external service, but the user should know what leaves the site, why it leaves and how to configure or disable the connection.
Test behavior across environments
The Plugin Handbook recommends testing once and testing again because a plugin runs with different PHP versions, database configurations, themes, active plugins, permissions, caching layers and hosting controls. At minimum, exercise:
- A clean WordPress installation with the default theme.
- An installation with a widely used block or classic theme, depending on your integration.
- Activation, deactivation, upgrade and uninstall, including whether options and tables are intentionally retained or removed.
- Administrator and lower-privilege accounts, confirming that every capability check and nonce check works.
- Sites with a non-default language, timezone, permalink structure and administrator URL.
- Fresh installs and upgrades from the previous release, not only a brand-new copy.
- Common PHP and WordPress versions that your stated compatibility range supports.
- Failure paths: missing API credentials, timeouts, invalid input, unavailable files and denied permissions.
Test the ZIP you intend to submit rather than the working directory on your computer. A missing include file, build artifact or generated asset can make an otherwise healthy development copy unusable.
Choose the name and slug before submission
Why the first name matters
WordPress.org uses the submitted plugin name to determine the directory slug and URL. The handbook says the plugin URL cannot be changed after submission, although the display name can be changed later. Treat the first submission as a permanent naming decision.
Search the directory and the wider WordPress ecosystem for similar names before you package the ZIP. Avoid names that imply an official relationship with WordPress or another project, and avoid trademarks you do not own or have permission to use. A distinctive name also reduces confusion in support requests and makes it easier for users to find the correct update.
Check every place the name appears
- The main plugin-file header and the name shown in the Plugins screen.
- The directory slug that will become part of the permanent URL.
- The ZIP’s top-level folder, which should be consistent with the plugin identity.
- The readme title, screenshots, settings pages and documentation links.
- Text strings, namespaces and PHP function prefixes used to avoid collisions.
Make the final naming check before pressing Submit. A later change to the display name does not give you a new directory URL.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated 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 matchPrepare the required plugin files
Main plugin file and header
The main PHP file needs a compliant plugin header. The minimum required header field is the plugin name; the other fields make the directory listing and administration screen understandable. A simple header can look like this:
<?php
/**
* Plugin Name: Site Health Note
* Description: Adds a small site-health note to the dashboard.
* Version: 1.0.0
* Requires at least: 6.4
* Requires PHP: 8.0
* Author: Example Studio
* License: GPL-2.0-or-later
*/Use values that are true for the release you are submitting. Do not claim compatibility you have not tested. Keep executable code outside the header comment and load additional files using paths based on the plugin directory rather than assumptions about the current working directory.
The directory readme.txt
readme.txt is the directory’s standard reference point. Write it for someone deciding whether to install the plugin, then for someone who needs to configure and troubleshoot it. Include:
- A concise summary of the problem solved and the principal feature.
- Installation steps, including where to activate the plugin and where its settings live.
- Configuration instructions for required services, credentials, webhooks or API permissions.
- Usage examples and any limitations that could affect a production site.
- Support channels, what information a useful support request should contain, and boundaries such as third-party service support.
- Release information, version notes and any upgrade or migration action.
- Accurate metadata that matches the plugin header and the files in the ZIP.
Run the readme through the WordPress.org readme standard or validator before submission. Fix warnings that affect parsing, headings, metadata or rendering, and then inspect the rendered result yourself. A readme that promises a feature absent from the ZIP creates both a review problem and a support burden.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Package only what users need
Create a ZIP that can be uploaded from the WordPress Add Plugins screen without a build environment, private dependency or local configuration file. Include production PHP, JavaScript, CSS, images, translation files and required third-party libraries. Exclude passwords, API keys, development caches, test secrets and unrelated repository history. Confirm that the ZIP extracts to one plugin folder and that activation succeeds from the extracted contents.
Meet licensing, trademark, privacy and security rules
License the whole distributed work
The directory requires code, data, images and included third-party libraries to use the GNU General Public License (GPL) or a GPL-compatible license. You are responsible for checking every dependency, font, icon, bundled asset and generated file. A dependency’s license must permit the way you distribute and use it; recording a copyright notice in your repository does not replace that check.
Put the applicable license information in the plugin and readme, retain required attribution and provide notices required by bundled components. Also check the terms of every API or hosted service. A service may impose branding, data-use, redistribution or rate-limit conditions that affect whether your plugin can be offered in the directory.
Respect names and project identity
Do not use another company’s or project’s trademark in a way that suggests endorsement. The submitted name, slug, screenshots and settings-page wording should identify your plugin without impersonating an official extension. If a compatibility statement is necessary, describe it factually instead of presenting the plugin as an authorized product.
Secure the ordinary WordPress paths
Review every action, AJAX endpoint, REST route, form and settings change for capability checks, nonces, sanitization and output escaping. Do not trust values from users, cookies, HTTP headers, database rows or remote responses. Avoid logging credentials and personal data. Ensure remote requests use appropriate timeouts and fail safely when a service is unavailable.
Rank #4
Explain data collection in the readme and in the plugin’s settings or privacy tools when applicable. Tell administrators what data is sent off-site, the destination, the purpose and how to disable it. A plugin that is functional but unsafe or misleading can be rejected, closed or removed later.
Create your WordPress.org account and submit the ZIP
Use a monitored identity
Create or sign in to a WordPress.org account whose email you check regularly. For a company-owned plugin, use an official company address so review questions and repository notices do not depend on one employee’s personal inbox. Keep the account and release credentials protected with strong authentication and a documented hand-off plan.
Submit through Add Your Plugin
- Sign in to WordPress.org and open the Add Your Plugin submission page.
- Enter the final plugin name and the short overview requested by the form.
- Upload the complete ZIP that you tested from a clean installation.
- Confirm that the name, slug, licensing information and support details are accurate.
- Submit the package and save the confirmation message for your release records.
The ZIP is sent for manual review. It should stand on its own: reviewers should not need to obtain missing files, request private access or infer how an advertised feature works.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsUnderstand review timing and respond to feedback
WordPress.org publishes estimates rather than a guaranteed service-level deadline. The Plugin Handbook says queued submissions are reviewed within 14 business days. The current Add Your Plugin page says WordPress.org attempts review within five business days and notes that timing depends on complexity. Treat both as planning estimates: a simple plugin may move faster, while a complex integration or a correction round may take longer.
Keep the submission email available during the queue. If reviewers identify a licensing, security, documentation, naming or functionality issue:
- Read the complete message and reproduce the reported behavior.
- Fix the root cause, not only the line or screen mentioned in the example.
- Rebuild and retest the complete ZIP, including upgrade and uninstall behavior.
- Update the readme and license notices so they describe the corrected release.
- Reply in the review thread with a concise change summary and any required evidence.
Do not submit a plugin that is intentionally incomplete while waiting for review. The directory’s detailed guidelines require a complete plugin at the time of submission.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Release the approved plugin through SVN
What approval gives you
After approval, WordPress.org provides access to an SVN repository for the plugin. The directory displays the project after you place the plugin files and readme.txt in that repository according to its release structure. Approval alone does not publish the files you uploaded for review.
Free tools Windows power users keep installed
One-click scans. No signup required.
A safe first release sequence
- Accept the repository access notice and authenticate with the WordPress.org account that received it.
- Check out the empty or initial repository with an SVN client.
- Place the tested plugin folder in the repository’s trunk area and place the matching
readme.txtwhere the directory expects it. - Review the SVN status and inspect the file list for secrets, development files and missing production assets.
- Add the files, commit them with a clear release message and wait for the commit to complete.
- Create a version tag that matches the plugin version, then verify the directory page and an installation from WordPress administration.
Use the repository as the source for public releases. Keep local build instructions and private test material outside the committed plugin unless users genuinely need them at runtime. For later versions, update the trunk, commit the release, create the corresponding tag and ensure the readme’s stable version and changelog agree with the code.
Why repository discipline matters
WordPress.org describes the directory as a hosting site, not merely a listing site. The code users download must therefore be present in the supplied SVN repository. A page that advertises a plugin while the repository contains no usable release, a broken package or an unrelated project can be closed or removed.
Maintain the plugin after it appears in the directory
- Monitor support requests, review notices and security reports at the addresses documented in the readme.
- Test updates from the currently published version, not only clean installations.
- Keep the stable tag, plugin header, readme metadata and changelog synchronized.
- Review new dependencies and service terms before adding them to a release.
- Remove or repair broken functionality instead of leaving artificial restrictions that prevent users from accessing built-in features.
- Document migrations, changed permissions, removed settings and data-retention behavior.
- Publish security fixes promptly and explain the affected versions without exposing exploit details that would endanger unpatched sites.
Directory guidelines can be enforced after publication. A plugin that later violates licensing, trademark, security, privacy or functionality requirements can be closed or removed, so approval is the beginning of maintenance rather than the end of compliance work.
WordPress.org directory or private distribution?
The directory is not the only way to deliver a plugin. A private ZIP, a customer portal or an organization’s internal update system can be appropriate when you need tighter control over access or monetization. The trade-offs are different:
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 →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →| Decision factor | WordPress.org directory | Private distribution |
|---|---|---|
| Review and compliance | Manual review and continuing compliance with directory guidelines. | You control review, but you still remain responsible for legal, security and privacy obligations. |
| Discovery and updates | Directory search, WordPress administration installation and the directory update path. | You must provide discovery, downloads and an update mechanism yourself. |
| Release workflow | Approved SVN repository, committed files and release tags. | Your own repository, storage and deployment process. |
| Community features | Directory support channels, reviews and usage statistics. | Support, telemetry and customer records are your responsibility. |
| Licensing and naming | GPL or GPL-compatible licensing for distributed components and trademark-respect requirements. | Private delivery does not remove copyright, license or trademark duties. |
| Commercial control | More visibility, with directory rules limiting some practices and requiring a usable hosted plugin. | More control over access, pricing and service terms, with more infrastructure to operate. |
If your audience benefits from one-click discovery and automatic update delivery, the directory’s compliance burden is usually worthwhile. If the plugin is an internal tool or must remain access-controlled, private distribution may fit better.
Pre-submission checklist
- The plugin performs every advertised function in a clean WordPress installation.
- The submitted name is distinctive, trademark-safe and acceptable as a permanent slug.
- The tested ZIP contains all runtime code and no secrets or development-only files.
- The main file has a valid plugin header, including an accurate plugin name.
readme.txtexplains installation, configuration, services, support, limitations and releases.- The readme passes the available WordPress.org validator and renders as intended.
- Code, images, data and third-party libraries have GPL or GPL-compatible licensing.
- Remote services, privacy behavior, permissions, nonces, validation and escaping have been reviewed.
- An official, monitored WordPress.org account is ready for review correspondence.
- You have a plan to test upgrades and maintain the SVN repository after approval.
What success looks like
A successful first publication is not simply an approved ZIP. It is a repeatable release that a stranger can discover, install, configure, update and get help with, while the code remains legal, secure and complete. Make the permanent naming decision early, test the exact package you submit, treat review estimates as variable, and use the assigned SVN repository as the authoritative home for every public release.
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.
