Easiest way to identify plugins that use plugin-updater-checker

[jessuppi]

Hello, thanks for this awesome project.

I'm currently working on RepoMan which is an MU plugin that extends the native WP plugin search to include plugins from GitHub that can be installed... it also prevents WordPress.org from sending "update" notices on any plugins that RepoMan detects already support the Git Updater software by looking for string GitHub Plugin URI in the main file:

https://github.com/littlebizzy/repoman

One of your users asked if we could support your software also.

Do you have a recommendation on the easiest way for RepoMan to scan installed plugins in WordPress and identify which plugins support plugin-update-checker that is hopefully lightweight and scalable?

For example, looking for string PluginUpdateChecker in the main file should that be enough? Cheers!

[YahnisElsts]

I don't think there's a reliable way to do that. Looking for a specific string like the YahnisElsts\PluginUpdateChecker\ namespace in the main plugin file will work in some cases, but the code that initialises the update checker doesn't have to be in the main file. Technically, the developer can put it anywhere. PUC doesn't require it to be in a specific location.

For plugins that use Composer, you could look for a /vendor/plugin-update-checker/ subdirectory. But again, the directory doesn't necessarily have to be named vendor (though I think that's the most common option), and it doesn't have to be in the plugin's root directory.

For active plugins, you could look at callbacks attached to the site_transient_update_plugins hook, get the update checker object from the callback, and then use $updateChecker->getAbsolutePath() to identify the plugin that the callback belongs to. However, this is more complex, and wouldn't work for inactive plugins.

[jessuppi]

Thanks for your quick response @YahnisElsts

It sounds like maybe this would be unreliable and/or require scanning the entire plugin tree, which would probably cause performance issues based on my previous tests doing that.

In the future if you end up having a narrower way to check the plugin main files, I'd love to know. Thanks!

[DavidAnderson684]

@jessuppi If your goal is to exclude any plugins that aren't from wordpress.org, then see this fragment: #578 (comment) . (The code there isn't restricted to use of any particular updates-checking class).

[jessuppi]

Thanks @DavidAnderson684

What if someone installs a third party WordPress plugin that has the same namespace as a plugin from WP.org would it potentially get skipped using your filter? Wouldn't the calls to api.wordpress.org show up in those cases?

[DavidAnderson684]

@jessuppi Plugins in the wordpress.org plugin directory are forbidden by the directory to include an "UpdateURI" header pointing elsewhere.

[jessuppi]

@DavidAnderson684 But couldn't your entire code be reduced to simply checking for an Update URI header line, at least for this purpose? The issue being that many third-party plugins still do not use that.

[DavidAnderson684]

It is true that the code won't detect any plugin that neglects to use that standard header. The best way to fix that is to inform any plugin authors to add it. And, of course, you can edit the code snippet to also include any plugins that include the Github header, if that's relevant.

[jessuppi]

Good idea @DavidAnderson684 ... this is now added to RepoMan 1.8.0:

• any plugins with Update URI string in the main file will be blocked from WP.org overwrites
• the plugin-update-checker namespace is also hardcode blocked from overwrites

https://github.com/littlebizzy/repoman

Progress at least! A bit off-topic, sorry @YahnisElsts but hopefully it proves useful as a public note for now...