Launch a WordPress Plugin for Free: Write for the Plugin Review Team
Launch a WordPress plugin by submitting it to the WordPress.org plugin directory, where a person reviews it by hand, usually within 1 to 10 days. The most common reasons for rejection are unescaped output, unsanitized input and form handling without a nonce, so fix those before you submit. Choose the plugin name carefully, since the slug cannot change after approval, and keep the code GPL-compatible. Announce once the directory page is live.
Why is the review the whole launch?
The directory’s submission page says each plugin is manually reviewed for common errors and for compliance with the guidelines. It says the review takes anywhere between 1 and 10 days, that the team tries to review everything within 5 business days, and that a review cannot be prioritised over others. Read that last part twice: no one can pay or ask their way to the front, so the only lever you control is the quality of the code you submit.
The page lists the usual reasons a plugin is not approved. The code outputs data without escaping it, it accepts data without sanitizing it, it processes form data without a nonce, or it breaks a guideline. Each of these sends you back to the Plugin Handbook’s security chapter and adds delay. A solo developer’s best launch preparation is a security pass, not a landing page.
- Escape on output, every time a value from a database, option or request reaches the page.
- Sanitize on input, before saving or using anything a user or request supplied.
- Check a nonce and a capability on every action that changes data.
What do the guidelines rule out for a business model?
The detailed guidelines are short headings, and several shape what you can sell. Code must be compatible with the GNU General Public License, so a plugin you hoped to keep closed does not belong in this directory. Trialware is not permitted, while software as a service is. Plugins may not track users without their consent, may not send executable code through third-party systems, and may not embed external links or credits on the public site without explicitly asking the user.
Put together, a few plans work and a few do not. A free plugin that connects to your paid hosted service is the usual shape that the guidelines allow. A plugin that switches features off when a trial period ends is the shape they rule out. If your idea is a service with a plugin as its connector, read the full guideline text on software as a service before you design the settings page, and decide before you write code.
How do the name and the web address get decided?
Your plugin’s address on WordPress.org is built from the Plugin Name in the main file’s headers. “Boaty McBoatface” becomes the slug boaty-mcboatface, and a taken slug gets a number at the end. The page says that after approval the plugin cannot be renamed. Before review begins you can change the slug once from the submission page, and if it is already in review you reply to the review email instead.
That makes the name the one decision you cannot undo cheaply. Pick one a site owner would search for, avoid generic words you will share with fifty others, and skip a name that ends in a number. Say what it does in the short description and let the name be recognisable.
What goes in the repository and on the listing?
Approved plugins live in a Subversion repository, which the developer handbook describes as a version control system similar to Git. Your released files, the readme and the listing images all sit in that repository, so learn the three folders it creates, trunk, tags and branches, before the first release rather than during it.
| File | Size | Note |
|---|---|---|
| banner-772x250 | 772 by 250 pixels, jpg or png | The normal banner at the top of the plugin page |
| banner-1544x500 | 1544 by 500 pixels | The high-DPI version of the same banner |
| icon-256x256 | 256 by 256 pixels | A square icon; the handbook says sizes should match their names |
The handbook also says not to rename these sizes or try to be clever with new ones. The readme file is the long description that people read, so write it for a site owner deciding in thirty seconds, with a short list of what the plugin does and what it needs.
What does a three-week plan look like?
- Days 1 to 7: build the core job. Escape, sanitize and nonce as you write each handler, not afterwards.
- Days 8 to 10: read the guidelines once against your own plugin, line by line, and remove anything that needs trialware or tracking behaviour.
- Day 11: submit, with the final name. Keep the review email open.
- Days 12 to 21: while it is reviewed, test on a fresh site with a default theme, write the readme, draw the banner and icon, and line up three site owners who will try the real release.
- Day of approval: release the first version and announce. Reply to support threads in the directory the same day.
How do site owners find a plugin?
Most look for a task, not a plugin, so the directory search is where installs begin. Put the task words in the short description and the readme’s first lines. Away from the directory, explain the problem where site owners and freelancers already talk about it, and show the plugin working on a real page. A before-and-after screenshot of a site beats a feature list.
A free public page for the product helps too. When you launch your plugin on this board it is public after you click a single emailed link, with a followed link back to your directory page. The ideas board shows what other builders are asking site owners to solve, and the places that suit WordPress plugins point to communities with their own rules. If the plugin is the front end of a service, the micro SaaS playbook covers the selling side, and getting first users for free covers the first twenty installs.
Frequently asked questions
How long does WordPress plugin review take?
The submission page says it takes anywhere between 1 and 10 days, with an aim of 5 business days, and that reviews cannot be prioritised over others. Complex plugins take longer. The best way to avoid delay is to follow the security chapter of the Plugin Handbook before submitting.
Why do WordPress plugins get rejected?
The most common reasons listed on the submission page are unescaped output, unsanitized input, form processing without a nonce, and breaking the guidelines. Fixing those before submission avoids being sent back to the handbook, which adds delay to the review.
Can I sell a premium WordPress plugin in the directory?
The guidelines say trialware is not permitted and that software as a service is permitted, and the code must be GPL-compatible. That rules out locking features behind a trial period, but a plugin that connects to a paid service is the allowed shape. Read the guidelines before you design pricing.
Can I rename a plugin after approval?
No. The submission page says that once a plugin is approved it cannot be renamed. You can change the slug once before review starts, and before approval by contacting the review team, so settle the name before you submit.
Written by Post your build ideas with AI assistance and edited for this site. Where a page names another product, the facts came from that product’s own pages on the date shown above; terms change, so check them before you rely on them. About the publisher.