There's no official average, as no two plugins are the same. If your plugin is small and all the code is correct, it shoud be approved within seven days. If your plugin has any code issues, it will take as long as it takes for you to correct the issues. Either way, you will get an email from firstname.lastname@example.org with the status, so please add that to your email whitelist.
We allow for seven days from the time we contact you regarding the issue to when we expect you to be finished with corrections. It's one of the only ways we have to keep the queue small. If you need to take more than seven days, we'll reject your request and you can resubmit after you're done.
We look for some pretty obvious things, all of which are listed in our guidelines, and most can be summed up as 'Don't be a spammer,' but to touch on the ones people do the most:
Yes and no. You can change the display name, but the 'slug' - that part of the plugin URL that is yours - cannot be changed. So if you submit "My cool tool" as the name, your URL will be
http://wordpress.org/plugins/my-cool-tool/ and that will also be the folder name on everyone's site.
We don't allow 'WordPress' in plugin names as it's redundant and somewhat obvious that you're a WordPress plugin. We also generally disallow using 'plugin' for the same reasons. Only English letters and Arabic numbers are permitted in the slug, so you cannot have, for example, Chinese or Arabic letters in the URL, for compatibility issues. We don't permit version numbers in plugins either.
We'd rather you actually just re-write the existing plugin. Make it a major version. We can't rename plugins, so your new one won't get any of the old users.
Put your files directly in the
trunk/ directory of your repository. Whenever you release a new version, tag that release by copying the current trunk revision to a new subdirectory of the
Make sure you update
trunk/readme.txt to reflect the new stable tag.
Screenshot image files should ideally be put in the
assets/ directory (which you'll likely need to create) in the root of your SVN checkout. This will be on the same level as
trunk/, for example. Alternatively, screenshots can be put in the directory of the tagged stable release (
trunk/ or the stable tag directory) (the old way). The
assets/ directory is preferred since the screenshots won't be packaged in the plugin's release zip files, saving unnecessary bloat for each download. Learn more from the feature's announcement post.
You can, but it’s silly. The
.zip file the WordPress.org Plugin Directory creates will automatically wrap all your files inside a directory, so there is no need to put your files into a subdirectory.
If you have complicated plugin with lots of files, you can of course organize them into subdirectories, but the readme file and the root plugin file should go straight into
Your subversion tags should look like version numbers. Specifically, they should only contain numbers and periods.
2.8.4 is a good lookin’ tag,
my neato releaso is a bad lookin’ tag. Inflexible? Yup. Easy to handle and sanitize? You bet!
Note that we’re talking about subversion tags here, not readme.txt tags. Those can obviously be any words you like.
Yes, by specifying the
Stable Tag field in your trunk directory’s readme file.
From the information you specify in the plugin file and in the readme file, and from the subversion repository itself.
Authorfield from the plugin header and
Contributorsfield from the readme file.
Versionfield from the plugin header.
Tagsfield from the readme file.
Plugin Namefrom the readme file falling back on the
Plugin Namespecified in the plugin header.
Plugin URIfields of the plugin header.
trunk/or the stable tag directory) after a version number change.
The WordPress.org Plugin Directory updates every few minutes, however it may take longer for your changes to appear, depending on how deep the queue is.
Nope, sorry. You can add svn externals to your repository, but they won’t get added to the downloadable zip file.
Start by creating an
assets/ directory in the root of your SVN checkout. This will be on the same level as
trunk/, for example.
assets/ directory, you can make a file named "banner-772x250.png" or "banner-772x250.jpg". The image must be exactly 772 pixels wide and 250 pixels tall. No GIFs.
To support high-DPI (aka "retina") displays, you can additionally make a file named "banner-1544x500.png" or "banner-1544x500.jpg". The image must be exactly 1544 pixels wide and 500 pixels tall. No GIFs. This image, if present, will only be served when the website detects that the viewing browser is on a high-DPI display. Read this feature's announcement post for more details and special notes about creating this image.
After you check in your new banner(s), it will appear the next time the plugin refreshes itself in the directory. This may take a few minutes.
For development and testing, you can add a URL parameter to your plugin's URL of "?banner_url=A_LINK_TO_YOUR_IMAGE" to preview what the page will look like with your own image. This will only work with your own plugins, you can not use this parameter on anybody else's plugins.