A mechanism for third-party plugins to avoid being replaced by wordpress.org plugins whilst inactive

[DavidAnderson]

WordPress core has a built-in link to the wordpress.org plugins repository. wp_update_plugins() in wp-includes/update.php checks ​http://api.wordpress.org/plugins/update-check/1.1/ for every slug which it finds installed.

Third-party plugins can over-ride this via a filter; but crucially, this requires the 3rd-party plugin to be active. For an inactive plugin, only the api.wordpress.org result will be obtained. If there is a plugin in the wordpress.org repository with the same slug, then this has bad results.

The curators of the wordpress.org repository try to avoid this, by not accepting new plugins with the same slug as known 3rd party plugins. However, this both involves issues of human error (to enumerate all the 3rd party plugins that might be out there would require omniscience), race conditions and future knowledge (who knows what plugin a 3rd party developer is working on and might release 6 weeks from now?). Potentially, this issue could break sites. (e.g. Someone might have a bespoke/private plugin that a developer built 3 years ago on their site. One day, a new update might appear via a new, completely different plugin in wordpress.org... and the unwitting site owner might update to it). (Also, I have heard from many people who believe that it is 'best practice' to update plugins whilst they are inactive...)

An optimum solution would be if an installed plugin could indicate, via its header, that wordpress.org should not be asked for potential updates for that plugin. By using the header, this flag can be used even when inactive. Since it would need to be explicitly/intentionally set by a developer, it could not cause unexpected issues.

The short patch attached adds a new plugin header, WordPressOrgUpdate. If this is present and set to 0 or false, then it will not include the slug in the list queried at api.wordpress.org. Thus it prevents unexpected wordpress.org updates when the plugin developer has indicated that they should not happen.

[DavidAnderson]

Provide header to allow plugin developer to indicate plugin should not be updated via wordpress.org

[jdgrimes]

Related: #25314, #22377, #13928

I think maybe this is a duplicate of #23318

[DavidAnderson]

Probably this one can be closed... in #23318 I've supplied a new patch based on a suggestion there, which is more flexible than the one here - but without adding any extra complications.

[DavidAnderson]

Implements "Update Service" header (default: wordpressorg) and omits plugins where this is set to something other than wordpressorg from the API call to api.wordpress.org (see discussion in #23318 for rationale)

[DavidAnderson]

Replying to DavidAnderson:

Probably this one can be closed... in #23318 I've supplied a new patch based on a suggestion there, which is more flexible than the one here - but without adding any extra complications.

(Update: in fact #23318 got closed instead, and discussion has come here).

[DavidAnderson]

Would love to see some feedback or action on this ticket... it keeps coming up as a real-world issue for me.

[helen]

#23318 is not closed, closing this as a dupe.