[wp-trac] [WordPress Trac] #28660: A mechanism for third-party plugins to avoid being replaced by wordpress.org plugins whilst inactive

[WordPress Trac]

#28660: A mechanism for third-party plugins to avoid being replaced by
wordpress.org plugins whilst inactive
---------------------------+-----------------------------
 Reporter:  DavidAnderson  |      Owner:
     Type:  defect (bug)   |     Status:  new
 Priority:  normal         |  Milestone:  Awaiting Review
Component:  Plugins        |    Version:  trunk
 Severity:  normal         |   Keywords:
  Focuses:                 |
---------------------------+-----------------------------
 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.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/28660>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform