6 ways to polish a plugin before release

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:

    1. Memory usage, using a tool such as WP Page Load stats to ensure you are not using more resources than expected.
    2. 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.
    3. Notices – If you haven’t developed with WP_DEBUG on (why the hell not!) enable it and fix any warnings and notices displayed.
    4. 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:

WooCommerce plugin action links

To add links, just add a filter to your plugin file:

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:

  1. A full description and list of features contained in your plugin. The more descriptive the better.
  2. ‘Tags’ (keywords) to help people find your plugin.
  3. Link to, or include, documentation and usage instructions which will help reduce the amount of support requests you receive.
  4. List methods users can submit issues, if you use an issue tracker.
  5. 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.

Readme validator result

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:

Banners 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:

POT file

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.

Found this post useful? Why not buy me a coffee :)

  • David Decker

    Great post again, Mike! I do fully agree with you, except partly for the translations/ localisations stuff in point 6 :)

    What you say is fully right and true but in my opinion that does not belong into the “polishing” work but is essential from start of the coding work – to any plugin! A plugin with hard-coded, untranslateable strings or misused translation functions of WordPress does a disservice to its users – or just “excludes” huge parts of a potential user base completely. In a globalized world, these aspects become more and more important, still, a lot of developers neglect the internationalization area of plugin development…!

    You are great example with your plugins of doing it in the right direction and I hope more developers follow your example – and include i18n/ L10n it from the beginning of the coding work!

    Keep up the good work! :)

    • mikejolley

      Thanks Dave. I localize from the start, but for beginners it can be an after thought. It’s easy to forget (or not eve consider) you may have non-english users.

  • http://lifewithamission.com/ Daniel Espinoza

    Uninstaller is a great suggestion. I need to add this in and give it some testing to my one .org plugin. Translations would be a nice addition as well!

    • David Decker

      Yeah! You should add translations from start, otherwise you’re limiting your user base… :-)

      I mostly get first translations for my plugins for some “bigger” language like Spanish, but mostly I get some from small countries with not so widespread languages, like from the baltic states, or Romania or such. Every user base counts! :-)

  • http://341design.com.au Chris Howard

    I’ve always been anti uninstaller deleting data and still am.

    If a user has to manually replace your plugin manually – and yes it is a real possibility, no matter how small – you don’t want them losing their data.

    Anything that removes their data should always be a voluntary and conscious option, never automatic.

    Putting that in an uninstaller is just too risky – even if you can build in an “Are you sure?” prompt. Put it in an options page where they have to actually choose to delete the data.

    • mikejolley

      I think in the case of SETTINGS (when you are uninstalling) it’s perfectly acceptable to remove the options.

      If however we’re talking post types, you should really have a way of making it optional. Plugins can share post types/taxonomies.

      • http://341design.com.au Chris Howard

        What if they are doing a manual reinstall and don’t want to lose any settings? e.g. installing a beta; installing an update manually.

        I know from my own experience of plugins that do delete settings, it’s as annoying as crap have to re-enter settings.

        Even ones as simple as Jetpack or Akismet that makes you have to re-authorise. (They’re even worse coz they delete that info even when you only deactivate)

        I’ve never gone down the uninstaller path, so don’t actually know what it can do, but if it can’t present a check sheet to explicitly give the user the choice over what data gets deleted, then it shouldn’t delete any.

        First rule of coding life, never ever, ever delete any of a *user’s* data – including “tables and options” – without their explicit permission.