Selectively disable plugin update requests

[bobbingwide]

For a variety of reasons there may be some plugins for which you neither want updates to be checked nor applied. Some of these reasons are:

1. You need to stick with a particular version until another version has been updated
2. The plugin is installed as a symlinked version

The requirement is to support the disabling of plugin updates on a plugin by plugin basis.

[bobbingwide]

Note: When checking to see if a plugin is a symlinked plugin you can't rely on the global $wp_plugin_paths table since this is only populated for active plugins.

So when hooking into 'pre_current_active_plugins' which lists all plugins, whether or not activated you have to find another way to determine if the plugin is symlinked.

[bobbingwide]

Messages about symlinked plugins are being displayed even when the plugin is at the latest version.
We should change the code to compare "new_version" with "Version" and issue the message when they're different.

[bobbingwide]

We need to produce the messages in WPMS as well.
/wp-admin/network/update-core.php

[bobbingwide]

The logic should also cater for plugins which are clones of Git repositories.
This is in addition to detecting plugins which are symlinks of Git repositories.

[bobbingwide]

We need to prevent updates from /wp-admin/update-core.php

[bobbingwide]

In order to prevent updates in wp-admin/update-core.php we'll need to see how we can intercept the processing for the following hooks

[hook pre_site_transient_update_plugins filter 2 10 0]
[hook pre_site_option__site_transient_update_plugins filter 4 14 0]
[hook default_site_option__site_transient_update_plugins filter 3 14 0]
[hook pre_option__site_transient_update_plugins filter 3 16 0]
[hook option__site_transient_update_plugins filter 2 16 0]
[hook site_option__site_transient_update_plugins filter 3 14 0]
[hook site_transient_update_plugins filter 2 10 1]

That means looking at where they're called and what they return.

The challenge is to be able to report where updates are available, but we don't recommend updating because the plugins symlinked or Gitted, and to remove the plugins from the list when we can't tell them it's not a good idea.

OK. I've written some code in the libs/class-oik-update.php shared library file. It hooks into the site_transient_update_plugins filter. It removes any symlinked or Git plugins from the update list when the current page is update-core.

I now need to test this without breaking anything. So I need to commit the changes, install somewhere safe and try it out. That means creating a new version of oik ( and oik-bwtrace ) with the updates. Should be interesting.

[bobbingwide]

OK, I've tested it. The logic only kicks in when a plugin has called oik_register_plugin_server. This is a function used in plugins delivered from oik-plugins.com.
I'm going to close the issue for now. I may revisit it if I think it's necessary to indicate to the user that "some plugins have been ignored during the creation of this list".