Congratulations! You’ve managed to get your plugin added to the WordPress.org directory. But, other than adding your plugin code, what should you do now?
Here are the 10 things that I’d recommend…
1. Enable Release Confirmation
Only last months a number of WordPress plugins were compromised after attackers gained access to their SVN repos. You can help prevent this in future by switching on Release Confirmation. It also has an additional benefit too.
Release confirmation, when switched on, prevents changes to your SVN repo from going “live”. When you make code changes (so, a README change won’t be affected by this, for example) you will receive an email with unique link in it – only once you click on this and confirm that the changes are correct, will they be available to the public.
Once switched on, you have to contact the Plugins team to switch it off – which ensures that no bad actors, with access to your account, can do this,.
Here’s how to switch it on…
That second advantage that I mentioned? It means that you can wait until your changes are made before committing them – otherwise, it’s possible for users to get partial, broken, downloads whilst your committing changes. Just make sure to only confirm your changes once all of them have been made.
2. Add committers and support reps
This may seem obvious, but next I’d recommend adding any other developers who think should have access to the code (“committers”) or anyone who should be noted as an official support representative in the support forum (“support reps”).
To add these…
Obviously, for the sake of security, keep the committers down to an absolute minimum and make sure they’re following best security practices for their passwords.
If you ever wish to transfer your plugin to another user, you’d add them as an additional committer and then you’ll find there will be an option to remove yourself as one.
3. Add Image Assets
Icons, banners and screenshots can all be placed in the assets folder within your SVN report.
Read my earlier blog post, to learn everything you can about these assets – maximum sizes, filename formats, etc.
4. Add a WordPress Playground Blueprint
WordPress Playground lets you create your own WordPress instance in the browser, and plugins in the directory can make use of this to provide a one-click method for users to try out your plugin.
Like the Image Assets option above, I already have a post available for this, which will explain everything!
5. Subscribe to the Forum
I believe you may already be automatically subscribed to it once your plugin is added to the directory, but I’d always recommend check and confirming this.
To check if you’re subscribed, simply head into the support forum. If you see this as the top, you’re already subscribed…
If not, check the sidebar. If the button reads “Subscribe to this plugin”, then you’ll need to click on this to do so.
6. Consider a Classification
Relatively recently, a classification system was added to WordPress, allowing you to specify whether your plugin is a Commercial or Community plugin. Adding it to one of these gives you the following…
- You will be listed in the appropriate plugin section – community and commercial
- A header will be added to your plugin, showing your classification, and (optionally) showing a link either your external support (for commercial plugins) or your contributor area (for community plugins – usually a link to a Github repo, or similar). It will look like one of these…
To have your plugin classified, right now, it’s a manual process and you need to contact the plugin review team (email plugins@wordpress.org). Once that’s done, do the following to access the area where you can add a link (for this example, it’s a community plugin)…
7. Add it to the Block Directory
If you plugin makes use of blocks, then you can look at adding it to the block directory.
To do this, head to the Block Plugin Validator
Type in your repo name and click the “Check Plugin!” button. If all goes well and no issues are found, you’ll get a screen similar to this, with a button allowing you to toggle your plugin in and out of the directory…
If any issues are found, however, you’ll get messages such as this.
8. Provide a place to share requested features and known bugs
The provided Support Forum is great, but really just for that. When it comes to tracking feature requests or bugs, this isn’t the place. Consider somewhere such as a Github repo where you can do this. However, make sure you’re clear with users where each should be used – you can make use of templates in Github issues, for example, and pin posts in the .org Support forum to direct people to where they should be.
9. Translate
The default language for WordPress, and plugins, is US English, so even if you’re native language is British English, you can provide translation options for your plugin! Of course, if you have other language skills too, then you can easily use these to add automatic translation to your plugin.
Here’s how to access the translation options for your plugin…
I’ve found that it takes a little while for your code versions to be picked up, so I wait about a day after an update before trying this out, just to make sure the latest revisions are available.
10. Promote!
This is the bit I often forget – start promoting your plugin. Even if this is a non-commercial plugin, you can try and get it known. Whether forums (such as Reddit), social media or WordPress news sites (WP Tavern has, in the past, mentioned my plugins, for example), there are various things you can do to get it known about. Or just blog about it!
Literally hours after this post went live, it was mentioned in a Github issue for GatherPress, where they used the 10 steps above as a check-list after getting their plugin into the directory. Please go and try it!
Thanks to Carsten for his very timely acknowledgement that all of this made sense!
Share this post on social media.
Leave a Reply