yahniselsts/plugin-update-checker

A custom update checker for WordPress plugins. Useful if you don't want to host your project in the official WP repository, but would still like it to support automatic updates. Despite the name, it also works with themes.

Plugin Update Checker

This is a custom update checker library for WordPress plugins and themes. It lets you add automatic update notifications and one-click upgrades to your commercial plugins, private themes, and so on. All you need to do is put your plugin/theme details in a JSON file, place the file on your server, and pass the URL to the library. The library periodically checks the URL to see if there's a new version available and displays an update notification to the user if necessary.

From the users' perspective, it works just like with plugins and themes hosted on WordPress.org. The update checker uses the default upgrade UI that is familiar to most WordPress users.

Table of Contents

• Getting Started
  • Self-hosted Plugins and Themes
    • How to Release an Update
    • Notes
  • GitHub Integration
    • How to Release an Update
    • Notes
  • BitBucket Integration
    • How to Release an Update
  • GitLab Integration
    • How to Release a GitLab Update
• Migrating from 4.x
• License Management
• Resources

Getting Started

Note: In each of the below examples, part of the instructions are to create an instance of the update checker class. It's recommended to do this either during the plugins_loaded action or outside of any hooks. If you do it only during an admin_* action, then updates will not be visible to a wide variety of WordPress maanagement tools; they will only be visible to logged-in users on dashboard pages.

Self-hosted Plugins and Themes

1. Download the latest release and copy the plugin-update-checker directory to your plugin or theme.

2. Go to the examples subdirectory and open the .json file that fits your project type. Replace the placeholder data with your plugin/theme details.

   • Plugin example:

      {
      	"name" : "Plugin Name",
      	"version" : "2.0",
      	"download_url" : "https://example.com/plugin-name-2.0.zip",
      	"sections" : {
      		"description" : "Plugin description here. You can use HTML."
      	}
      }

     This is a minimal example that leaves out optional fields. See this table for a full list of supported fields and their descriptions.

   • Theme example:

      {
      	"version": "2.0",
      	"details_url": "https://example.com/version-2.0-details.html",
      	"download_url": "https://example.com/example-theme-2.0.zip"
      }

     This is actually a complete example that shows all theme-related fields. version and download_url should be self-explanatory. The details_url key specifies the page that the user will see if they click the "View version 1.2.3 details" link in an update notification.

3. Upload the JSON file to a publicly accessible location.

4. Add the following code to the main plugin file or to the functions.php file:

   require 'path/to/plugin-update-checker/plugin-update-checker.php';
   use YahnisElsts\PluginUpdateChecker\v5\PucFactory;
   
   $myUpdateChecker = PucFactory::buildUpdateChecker(
   	'https://example.com/path/to/details.json',
   	__FILE__, //Full path to the main plugin file or functions.php.
   	'unique-plugin-or-theme-slug'
   );

   Note: If you're using the Composer autoloader, you don't need to explicitly require the library.

How to Release an Update

Change the version number in the JSON file and make sure that download_url points to the latest version. Update the other fields if necessary. Tip: You can use wp-update-server to automate this process.

By default, the library will check the specified URL for changes every 12 hours. You can force it to check immediately by clicking the "Check for updates" link on the "Plugins" page (it's next to the "Visit plugin site" link). Themes don't have that link, but you can also trigger an update check like this:

1. Install Debug Bar.
2. Click the "Debug" menu in the Admin Bar (a.k.a Toolbar).
3. Open the "PUC (your-slug)" panel.
4. Click the "Check Now" button.

Notes

• The second argument passed to buildUpdateChecker must be the absolute path to the main plugin file or any file in the theme directory. If you followed the "getting started" instructions, you can just use the __FILE__ constant.

• The third argument - i.e. the slug - is optional but recommended. In most cases, the slug should be the same as the name of your plugin directory. For example, if your plugin lives in /wp-content/plugins/my-plugin, set the slug to my-plugin. If the slug is omitted, the update checker will use the name of the main plugin file as the slug (e.g. my-cool-plugin.php → my-cool-plugin). This can lead to conflicts if your plugin has a generic file name like plugin.php.

  This doesn't affect themes because PUC uses the theme directory name as the default slug. Still, if you're planning to use the slug in your own code - e.g. to filter updates or override update checker behaviour - it can be a good idea to set it explicitly.

GitHub Integration

1. Download the latest release and copy the plugin-update-checker directory to your plugin or theme.

2. Add the following code to the main plugin file or functions.php:

   require 'plugin-update-checker/plugin-update-checker.php';
   use YahnisElsts\PluginUpdateChecker\v5\PucFactory;
   
   $myUpdateChecker = PucFactory::buildUpdateChecker(
   	'https://github.com/user-name/repo-name/',
   	__FILE__,
   	'unique-plugin-or-theme-slug'
   );
   
   //Set the branch that contains the stable release.
   $myUpdateChecker->setBranch('stable-branch-name');
   
   //Optional: If you're using a private repository, specify the access token like this:
   $myUpdateChecker->setAuthentication('your-token-here');

3. Plugins only: Add a readme.txt file formatted according to the WordPress.org plugin readme standard to your repository. The contents of this file will be shown when the user clicks the "View version 1.2.3 details" link.

How to Release an Update

This library supports a couple of different ways to release updates on GitHub. Pick the one that best fits your workflow.

• GitHub releases

  Create a new release using the "Releases" feature on GitHub. The tag name and release title don't matter. The description is optional, but if you do provide one, it will be displayed when the user clicks the "View version x.y.z details" link on the "Plugins" page. Note that PUC ignores releases marked as "This is a pre-release".

  If you want to use release assets, call the enableReleaseAssets() method after creating the update checker instance:

   $myUpdateChecker->getVcsApi()->enableReleaseAssets();

• Tags

  To release version 1.2.3, create a new Git tag named v1.2.3 or 1.2.3. That's it.

  PUC doesn't require strict adherence to SemVer. These are all valid tag names: v1.2.3, v1.2-foo, 1.2.3_rc1-ABC, 1.2.3.4.5. However, be warned that it's not smart enough to filter out alpha/beta/RC versions. If that's a problem, you might want to use GitHub releases or branches instead.

• Stable branch

  Point the update checker at a stable, production-ready branch:

   $updateChecker->setBranch('branch-name');

  PUC will periodically check the Version header in the main plugin file or style.css and display a notification if it's greater than the installed version.

  Caveat: If you set the branch to master (the default), the update checker will look for recent releases and tags first. It'll only use the master branch if it doesn't find anything else suitable.

Notes

The library will pull update details from the following parts of a release/tag/branch:

• Version number
  • The "Version" plugin header.
  • The latest GitHub release or tag name.
• Changelog
  • The "Changelog" section of readme.txt.
  • One of the following files: CHANGES.md, CHANGELOG.md, changes.md, changelog.md
  • GitHub release notes.
• Required and tested WordPress versions
  • The "Requires at least" and "Tested up to" fields in readme.txt.
  • The following plugin headers: Required WP, Tested WP, Requires at least, Tested up to
• "Last updated" timestamp
  • The creation timestamp of the latest GitHub release.
  • The latest commit in the selected tag or branch.
• Number of downloads
  • The download_count statistic of the latest release.
  • If you're not using GitHub releases, there will be no download stats.
• Other plugin details - author, homepage URL, description
  • The "Description" section of readme.txt.
  • Remote plugin headers (i.e. the latest version on GitHub).
  • Local plugin headers (i.e. the currently installed version).
• Ratings, banners, screenshots
  • Not supported.

BitBucket Integration

1. Download the latest release and copy the plugin-update-checker directory to your plugin or theme.

2. Add the following code to the main plugin file or functions.php:

   require 'plugin-update-checker/plugin-update-checker.php';
   use YahnisElsts\PluginUpdateChecker\v5\PucFactory;
   
   $myUpdateChecker = PucFactory::buildUpdateChecker(
   	'https://bitbucket.org/user-name/repo-name',
   	__FILE__,
   	'unique-plugin-or-theme-slug'
   );
   
   //Optional: If you're using a private repository, create an OAuth consumer
   //and set the authentication credentials like this:
   //Note: For now you need to check "This is a private consumer" when
   //creating the consumer to work around #134:
   // https://github.com/YahnisElsts/plugin-update-checker/issues/134
   $myUpdateChecker->setAuthentication(array(
   	'consumer_key' => '...',
   	'consumer_secret' => '...',
   ));
   
   //Optional: Set the branch that contains the stable release.
   $myUpdateChecker->setBranch('stable-branch-name');

3. Optional: Add a readme.txt file formatted according to the WordPress.org plugin readme standard to your repository. For plugins, the contents of this file will be shown when the user clicks the "View version 1.2.3 details" link.

How to Release an Update

BitBucket doesn't have an equivalent to GitHub's releases, so the process is slightly different. You can use any of the following approaches:

• Stable tag header

  This is the recommended approach if you're using tags to mark each version. Add a readme.txt file formatted according to the WordPress.org plugin readme standard to your repository. Set the "stable tag" header to the tag that represents the latest release. Example:

   Stable tag: v1.2.3
  

  The tag doesn't have to start with a "v" or follow any particular format. You can use any name you like as long as it's a valid Git tag.

  Tip: If you explicitly set a stable branch, the update checker will look for a readme.txt in that branch. Otherwise it will only look at the master branch.

• Tags

  You can skip the "stable tag" bit and just create a new Git tag named v1.2.3 or 1.2.3. The update checker will look at the most recent tags and pick the one that looks like the highest version number.

  PUC doesn't require strict adherence to SemVer. These are all valid tag names: v1.2.3, v1.2-foo, 1.2.3_rc1-ABC, 1.2.3.4.5. However, be warned that it's not smart enough to filter out alpha/beta/RC versions.

• Stable branch

  Point the update checker at a stable, production-ready branch:

   $updateChecker->setBranch('branch-name');

  PUC will periodically check the Version header in the main plugin file or style.css and display a notification if it's greater than the installed version. Caveat: If you set the branch to master, the update checker will still look for tags first.

GitLab Integration

1. Download the latest release and copy the plugin-update-checker directory to your plugin or theme.

2. Add the following code to the main plugin file or functions.php and define how you want to check for updates from Gitlab (refer to: Gitlab: How to Release an Update):

   require 'plugin-update-checker/plugin-update-checker.php';
   use YahnisElsts\PluginUpdateChecker\v5\PucFactory;
   
   $myUpdateChecker = PucFactory::buildUpdateChecker(
   	'https://gitlab.com/user-name/repo-name/',
   	__FILE__,
   	'unique-plugin-or-theme-slug'
   );
   
   //Optional: If you're using a private repository, specify the access token like this:
   $myUpdateChecker->setAuthentication('your-token-here');

   Alternatively, if you're using a self-hosted GitLab instance, initialize the update checker like this:

   use YahnisElsts\PluginUpdateChecker\v5p4\Vcs\PluginUpdateChecker;
   use YahnisElsts\PluginUpdateChecker\v5p4\Vcs\GitLabApi;
   
   $myUpdateChecker = new PluginUpdateChecker(
   	new GitLabApi('https://myserver.com/user-name/repo-name/'),
   	__FILE__,
   	'unique-plugin-or-theme-slug'
   );
   //Optional: Add setAuthentication(...) and setBranch(...) as shown above.  

   If you're using a self-hosted GitLab instance and subgroups or nested groups, you have to tell the update checker which parts of the URL are subgroups:

   use YahnisElsts\PluginUpdateChecker\v5p4\Vcs\PluginUpdateChecker;
   use YahnisElsts\PluginUpdateChecker\v5p4\Vcs\GitLabApi;
   
   $myUpdateChecker = new PluginUpdateChecker(
   	new GitLabApi(
   		'https://myserver.com/group-name/subgroup-level1/subgroup-level2/subgroup-level3/repo-name/', 
   		null, 
   		'subgroup-level1/subgroup-level2/subgroup-level3'
   	),
   	__FILE__,
   	'unique-plugin-or-theme-slug'
   );

3. Plugins only: Add a readme.txt file formatted according to the WordPress.org plugin readme standard to your repository. The contents of this file will be shown when the user clicks the "View version 1.2.3 details" link.

How to Release a GitLab Update

A GitLab repository can be checked for updates in 3 different ways.

• GitLab releases

  Create a new release using the "Releases" feature on GitLab. The tag name should match the version number. You can add a v prefix to the tag, like v1.2.3. Releases that are marked as "Upcoming Release" will be automatically ignored.

  If you want to use custom release assets, call the enableReleaseAssets() method after creating the update checker instance:

   $myUpdateChecker->getVcsApi()->enableReleaseAssets();

  By default, PUC will use the first available asset link, regardless of type. You can pass a regular expression to enableReleaseAssets() to make it pick the first link where the URL matches the regex. For example:

   $myUpdateChecker->getVcsApi()->enableReleaseAssets('/\.zip($|[?&#])/i');

  Tip: You can use a Gitlab CI/CD Pipeline to automatically generate your update on release using a Generic Package. For more information about generic packages, refer to the following links: - Gitlab CI/CD Release Documentation - Gitlab Release Assets as Generic Package Documentation - Example .gitlab-ci.yml file using Release Generic Packages for generating a update package from the Sensei-LMS wordpress plugin

• Tags

  To release version 1.2.3, create a new Git tag named v1.2.3 or 1.2.3. The update checker will look at recent tags and use the one that looks like the highest version number.

  PUC doesn't require strict adherence to SemVer. However, be warned that it's not smart enough to filter out alpha/beta/RC versions. If that's a problem, you might want to use GitLab branches instead.

• Stable branch

  Point the update checker at any stable, production-ready branch:

   $myUpdateChecker->setBranch('stable-branch-name');

  PUC will periodically check the Version header in the main plugin file or style.css and display a notification if it's greater than the installed version. Caveat: Even if you set the branch to main (the default) or master (the historical default), the update checker will still look for recent releases and tags first.

Migrating from 4.x

Older versions of the library didn't use namespaces. Code that was written for those versions will need to be updated to work with the current version. At a minimum, you'll need to change the factory class name.

Old code:

$myUpdateChecker = Puc_v4_Factory::buildUpdateChecker(
	'https://example.com/info.json',
	__FILE__,
	'my-slug'
);

New code:

use YahnisElsts\PluginUpdateChecker\v5\PucFactory;

$myUpdateChecker = PucFactory::buildUpdateChecker(
	'https://example.com/info.json',
	__FILE__,
	'my-slug'
);

Other classes have also been renamed, usually by simply removing the Puc_vXpY_ prefix and converting Category_Thing to Category\Thing. Here's a table of the most commonly used classes and their new names:

Old class name	New class name
Puc_v4_Factory	YahnisElsts\PluginUpdateChecker\v5\PucFactory
Puc_v4p13_Factory	YahnisElsts\PluginUpdateChecker\v5p4\PucFactory
Puc_v4p13_Plugin_UpdateChecker	YahnisElsts\PluginUpdateChecker\v5p4\Plugin\UpdateChecker
Puc_v4p13_Theme_UpdateChecker	YahnisElsts\PluginUpdateChecker\v5p4\Theme\UpdateChecker
Puc_v4p13_Vcs_PluginUpdateChecker	YahnisElsts\PluginUpdateChecker\v5p4\Vcs\PluginUpdateChecker
Puc_v4p13_Vcs_ThemeUpdateChecker	YahnisElsts\PluginUpdateChecker\v5p4\Vcs\ThemeUpdateChecker
Puc_v4p13_Vcs_GitHubApi	YahnisElsts\PluginUpdateChecker\v5p4\Vcs\GitHubApi
Puc_v4p13_Vcs_GitLabApi	YahnisElsts\PluginUpdateChecker\v5p4\Vcs\GitLabApi
Puc_v4p13_Vcs_BitBucketApi	YahnisElsts\PluginUpdateChecker\v5p4\Vcs\BitBucketApi

License Management

Currently, the update checker doesn't have any built-in license management features. It only provides some hooks that you can use to, for example, append license keys to update requests ($updateChecker->addQueryArgFilter()). If you're looking for ways to manage and verify licenses, please post your feedback in this issue.

Resources

• This blog post has more information about the update checker API. Slightly out of date.
• Debug Bar - useful for testing and debugging the update checker.
• Update format reference - describes all fields supported by the JSON-based update information format used by the update checker. Only covers plugins. Themes use a similar but more limited format.
• Securing download links - a general overview.
• A GUI for entering download credentials
• Theme Update Checker - an older, theme-only variant of this update checker.

plugin-update-checker's Issues

Warning: $updates->response

► IGNORE THIS. Just found version 1.3 on GitHub...

Hello Janis,

plugin-update-checker.php
Version 1.2
Line 377:
unset($updates->response[$this->pluginFile]);

I had to surround it as follows:

if (!empty($updates)) {
    unset($updates->response[$this->pluginFile]);
}

Otherwise, I was getting warnings because $updates came as boolean false.

Thank you!

Reducing frequency of update checks

Hi Yahnis,

First, I think you'll be happy to know that those changes we worked on a few weeks ago appear to have entirely worked. That is, I have had zero people telling me that updates were not showing in their dashboard. (To refresh your memory: I used to get around 1% of users (usually on multisite, it seemed) saying that no update would show up even though pressing "Check for updates" manually displayed the message saying that an update had been found). I've been using the new code for about 6 weeks, with zero reports of the issue since then.

Secondly... I had a new idea. I think we've both faced the issue of the load caused by all the update check-ins:

Background: Lots of people never (or very rarely) update their sites. Even those that do, may not do so immediately on day one of the update. Yet, their sites continue to perform the update check, every day (or whatever you set it to).

One solution would be to perform the update check only weekly. I can already do that. But that carries other risks. e.g. If a release of the plugin has a hideous bug, then I want everyone to update immediately before a) it breaks their sites, or b) I get the same support request 25 times. So, that solution is problematic.

Better idea: If there is already an existing update available, then do not perform a further update check until a lot later. (e.g. max(7 * update period, month)). When it is known that an update is available, the only useful function performed by further checks is to refresh the exact version number of the update available, and to refresh other meta-data (e.g. changelog). This update is wasted on people who never update, and only marginally useful for people who do (and even then, is only useful if frequent releases of new versions are being made).

What's gained from this? An approximate 85% (6 parts in 7, in my example of daily becoming weekly) drop in the number of update checks. What's lost? Very little.

What do you think?

Multisite problems

Hi Yahnis,

I used your excellent library in UpdraftPlus Backup/Restore (http://updraftplus.com) - thank you.

There's just one report that keeps cropping up - some multisite users don't get to see the availability of updates.

I've finally been able to log in on someone's site where they're having this problem. Here's what I can see (the site in question currently has 1.7.20 - the update is to 1.7.20.1)

• I click the manual "check for updates" link (in the network dashboard admin), it sends the HTTP request; and the response is correct. The link is:
  http://example.com/wp-admin/network/plugins.php?puc_check_for_updates=1&puc_slug=updraftplus&_wpnonce=(nonce)

Example HTTP response:

stdClass Object
(
    [name] => UpdraftPlus - Backup/Restore
    [slug] => updraftplus
    [download_url] => http://updraftplus.com/.../?download&token=(snip)
    [version] => 1.7.20.1
    [author] => UpdraftPlus.Com
    [sections] => stdClass Object
        (
            [description] => Backup and restore: your content and database can be automatically backed up to Amazon S3, Dropbox, Google Drive, Rackspace Cloud Files, FTP or email, on separate schedules.<p><strong>Add-ons for this site:</strong></p><ul><li>Migrate a WordPress site to a different location. - Import a backup into a different site, incluing database search-and-replace. Ideal for development and testing and cloning of sites.</li></ul>
        )

    [requires] => 3.2
    [homepage] => http://updraftplus.com
    [tested] => 3.6.1
)

The WordPress admin page displays the message at the top: "A new version of this plugin is available."

However, no update shows. When I throw in some code to var_dump(get_site_transient('plugins_update')), then the output does not show the above data - it shows the current version of the plugin (1.7.20).

I suspect that it is relevant that the multisite has an object cache active (these store transient data).

Any ideas? Unfortunately I get a report about this one or two times each week!

Best wishes,
David

Multisite

I did the following mods for it to work in MS:

$hook = ( is_multisite() ) ? 'network_admin_notices' : 'admin_notices';
add_action( $hook, array( $this, 'displayManualCheckResult' ) );```

$url = ( is_multisite() ) ? network_admin_url( 'plugins.php' ) : admin_url( 'plugins.php' ); wp_redirect( add_query_arg( array( 'puc_update_check_result' => $status, 'puc_slug' => $this->slug, ), $url ) ); }

Issue updating more than one plugin

I've come across an issue when updating more than one plugin using the library. The updater displays the wrong information on the second plugin. Here is a screenshot.

https://docs.google.com/a/radiumthemes.com/file/d/0BznInrRXOU8XZlJDdjRmSlRHeTQ/edit?usp=drivesdk

I believe it's mixing up the updates and reporting the same data for both plugins.

Any help is appreciated.
Frank.

Code spacing when updating a plugin

I notice on a test site after i used the plugin updater that the source code of the plugin in discussion got some extra spaces

Something like

$var = 123;
$newvar = 234;

became

$var = 123;

$newvar = 234;

any ideas ?

after update complete my plugin folder name changed

Hello, can u help me whats the problem. I updating the plugin and after update complete, i go to plugins dir and the plugin folder name is changed like plugin-name-"deaf324" --> this is always a random key.
Any idea? thanks

Different plugin file name

For example my plugin folder is called my-plugin/
The zip that goes in the server part is my-plugin.zip
The main file that runs my plugin is called my_custom_plugin.php

As you can see is different from the dir names.
Whats the right code to use for the checker in the main plugin file cause i`m having issues getting it to work
For example something like this does not work

$update_checker = PucFactory::buildUpdateChecker(
                    'http://mysite/?action=get_metadata&slug=my-plugin', //Metadata URL.
                    __FILE__
                );

Issue with updating via GitHub

When using the GitHubChecker class, the update has the commit hash appended to the end of the plugin folder downloaded from GH, breaking the update since the plugin has moved to a new path.

Any suggestions on how to resolve?

Plugin details

Thanks for the fantastic code!

How do I add a URL to the plugin details as per your theme updater?

Currently, the update detects there is a new version but shows this link...

http://cl.ly/image/2o3a1d0n0N1a

When you click on the link you get this error...

http://cl.ly/image/1r1H2O2b1E1c

Any simple fixes?

Bad renaming when I updated from Manage WP

Hi,

When I update from Manage WP the plugin folder name is rename like
username-pluginrepository-0b6ff025db8a4578bea1fdf10ff80c7c35da5efe

What can I do for not change the plugin folder name when I update it?

Thanks a lot for your answer.

Best regards,

Salah.

Getting "Update Failed: The directory structure of the update is incorrect." (When directory structure appears to be correct)

Hello,

I'm trying to use both the plugin update checker and the WP update server. As far as I can tell, the update server is working fine; visiting http://myserver.com/wp-update-server/?action=get_metadata&slug=my-plugin gives me a nice JSON output.

However, when updating plugins, the update checker (3.1) successfully recognizes that an update is available, but whenever I actually attempt the update, I get this message:

"Update Failed: The directory structure of the update is incorrect. All plugin files should be inside a directory named [directory-name], not at the root of the ZIP file."

Note: [directory-name] here is where the actual directory name appears.

I've triple-checked that the ZIP file specified by "download_url" in the JSON output expands to create a single folder, with all plugin files and subdirectories contained inside it. All plugin files are indeed inside a directory with the same name as the plugin slug, not at the root of the ZIP. As far as I can tell, the directory structure is correct:

pluginname.zip -> extracts to create -> pluginname (directory) -> which contains pluginname.php (along with other plugin files)

I've also tried creating an alternate directory structure by nesting the pluginname folder inside ANOTHER directory by the same name, then zipping it up for the updater to use. When I do that, I receive a 500 Error from the update server, telling me that no valid package was found.

This has to be a bug, right? Or am I nuts?

Disabling SSL verification on plugin updates

Hi Yahnis,

first thanks for your great plugin, I use it in my plugin Maps Marker Pro (www.mapsmarker.com).

A few months ago I started delivering my plugin updates via SSL. This worked fine for well maintained servers but as my user base grew over time, more and more error reports were filed that updates could not be retrieved. In most cases the reason was, that the SSL libraries on the server were outdated and could not verify the SSL certificate (sslverify).

As most users were on shared hosts and had little influence on the maintenance of SSL libraries, I decided to still deliver plugin updates via SSL but to disable the ssl verification. Not a beautiful solution, but needed as otherwise plugins wouldnt be delivered and as in the near future I am planning to redirect all http-requests to https which would cause issues if I didnt use https for the plugin-update-checker.

Just want to share with you how I did this (sorry for not sending a PR, thought, making an issue here would be easier):

With in the "public function __construct" I added two filters for disabling ssl verification, right after "$this->installHooks();":

add_filter( 'https_ssl_verify', '__return_false' );
add_filter( 'https_local_ssl_verify', '__return_false' );

In addition, within "public function requestInfo($queryArgs = array()){" I also added the wp_remote_get-option
'sslverify' => false,
so that with plugin checks also no SSL verification is done.

Perhaps this is also helpful for you!
best,

Robert

array_key_exists(): The first argument should be either a string or an integer on line 107

Warning array_key_exists(): The first argument should be either a string or an integer on line 104 in file /var/www/wp-content/plugins/biznip-popup/plugin-updates/plugin-update-checker.php

I print $this->checkPeriod;
and there is 2 value:

• 12
• 0.01

What is 0.01? From where?
PHP 5.5.3
Thx.

Issue with displaying plugin info for beta versions

Hi Yahnis,

got the following issue: I just uploaded a beta version (1.9-beta1) to my plugin update server at https://www.mapsmarker.com/updates/?action=get_metadata&slug=leaflet-maps-marker-pro-beta
As you can see from the URL, the plugin infos are retrieved correctly.

If I try to in contrast retrieve the plugin infos from within WordPress by going to Plugins and clicking on "View version 1.9-beta1 details" next to my plugin in the list, a popup with the following error opens:

An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums.

The plugininfo for non-beta-versions (e.g. 1.8) in contrast was displayed successfully when clicking on that link.

Do you know if there are any issues with displaying plugininfo when plugin version is not regular, like it is with beta-versions (1.9-beta1)? I turned on debugging and looked into the server PHP error logs but didnt find any hint on whats wrong here - so any help would be really appreciated!
best,

Robert

Bitbucket support

Hey @YahnisElsts, any plans to support Bitbucket (private repos) as well? Would be amazing!

Lovely plugin but getting PHP notice with PHP 7

Hello,

This is a must have plugin for all theme developers. Thanks for this. But with PHP 7, we are getting the following PHP warnings and notices

PHP Fatal error: Uncaught Error: Call to undefined method PluginUpdateChecker_3_0::getCronHookName() in /absolute-path/plugins/ac-shortcodes/files/updater/debug-bar-panel.php:79

#0 /absolute-path/plugins/debug-bar/debug-bar.php(244): PluginUpdateCheckerPanel->render()
#1 /absolute-path/wp-includes/plugin.php(524): Debug_Bar->render('')
#2 /absolute-path/wp-admin/admin-footer.php(72): do_action('admin_footer', '')

[ASK] Doing login authentication before upgrade the plugin

Hi there,

Is there a way to add some authentication before downloading new file update ? I would like when click button "update now" it will perform authentication first to the download server and once the authentication is valid then proceed the downloading.

Could you point me to some hooks in this class to achieve this if any ?

Nice class btw !!

Thanks

Bug since WordPress 4.6 [with fix]

I'm usind your code to update a custom plugin not in public WordPress repo. Since update to 4.6 every upgrade fails with curl error. This is caused by malformed url.

Here is the fix:
in https://github.com/YahnisElsts/plugin-update-checker/blob/master/plugin-update-checker.php#L1208
change:
$update->package = $this->download_url;
to:
$update->package = preg_replace('/([^:])(\/{2,})/', '$1/', $this->download_url);

Update Deleting Custom Files

It seems that when it downloads an updated version of the plugin, it will delete the old version's folder and put the new on in its place.

I have custom files stored in a sub-folder of the plugin folder. Those files are deleted when an update occurs. Is there some way to prevent files or folders that are not in the new version's zip file from being deleted?

EDIT: This may just be how WP handles plugin updates. If so, I'll have to rethink how I handle storing custom files.

Plugins Folder Name > based on meta download_url not slug

I am using php file to generate the .json formated meta. although it is working I can not figure out how to provide a specific name for the plugin folder. It seems it is based on the download_url value, stripped of URL and .zip extension.

For example:

http://domain.com/paht/to/zip/folder/zip-file-name.zip

would update the plugin into a folder called:
zip-file-name

but if we point the download link to:

http://domain.com/index.php?download_key=xzy&file_id=123

the folder name would be:
index.tmp

Any tips on how one might keep the dynamic download_url and force the plugin folder name to match that of the slug?

AddqueryArg without a filter

ok so my plugin before running the PucFactory::buildUpdateChecker is doing a check to see if its "legit" to run

Once the plugin is legit to run it runs the update checker code.
At the moment i got something like

$update_checker->addQueryArgFilter('my_function');

The thing is my_function does the exact same check that the PucFactory initialization "legit". I`m wondering if for example something like this might work and if not how to use the queryargfilter without the "callback" function

$update_checker->addQueryArgFilter( $my_array );

Notices and Fatal Error in Parsedown.php

I seem to get this error sometimes:

Notice: Array to string conversion in /vendor/yahnis-elsts/plugin-update-checker/vendor/Parsedown.php on line 1412

Notice: Undefined property: Parsedown::$Array in /vendor/yahnis-elsts/plugin-update-checker/vendor/Parsedown.php on line 1412

Fatal error: Uncaught Error: Function name must be a string in /vendor/yahnis-elsts/plugin-update-checker/vendor/Parsedown.php on line 1412

I've read here it might have something to do with PHP 7 but it happened on PHP 5.6 as well. Could you update the Parsedown script to the latest version?

Plugin updates from private repository not working

Hi!,
i follow the instructions and added the folder inside my plugin, i'm also calling the update file like this, but i doesn't work.

// Load the auto-update class
require 'plugin-update-checker/plugin-update-checker.php';
$className = PucFactory::getLatestClassVersion('PucGitHubChecker');
$myUpdateChecker = new $className(
'https://github.com/surgeonsadvisor/sa-photo-gallery',
FILE,
'master'
);
$myUpdateChecker->setAccessToken('######myaccesstoken######');

but i get this,

Any help will be appreciated.

Best Regards.

Possible update needed because of changes in core

See https://core.trac.wordpress.org/ticket/35301

Download URL.

First of all your work is awesome. Now I've two question,

1. JSON file. Right now your update checker use json file. Is there any way to make it use the json response ???
2. Right now the plugin update checker needs a "download_url" as a must. But I need to make like if anyone click on it it will redirect to my site where customer can download and manually install it. If this is not possible, could it be done that there will be no install button for my plugin. Just show the message that it has update. So client can came to my site and download the update manually ???

Thanks in advance.

using just the main file

If i want to bundle in plugins just plugin-update-checker.php and not use the entire directly it fails because for example require_once(dirname(__FILE__) . '/github-checker.php');

any way to use the main plugin file without the rest without commenting manually the not needed lines like the github one ?

Update via Github

Do you think you can implement a function that checks plugins on Github not based on the plugin version but on the Github commit hash?

And please keep up your good work. I really love this script.

Support for WordPress 4.2 - is-dismissible class

In WordPress 4.2 a new class was introduced to make the admin notices dismissible. The admin notice displayed after the plugin update check can be dismissed using this.

conflict with "rise" theme

Hi Yahnis,

I discovered that there is an issue when using your plugin-update-checker together with the "rise" theme from http://thrivethemes.com/, showing the following error in the dashboard:

Warning: The URL http://members.thrivethemes.com/plugin_versions/content_builder/update.json?checking_for_updates=1&installed_version=1.100.1 does not point to a valid plugin metadata file. WP HTTP error: Could not resolve host: http (Domain name not found) in /(wp-content/plugins/leaflet-maps-marker-pro/inc/class-plugin-update-checker.php on line 248

it seems that the GET parameter checking_for_updates is also used by the theme and causing this issue.

Perhaps renaming checking_for_updates to puc_checking_for_updates would solve this and any further related issues...
best,

Robert

Multisite usage

I'm using the update-checker on a multisite WP installation. If a plugin is not active on the 'main' site, but only on sub sites, the update code is never executed and updates ar not shown.
I've tried to install a plugin executing the update checks for all these plugins but that didn't work.

Any suggestions?

Thank for developing and maintaining this awesome checker!

eric

issue with several plugin-update-checkers and absolute plugin paths

Hi,

I am currently using v1.3.1 with the following integration code:

$run_PluginUpdateChecker = new PluginUpdateChecker(
$lmm_plugin_updater_url,
'leaflet-maps-marker-pro/leaflet-maps-marker.php',
'leaflet-maps-marker-pro',
'12',
'leafletmapsmarkerpro_pluginupdatechecker'
);

I now found that another plugin who uses your library v1.4 is causing my updates to fail, because the "Full path of the main plugin file" is now needed and I am using 'leaflet-maps-marker-pro/leaflet-maps-marker.php' because FILE doesnt work for me here.

The solution for me is to update to v1.5 and use 'plugin_dir_path( FILE ) . 'leaflet-maps-marker.php' instead - anyway I wanted you to know that there is a this breaking change (I guess introduced in v1.4) which can cause multiple instances of your library to fail.

Bad renaming when I updated from http:www/website/wp-admin/plugins.php

Hi,

When I update from http:www/website/wp-admin/plugins.php the plugin folder name is rename like
username-pluginrepository-0b6ff025db8a4578bea1fdf10ff80c7c35da5efe
and if I'll update from http://website//wp-admin/update-core.php the plugin folder is good and doesn't change.
What can I do for not change the plugin folder name when I update it?

Thanks a lot for your answer.

Best regards,

Salah.

issue if separate plugins use PUC 2.0 and 2.2 on the same WordPress site

Hi Yahnis,

I am using PUC 2.2 in my plugin Maps Marker Pro and a user reported an issue if the plugin UpDraftPlus is active, which uses PUC 2.0. When both plugins are active, the update check for UpDraftPlus shows the following errors when using the debug bar actions "request info" for metadata url:

Warning: The URL http://updraftplus.com/plugin-info/?installed_version=2.11.26.0&udm_action=updateinfo&sid=REPLACED&su=REPLACED&sn=REPLACED&slug=updraftplus&e=REPLACED&si=REPLACED does not point to a valid plugin metadata file. HTTP response code is 404 (expected: 200) in /wp-content/plugins/leaflet-maps-marker-pro/inc/class-plugin-update-checker.php on line 255
Failed to retrieve plugin info from the metadata URL.

If I deactivate Maps Marker Pro / PUC 2.2, the "request info" for metadata url works fine. Do you have any idea what might be causing this or how this could be solved? I guessed as our plugins use different PUC versions, there might not be any conflict?
thx for any help!
best,

Robert

still keep "Updating..." when I click the "update now" button

Ho, I have applied it in my plugin code and I am using github to host my private wp plugin. when I have pushed some updates in my repo in github, in my wp admin I have seen a new update for the plugin but when I tried to click the "update now" button, it stays and displays "Updating.." for hours.. and didn't do the update of the code or it didn't done..

any idea about my case? thanks in advance..

what I have done is this only that I have put in my plugin code:

require 'plugin-update-checker/plugin-update-checker.php';
$className = PucFactory::getLatestClassVersion('PucGitHubChecker');
$myUpdateChecker = new $className(
'https://github.com/user-name/plugin-repo-name/',
FILE,
'master'
);

Does not work with WP 4.0

The plugin gets deleted after all updating is completed.

Works as expected with WP 3.9.2, but once updated to WP 4.0 and an update is attempted all plugin files are deleted after update.

sections formattings

how to format the sections?
I'm not able to style my changelog with html (< br >) or \n.
I'm checking out the official redame.txt from wordpress (= title =)
http://wordpress.org/extend/plugins/about/readme.txt

but this didn't work, too. My changelog looks like a big textblock.

Hangs on "Updating..." even when plugin was updated succesfully

I am doing some tests and encountered a small issue. When clicking the "update now" link on the wp-admin/plugins.php page after a new update is available, entering the ftp details and clicking proceed, wp says "Updating..." and shows the rotating icon, and it never finish. But when I open the site again, the plugin was updated successfully. Could it be a problem with my setup? Updating from wp-admin/update-core.php shows no errors and it updates fine.

update: Nevermind, now it works fine, not sure what happened.

Align Shorter timeout scenario's with WP update.php

May want to consider including a few extra cases for the shorter timeout scenarios to align with the current WP plugin update class...

    case 'upgrader_process_complete' :
        $timeout = 0;
        break;
    case 'load-update-core.php' :
        $timeout = MINUTE_IN_SECONDS;
        break;
    case 'load-plugins.php' :
    case 'load-update.php' :
        $timeout = HOUR_IN_SECONDS;
        break;

OR

in_array( current_filter(), array( 'load-plugins.php', 'load-update.php', 'load-update-core.php' ) )

actions:
add_action( 'load-plugins.php', 'wp_update_plugins' );
add_action( 'load-update.php', 'wp_update_plugins' );
add_action( 'load-update-core.php', 'wp_update_plugins' );
add_action( 'admin_init', '_maybe_update_plugins' );
add_action( 'wp_update_plugins', 'wp_update_plugins' );
add_action( 'upgrader_process_complete', 'wp_update_plugins', 10, 0 );

https://github.com/WordPress/WordPress/blob/b0a2416040f24dcf0f50b3520dfc798de43a904a/wp-includes/update.php

(minor) Plugin update count incorrect

It seems that this is causing the plugin update count on the menu items:

• Dashboard->Updates
• Plugins

To show 1 in a red circle, despite all plugins being up to date.

WP 4.5.3
Fresh install

Updating from GitHub adds an undesired suffix to the plugin folder name.

If we use a GitHub zip file as download_url, e.g., https://github.com/user/git-name/archive/master.zip, the updated plugin receives an extra folder suffix: /wp-content/plugins/plugin-slug-master/.

I made a hack to deal with this, but wonder if there'd be a better alternative...

add_filter('upgrader_source_selection', 'ultra_hack', 1, 3);
function ultra_hack( $source, $remote_source, $thiz )
{
    if( not_my_plugin() )
        return $source;

    $path_parts = pathinfo($source);
    $newsource = trailingslashit($path_parts['dirname']). trailingslashit('plugin-slug');
    rename($source, $newsource);
    return $newsource;
}

Multiple plugins

Using your update checker (and server) for all of my plugins.

Unfortunately it doesn't work when 2 plugins are ready to be updated. After the first plugin is updated correctly, the second plugin seems to take the data from the first and will be removed from wordpress after the update, due to the fact, that the "original" plugin file (and all other files) are overwritten by the first one.

Any idea how to prevent this?

Wordpress 4.2 plugin update from the Plugins Screen

Wordpress 4.2 introduced a new update mechanism from the plugins page "update now" link alongside each plugin. I'm seeing "Update Failed" after clicking the "Update Now" link from wp-admin/plugins.php. Seems to work fine from Dashboard->Updates. Also, if you use the checkbox via bulk actions to update from plugins.php that works too. PHP error logs appear to be clean.

From 4.2 Codex: "More intuitive plugin update and install from the Plugins Screen. Goodbye boring loading screen, hello smooth and simple plugin updates. Click Update Now and watch the magic happen."

wp.ajax.post( 'update-plugin', data )
.done( wp.updates.updateSuccess )
.fail( wp.updates.updateError );

Can this work with themes too?

Just wondering if there is anything newer than the 2011 blog post.

Version 3.0 backward incompatible changes

I have noticed a commit message saying that version 3 is not backward compatible. However, I can't find changes making it so. Would you mind to point me to them? Is it something related to the update server response fields?

Also, is it expected to be safe to use v.3 in a plugin while there is another plugin using an older version, both running on the same WordPress instance?

Language packs updating... ?

Hi Yahnis,

Do you have any plans to write a class to support language pack updating from non-wordpress.org sources, for when WordPress starts to support downloading language packs separately from the main plugin?

Some background:
https://make.wordpress.org/plugins/2015/09/01/plugin-translations-on-wordpress-org/

I asked the question "Is there some documentation somewhere on the hooks/filters that WP will be using to download translation packs? As a developer of third-party plugins (i.e. ones not hosted at wordpress.org), I want to see how I can hook in so that WP can download translation packs for third-party plugins so that they don’t need bundling." ... and got pointed to this bit of code as relevant: https://core.trac.wordpress.org/browser/branches/4.3/src/wp-admin/includes/class-wp-upgrader.php#L1730

David

PHP notice Undefined index: every12hours

Hi

I'm getting this error:
PHP Notice: Undefined index: every12hours in /media/websites/sandbox.dev/wp-includes/cron.php on line 103

It seems like the custom schedules aren't being registered?

Mutisite Check when Plugin is not network activated

Hey there,

Just started using this within in a plugin I'm developing and it works great when the plugin is on a single site or network activated.

However, and I'm not sure if this is an issue or something I'm missing, when the plugin is activated on a single site within a multisite install, there doesn't seem to be a way to trigger the check and update of the plugin. Is there a hook or something that can be called to make this happen?

Thanks and let me know if you need further details!

Regards,
Justin

gzinflate data error

Hi Yahnis,

since a while I keep on getting the attached error - happens once after login and then it is gone; have you experienced this one before?

WARNING: wp-includes/class-http.php:2108 - gzinflate(): data error
do_action('admin_init'), call_user_func_array, PluginUpdateChecker_1_6->maybeCheckForUpdates, PluginUpdateChecker_1_6->checkForUpdates, PluginUpdateChecker_1_6->requestUpdate, PluginUpdateChecker_1_6->requestInfo, wp_remote_get, WP_Http->get, WP_Http->request, WP_Http->_dispatch_request, WP_Http_Curl->request, WP_Http_Encoding::decompress, gzinflate

There is a related WP core trac ticket at https://core.trac.wordpress.org/ticket/22952 - anyway I am not sure if this is caused by my server configuration & your library. Just wanted you to know - if it is not related, please close this issue.
thx,

Robert

SSL issue

The plugin does not read the metadata correctly and comes back with nothing when SSL is turned on for the server. So when somebody checks for updates it says there is no updates available. However I know that there is and tried using static JSON files. I checked using the debug bar and for SSL it said there was a SSL v3 handshake error. The whole time I could go to the URL in the browser and see the JSON file that was generated, but for some reason the update checker could not read the file as a JSON file, I checked that the headers were correct in Chrome developer tools as well.