Ability to discard plugin upgrade automatically

[arena]

Adding an optional specific tag in plugin headers

/*
Plugin Name: myplugin
Version: 1.1
...
AutoUpdate: Your text here.
*/

will change the following message :

"There is a new version of myplugin available. View version 1.1 Details or upgrade automatically."

in

"There is a new version of myplugin available. Your text here."

[Denis-de-Bernardy]

You can do this already by filtering the plugin out on the transient_update_plugins hook, and using the after_plugin_row (or whatever it's called) to show anything you want.

[arena]

Sorry Denis, i re open it because your workaround only applies if plugin activated !!!!

[janeforshort]

Punting. We're already in feature freeze, and beta release.

[arena]

see my comment here :

​http://markjaquith.wordpress.com/2009/12/14/excluding-your-plugin-or-theme-from-update-checks/

[arena]

patch

[arena]

I upgraded patch from 2.9

New plugin optional tags are :

Upgrade Check: none
Upgrade Text: your text here

[dd32]

Point releases are for Defects only. New feature requests can stay in Future release until a dev agree's with it.

Personally, I'm -1 for this.. If a plugin exists within the .org repository, it should support the autoupgrades.

Also, resetting priority/severity due to it being a feature request.. that IMO, isnt very high at all.

[hakre]

How about to exclude all plugins that are deactivated from the update check? I mean, if they aren't updated, there is no need to update them.

And if they are active, the hooks do apply. I think that's fair.

[nacin]

Not sure if I understand that right, but I don't see why a deactivated plugin can't also be updated?

[dd32]

How about to exclude all plugins that are deactivated from the update check? I mean, if they aren't updated, there is no need to update them.

Many plugins will be deactivated as their blog wasnt stable with it activated, or broke something. You need to be able to update deactivated plugins.

Doesnt WordPress somehow support a changelog feature before agree'ing to updateing, or something like that? Maybe it was just a thought that never got implemented?

[volcanicpixels]

To collate everything here:

The issue is that third-party plugins are still checked for updates against the wordpress repository even if they aren't on there. Some people object over sensitive data contained within the plugin header is being sent to wordpress.org. Even worse is when a plugin of the same name exists in the repository and wordpress issues an update warning which is wrong. Mark Jaquith's work around ( ​http://markjaquith.wordpress.com/2009/12/14/excluding-your-plugin-or-theme-from-update-checks/ ) doesn't work if the plugin is deactivated and therefore support for an "auto-update" header tag would be nice.

[MattyRob]

Would an alternative solutions to this be a combination of two things:

First, why are plugin authors putting sensitive information in plugin header details in the first place - if it's that sensitive, don't put it in the header - maybe comment it further down the code.

Second, why not compare more information in the update check beyond the version number? How about comparing the Plugin URL and name for example?

[nacin]

Second, why not compare more information in the update check beyond the version number? How about comparing the Plugin URL and name for example?

It does. It uses (at a minimum) the plugin URL, author, name, and slug to try to find the best possible match for the plugin. Unfortunately any heuristics on this can result in false positives. See #13928 for more.

Otherwise, closing this as wontfix. There's already an "Upgrade Notice" you can specify in the readme that will then be shown in the same spot that the OP requests (while not replacing text).

[MattyRob]

I'll follow up on 13928 - thanks Nacin.