search

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.
MIT License
2.27k stars 411 forks source link

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

Open jessuppi opened 3 weeks ago

jessuppi commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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!