Plugin Update Checker 1.2 Released

After a long delay, a new version of my PluginUpdateChecker library is finally ready for release. Read on to find out what’s new, or go straight to the download page.

For those of you not familiar with this library, here’s a short summary:

You can use it to add automatic update support to any WordPress plugin.
Especially useful for commercial plugins that can’t be hosted on the official WordPress.org repository.
Free and open source.
See the original post for more details.

Here’s what’s new in this version:

Added a “Check For Updates” Link

This version adds a new “Check for updates” link to the associated plugin’s row in the Plugins page. Clicking the link will trigger an immediate update check. You can change the link text by using the puc_manual_check_link-$slug filter. To disable the link, return an empty string from the filter.

Debug Bar Integration

(Click to view full size screenshot.)

Judging by the comments that the previous version received, one of the things that it was really missing was better error reporting and debugging features. When it worked, it worked well. When it didn’t, it was ridiculously hard to figure out why.

To make debugging easier, this version adds a new Debug Bar panel that displays all kinds of useful information about the update checker, including all of its configuration fields, last check timestamp, cached update information and more. You can also click “Request Info” to download and parse the metadata file, which is a good way to make sure the URL and file format are correct. If you have multiple plugins using this library, each plugin gets its own Debug Bar panel.

New `$debugMode` Setting

You can set $updateChecker->debugMode to true to make the library report errors that it would usually ignore. For example, if it gets an HTTP error while trying to download plugin information, it will usually fail silently and treat it as “no updates available”. With debug mode enabled, it will trigger a PHP warning instead. Debug mode will be enabled automatically if WP_DEBUG is enabled.

New `getUpdate()` Method

Previously there was no good way to get information about available updates from the update checker instance. Sure, the updates would show up just fine in the WordPress UI, but if you wanted to get the update details from inside your plugin, you had to jump through quite a few hoops.

In this version, you can just call getUpdate(). It returns an instance of PluginUpdate if there is an update available, or null otherwise. Note that this method uses the internal cache, so use checkForUpdates() instead if you want the most recent information.

Other Changes

Added a resetUpdateState() method. It clears the update cache, last check timestamp and last checked version number.
checkForUpdates() now returns the update details, if any. It didn’t return anything in the previous version.
You can use the new puc_pre_inject_info-$slug filter to modify the update just before it’s passed to WordPress.
Store cached updates as generic StdClass objects to prevent the “Tried to use an incomplete object” error on sites that use an object cache.
Fixed an incompatibility between this library and WooThemes plugin updater that would cause no updates to show up even if everything was configured correctly. The problem: both libraries use the plugins_api filter, but the WooThemes updater throws away the response returned by other plugins and breaks my update checker.
Minor code clean-up.

Related posts :

This entry was posted on Tuesday, October 30th, 2012 at 10:20 and is filed under WordPress Development, WordPress Tools. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

« Tell Your Users Where Your Plugin Puts Its Menu Pages | 8 Great Tools For Working With JSON »

20 Responses to “Plugin Update Checker 1.2 Released”

Zach says:

October 31, 2012 at 15:52

Hi Janis,
Thanks for the update! When enabled, ran across a few errors:

(front-end)
Fatal error: Call to undefined function get_submit_button() in /wp-content/plugins/mouldings/includes/plugin-updates/debug-bar-panel.php on line 37

(back-end)
Notice: Use of undefined constant HOUR_IN_SECONDS – assumed ‘HOUR_IN_SECONDS’ in /wp-content/plugins/mouldings/includes/plugin-updates/debug-bar-panel.php on line 100

For the back-end, changing HOUR_IN_SECONDS to ‘HOUR_IN_SECONDS’ did the trick, but didn’t see that defined anywhere. For get_submit_button() – that’s a bit odd, since it’s a core WP function – any thoughts? Thanks!
Jānis Elsts says:

October 31, 2012 at 17:38

Apparently WP only includes the file where get_submit_button() is defined only in the WP admin, so the function isn’t available in the front-end. Also, HOUR_IN_SECONDS is a new constant that’s going to be introduced in WP 3.5; I should’ve just used the literal value (i.e. 3600 seconds) for compatibility.

I’ve fixed both errors.
Zach says:

October 31, 2012 at 19:01

Awesome — I downloaded the .zip again and didn’t see it in there, but adjusted both the constant and changed $requestInfoButton to:

”

and it worked great. Thanks!
Zach says:

October 31, 2012 at 19:02

Let’s try that again: http://pastebin.com/mCTDBHaN
Jānis Elsts says:

October 31, 2012 at 19:47

You probably got an old cached version from the CDN. Try this link: http://w-shadow.com/files/plugin-updates.zip
Zach says:

November 5, 2012 at 17:06

Hey Janis,
Just ran into another little notice:

plugin-update-checker.php on line 377

This is only happening after a plugin is updated (that is not part of the PUC). Showing up 3 times for me when one plugin was updated. Perhaps it’s trying to unset a plugin update that was not needed (since the plugin sent through PUC wasn’t in need of an upgrade)? Thanks!
Jānis Elsts says:

November 5, 2012 at 17:14

Yep, the notice shows up because it tries to remove a non-existent update. I actually fixed that one a few days ago but forgot to upload the new version to this site. Here it is.
Zach says:

November 5, 2012 at 18:35

Nice, appreciate it!
Sisir says:

September 13, 2013 at 16:14

Hey, Great work with update with plugin updater. I was wondering if there will be any update on theme updater too?
Jānis Elsts says:

September 13, 2013 at 16:24

Eventually there probably will be, but right now I’m mostly focusing on some of my plugins.
Matt says:

November 1, 2013 at 03:41

was wondering if this works with wordpress 3.7
Matt says:

November 1, 2013 at 04:01

I have this working with 3.7 but I can not seem to get the Check for Updates link to show up. Anything special that needs to be done? I am running 1.3.2.
Jānis Elsts says:

November 1, 2013 at 10:29

Yes, it works in WP 3.7. Are you sure you have the latest version? Try downloading it from GitHub.

Normally you don’t need to do anything special to display the “check for updates” link. Just make sure the plugin filename (second constructor argument) is correct.
Matt says:

November 1, 2013 at 15:34

Thanks Janis, I did find what my issues were. 1st, the GitHub latest version 1.3.2 has the class name changed, so your sample code above will not work unless you change the class name. That was no biggy.

The second issue I have is because of my structure of my development environment, which I am not sure I can get around. I have each of my plugins in my own repos, and locally I just symlink those repos into the /wp-content/plugins/{{plugin}}/ all of that works great, the issue is when we use the functions plugin_basename() or any wordpress paths, it pulls the FULL path which is not inside of wordpress plugins folder…

So what I did to make it work just now was to edit your class. All I did was add another variable for path.

public function __construct($metadataUrl, $pluginFile, $slug = ”, $checkPeriod = 12, $optionName = ”, $pluginPath){

$this->metadataUrl = $metadataUrl;

if(empty($pluginPath)){
$this->pluginAbsolutePath = $pluginFile;
$this->pluginFile = plugin_basename($this->pluginAbsolutePath);
} else {
$this->pluginAbsolutePath = $pluginPath;
$this->pluginFile = $pluginFile;
}

Any other suggestions on how to do this other than what I have done?
Jānis Elsts says:

November 1, 2013 at 16:08

Yes, the main class name has a version number suffix, but there should also be a backwards-compatible subclass named “PluginUpdateChecker”. Are you saying it’s not there or didn’t work for you?

As for suggestions, I would not recommend editing the update checker class directly. Instead, create a subclass with a custom constructor that handles your symlinked paths. This way, when a new version of the update checker comes out, you can install it without having to worry about your code modifications being preserved. For example:
```
class MyUpdateChecker extends PluginUpdateChecker {
    public function __construct() {
        parent::__construct(...);
        /* your custom constructor here */
    }
}
```
Matt says:

November 1, 2013 at 16:37

Janis, I do see the extended class, but I don’t believe that was working for me. It wasn’t even firing when I was doing straight error_log on the class init. It only started working when I changed the name of the main class to PluginUpdateChecker without the version number.
Jānis Elsts says:

November 1, 2013 at 18:31

I see. Do you perhaps have multiple active plugins that use this library? If so, then the copy tha is loaded first will take the PluginUpdateChecker class name, and any changes made to other copies of the library will appear to have no effect unless you use the versioned class.
Automatic Updates For Private And Commercial Themes | W-Shadow.com · Japh says:

January 24, 2017 at 11:03

[…] Plugin Update Checker 1.2 Released […]
Marco says:

June 17, 2018 at 19:45

Great tool.

I have only one question. Is it possible to use a single .json file for multiple plugins? If you are like. I created it and it works but only the first plugin in the list can be updated.

For everyone else he says that it is not possible to find the update.
Jānis Elsts says:

June 18, 2018 at 15:00

No, that isn’t possible. If you have multiple plugins, you’ll need one file for each plugin.