WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#28660 closed defect (bug) (duplicate)

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

Reported by: DavidAnderson Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.0
Component: Plugins Keywords: has-patch
Focuses: Cc:
PR Number:

Description

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.

Attachments (2)

disable-wporg-updates.txt (1.9 KB) - added by DavidAnderson 5 years ago.
Provide header to allow plugin developer to indicate plugin should not be updated via wordpress.org
update-service.diff (1.9 KB) - added by DavidAnderson 5 years ago.
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)

Download all attachments as: .zip

Change History (8)

@DavidAnderson
5 years ago

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

#1 @DavidAnderson
5 years ago

  • Keywords has-patch added

#2 @jdgrimes
5 years ago

Related: #25314, #22377, #13928

I think maybe this is a duplicate of #23318

#3 follow-up: @DavidAnderson
5 years ago

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
5 years ago

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)

#4 in reply to: ↑ 3 @DavidAnderson
5 years ago

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

#5 @DavidAnderson
5 years ago

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

#6 @helen
5 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.