Before you release your plugin on WordPress.org it’s always good to spend a little time polishing the final product; not only does this make your job easier in the long run (so you don’t have to fix it later), it gives a better first impression to new users.
1. Do some quality control
Before releasing a plugin, obviously testing should have already been done by yourself and others, but there are other things you should check too:
- Memory usage, using a tool such as WP Page Load stats to ensure you are not using more resources than expected.
- Dependencies – if you plugin relies on another to function, ensure you have a check for that dependency, and possibly a notice for the user to see.
- Notices – If you haven’t developed with WP_DEBUG on (why the hell not!) enable it and fix any warnings and notices displayed.
- WordPress versions – If you declare support for a range of WordPress versions, ensure you test the major ones. You can download old versions of WordPress here. Personally, I tend to only support the latest and greatest version.
2. Add some plugin_action_links
An often forgotten feature are the plugin action links – these show up on the ‘plugins’ page beneath the plugin name and, by default, consist of the ‘deactivate’, ‘settings’ and ‘edit’ links. You can add some extra ones with a few lines of code and link to things such as your documentation or support area, for example:
To add links, just add a filter to your plugin file:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| add_filter( 'plugin_action_links_' . plugin_basename( __FILE__ ), 'your_plugin_action_links' ); | |
| function your_plugin_action_links( $links ) { | |
| return array_merge( array( | |
| '<a href="' . admin_url( 'admin.php?page=your-plugin' ) . '">' . __( 'Settings'' ) . '</a>', | |
| '<a href="#someotherlink">' . __( 'Link' ) . '</a>' | |
| ), $links ); | |
| } |
3. Add an uninstaller
In the event that a user does remove your plugin, don’t leave a bad taste in their mouth by leaving data strewn everywhere; clean up. By including an uninstall.php file in your plugin’s directory which removes data (such as tables and options) you’ll ensure you don’t leave data once your plugin is removed permanently.
You can read my post on creating an uninstall.php here.
4. Improve your readme file
The readme will be the first thing a user reads before installing your plugin so ensure you include all the relevant, ‘pre-sale’ if you will, content and that you’ve tested the readme file.
Things you should include:
- A full description and list of features contained in your plugin. The more descriptive the better.
- ‘Tags’ (keywords) to help people find your plugin.
- Link to, or include, documentation and usage instructions which will help reduce the amount of support requests you receive.
- List methods users can submit issues, if you use an issue tracker.
- List any version requirements or dependencies.
One tip, try to include your main keywords in your content several times so that users can find your plugin more reliably when searching WordPress.org. For example in WooCommerce we include the word ‘eCommerce’ several times to improve our relevance when a user searches for that word specifically.
Once written you should always check its validity with the readme validator. This will help you identify any errors or missing information before deployment.
5. Make a header image for WordPress.org
You don’t have to do this before release, but a nice thing to add is a plugin banner to your page on WordPress.org:
To add a banner you need to commit it to your plugin repository in an ‘assets’ directory, named banner-772x250.png. WordPress.org will then display this above your plugin’s description.
6. Ensure your strings are localised and add a .pot file
Ensure any strings in your plugin (text you output, settings etc) are localised using WordPress’ L10n functions. Without doing this, users won’t be able to translate your plugin into their own language.
Additionally, although translators can do this themselves using a tool like codestyling localisation, or poedit, you can also include a POT file (Portable Object Template) with your plugin to save them a job. This POT file will contain all of the strings in your plugin and will form the basis for any localisation.
You can actually get WordPress.org to create this for you after committing your files – just go to the ‘admin’ section:
Now it’s your turn
Next time you go to release a plugin, don’t rush, spend a little time getting your plugin and content in order to give the best possible first impression to your new users.
Leave a Reply