CorePlugin Development

How to update a WordPress Plugin

By December 8, 2018 No Comments

How to update a custom WordPress Plugin

This post describes the necessary steps to update your Plugin when you host it on, including details about using Subversion (SVN) with

Assuming you have already submitted your Plugin to the WordPress Plugin Repository, over time you will probably find the need, and hopefully the time, to add features to your Plugin or fix bugs. Work on these changes and commit the changes to the trunk of your plugin as often as you want. The changes will be publicly visible, but only to the technically-minded people checking out your Plugin via SVN. What other users download through the website or their WordPress Plugin administration will not change.

When you’re ready to release a new version of the Plugin:

  • Make sure everything is committed and the new version actually works. Pay attention to all WordPress versions your Plugin supports and try to test it with all of them. Don’t just test the new features; also make sure you didn’t accidentally break some older functionality of the Plugin.
  • Change the version number in the header comment of the main PHP file to the new version number (in the trunk folder).
  • Change the version number in the ‘Stable tag’ field of the readme.txt file (in the trunk folder).
    Add a new sub-section in the ‘changelog’ section of the readme.txt file, briefly describing what changed compared to the last release. This will be listed on the ‘Changelog’ tab of the Plugin page.
  • Commit these changes.
  • Create a new SVN tag as a copy of trunk, following this guide.

Give the system a couple of minutes to work, and then check the Plugin page and a WordPress installation with your Plugin to see if everything updated correctly and the WordPress installation shows an update for your Plugin (the update checks might be cached, so this could take some time — try visiting the ‘available updates’ page in your WordPress installation).


The Plugin’s page on still lists the old version. Have you updated the ‘stable tag’ field in the trunk folder? Just creating a tag and updating the readme.txt in the tag folder is not enough!
The Plugin’s page offers a zip file with the new version, but the button still lists the old version number and no update notification happens in your WordPress installations. Have you remembered to update the ‘Version’ comment in the main PHP file?

For other problems check Otto’s good write-up of common problems: The Plugins directory and readme.txt files

Plugin Development Suggestions

This last section contains various suggestions regarding Plugin development.

The code of a WordPress Plugin should follow the WordPress Coding Standards. Please consider the Inline Documentation Standards as well.

All the functions in your Plugin need to have unique names that are different from functions in the WordPress core, other Plugins, and themes. For that reason, it is a good idea to use a unique function name prefix on all of your Plugin’s functions. A far superior possibility is to define your Plugin functions inside a class (which also needs to have a unique name).

Do not hardcode the WordPress database table prefix (usually “wp_”) into your Plugins. Be sure to use the $wpdb->prefix variable instead.

Database reading is cheap, but writing is expensive. Databases are exceptionally good at fetching data and giving it to you, and these operations are (usually) lightning quick. Making changes to the database, though, is a more complex process, and computationally more expensive. As a result, try to minimize the amount of writing you do to the database. Get everything prepared in your code first, so that you can make only those write operations that you need.

Use WordPress’ APIs instead of using direct SQL where possible. For example, use get_posts() or new WP_Query() instead of SELECT * FROM {$wpdb->prefix}_posts.

Use the existing database tables instead of creating new custom tables if possible. Most use-cases can be accomplished with custom post types and meta data, custom taxonomy and/or one of the other standard tables and using the standard tables provides a lot of UI and other functionality “for free.” Think very carefully before adding a table because it adds complexity to your plugin that many users and site builders prefer to avoid.

SELECT only what you need. Even though databases fetch data blindingly fast, you should still try to reduce the load on the database by only selecting that data which you need to use. If you need to count the number of rows in a table don’t SELECT * FROM, because all the data in all the rows will be pulled, wasting memory. Likewise, if you only need the post_id and the post_author in your Plugin, then just SELECT those specific fields, to minimize database load. Remember: hundreds of other processes may be hitting the database at the same time. The database and server each have only so many resources to spread around amongst all those processes. Learning how to minimize your Plugin’s hit against the database will ensure that your Plugin isn’t the one that is blamed for abuse of resources.

Eliminate PHP errors in your plugin. Add define(‘WP_DEBUG’, true); to your wp-config.php file, try all of your plugin functionality, and check to see if there are any errors or warnings. Fix any that occur, and continue in debug mode until they have all been eliminated.

Try not to echo <script> and <style> tags directly – instead use the recommended wp_enqueue_style() and wp_enqueue_script() functions. They help eliminate including duplicate scripts and styles as well as introduce dependency support. See posts by the following people for more info: Ozh Richard, Artem Russakovskii, and Vladimir Prelovac.

Content Credit:

Leave a Reply