WordPress.org

Ready to get started?Download WordPress

Plugin Directory

Developer FAQ

Questions about Submissions and Approval

How long does it take to get a plugin approved?

There's no official average, as no two plugins are the same. If your plugin is small and all the code is correct, it should 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 plugins AT wordpress.org with the status, so please add that to your email whitelist and patiently wait for our response.

If my plugin has a problem, how long do I have to fix it?

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.

Are there specific things you're looking for that I should avoid?

We look for some pretty obvious things, all of which are listed in our guidelines. Most can be summed up as "Don't be a spammer," but to touch on the ones people do the most:

  • Not including a readme.txt file
    A readme.txt file is the primary source for the information displayed for the plugin in the Plugins Directory. It should be present and should explain how to use the plugin and what plugin does, even if you think it's obvious.
  • Not testing the plugin with WP_DEBUG on
    We test your plugin with WP_DEBUG on. You should, too, before you submit. If the plugin doesn't work, we push back.
  • Including custom versions of packaged JavaScript libraries
    WordPress comes with a great number of default scripts (including jQuery) which we ask you not include in your plugin. Use ours.
  • Calling external files
    All plugins should be as self-contained as possible. Obviously, if your plugin relies on a service on your own servers (like Twitter), then calling JS remotely is fine. However, if you're attempting to offload images and JS to a CDN without providing a service, we do not permit this.
  • "Powered By" links
    All links on the forward facing aspect of a website must be "Opt In." This means your plugin may not default to link back to your site, or any other, on the part of the website that visitors see.
  • Phoning home
    This is bigger than just not tracking users, but also not including files that send any data back to your servers (like iframes) unless that is a requirement for how your plugin works. Even then, we may ask about it.

Can I change my plugin's name?

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 https://wordpress.org/plugins/my-cool-tool/ and that will also be the folder name on everyone's site.

Are there names you don't permit?

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 plugin names either.

We also discourage naming a plugin fully after a web service, tool, or library unless it's submitted by someone officially representing said web service, tool, or library. Especially if the plugin relates to that very thing. Be creative and come up with your own unique name!

I already have a plugin, but I want to redo it! I just submit again, right?

We'd rather you actually just rewrite the existing plugin. Make it a major version release. We can't rename plugins, so a new one wouldn't carry over any existing users, reviews, support topics, ratings, downloads, favorites, etc.

Questions About The Repository

In what directory should I put my files?

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 tags/ directory.

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 may need to create) in the root of your SVN checkout. This will be on the same level as tags/ and 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.

Can’t I put my files in a subdirectory of trunk/?

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.txt file and the root plugin file should go straight into trunk/.

How should I name my tags (a.k.a. releases)?

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.

Can I specify what version of my plugin the WordPress.org Plugin Directory should use?

Yes, by specifying the Stable Tag field in your trunk directory’s readme.txt file.

Where does the WordPress.org Plugin Directory get its data?

From the information you specify in the plugin file and in the readme.txt file, and from the Subversion repository itself.

Authors
Author field from the plugin header and Contributors field from the readme file.
Version
Version field from the plugin header.
Tags (as in categories)
Tags field from the readme file.
Plugin Name
The Plugin Name from the readme file falling back on the Plugin Name specified in the plugin header.
Author and Plugin Homepages
The Author URI and Plugin URI fields of the plugin header.
Last updated time
Time of last check in to the appropriate directory (trunk/ or the stable tag directory) after a version number change.
Creation time
Time of first check in.

I made some changes to my SVN repository. How long will it take for the WordPress.org Plugin Directory to reflect those changes?

The WordPress.org Plugin Directory updates every few minutes. However, it may take longer for your changes to appear depending on the size of the update queue.

Can I include SVN externals in my plugin?

Nope, sorry. You can add svn externals to your repository, but they won’t get added to the downloadable zip file.

How do I make one of those cool banners for my plugin page?

Start by creating an assets/ directory in the root of your SVN checkout (if one doesn't already exist). This will be on the same level as tags/ and trunk/, for example.

Inside that 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_URL_TO_YOUR_IMAGE" to preview what the page will look like with your own image. This will only work with your own plugins; you cannot use this parameter on anybody else's plugins.