WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 2 years ago

Last modified 2 years ago

#11227 closed feature request (wontfix)

Ability to discard plugin upgrade automatically

Reported by: arena Owned by: westi
Milestone: Priority: normal
Severity: normal Version: 2.9
Component: Plugins Keywords: has-patch
Focuses: Cc:

Description

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."

Attachments (1)

#11227.patch (3.2 KB) - added by arena 4 years ago.
patch

Download all attachments as: .zip

Change History (17)

comment:1 arena4 years ago

  • Keywords has-patch tested added

comment:2 Denis-de-Bernardy4 years ago

  • Milestone 2.9 deleted
  • Resolution set to worksforme
  • Status changed from new to closed

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.

comment:3 arena4 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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

comment:4 arena4 years ago

  • Milestone set to 2.9

comment:5 janeforshort4 years ago

  • Milestone changed from 2.9 to Future Release

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

arena4 years ago

patch

comment:7 arena4 years ago

  • Keywords tested removed

I upgraded patch from 2.9

New plugin optional tags are :

Upgrade Check: none
Upgrade Text: your text here

comment:8 arena4 years ago

  • Milestone changed from Future Release to 2.9.1

comment:9 dd324 years ago

  • Milestone changed from 2.9.1 to Future Release
  • Priority changed from high to normal
  • Severity changed from major to normal

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.

comment:10 hakre4 years ago

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.

comment:11 nacin4 years ago

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

comment:12 dd324 years ago

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?

comment:13 volcanicpixels3 years ago

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.

comment:14 MattyRob2 years ago

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?

comment:15 nacin2 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

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).

comment:16 MattyRob2 years ago

I'll follow up on 13928 - thanks Nacin.

Note: See TracTickets for help on using tickets.