Skip to content

Add support for a header which causes WordPress.org not to offer an update for an item - #950

Open
dd32 wants to merge 10 commits into
WordPress:masterfrom
dd32:add/14179-update-filters
Open

dd32 wants to merge 10 commits into
WordPress:masterfrom
dd32:add/14179-update-filters

Conversation

@dd32

@dd32 dd32 commented Jan 28, 2021 •

Copy link
Copy Markdown
Member

This PR introduces a header that the WordPress.org plugins api will ignore for the purposes of plugin updates.
This PR doesn't touch themes, as this is proof-of-concept.

The Update URI field should:

  • Be a URI, eg: https://wordpress.org/plugins/example-plugin, or https://dd32.id.au/plugins/example-plugin
  • Have a unique hostname
  • Must pass through esc_url_raw() so custom scheme's are out. github://someone/something is not valid.
  • https://some-url-that-will-never-exist-at-all-ever or my-custom-plugin-name are valid.
  • Update URI: false is valid, and unless code is handling the 'false' hostname, the plugin will never get an update notification.

If present, the WordPress.org plugins API will currently not return a result for it, UNLESS, it matches the following format:

Included, is a filter which 3rd party plugins can use to offer updates for a given hostname (Yes, it's tied to a hostname), and they can return their plugin data blob and it should just work natively.

There's a few other small changes around WordPress not expecting that the slug field is always set, but that's the only real change to the rest of WordPress needed.

Included is also an example plugin, whose Name + Author indicate that it's the WordPress.org Hello Dolly plugin.
When installed on...

  • WordPress 5.6: Offers to update to the Hello Dolly plugin.
  • This PR, plugin deactivated: No update offered, as no plugin is handling the updates for it.
  • This PR, plugin activated: Offers to update the plugin using the hard-coded details from the plugin (This should be pulled from an API)

Trac ticket: https://core.trac.wordpress.org/ticket/14179


This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

@afragen

afragen commented Feb 8, 2021

Copy link
Copy Markdown
Member

@dd32 does this actually allow updates to plugins from 3rd party hosts?

If yes, is it really useful given the restrictions in Guideline 8?

https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

Or am I misunderstanding it's utility outside of not updating a plugin with the same slug that is different from a plugin in the plugin directory?

Comment thread src/wp-admin/includes/plugin.php Outdated
@abuyoyo

abuyoyo commented Feb 12, 2021

Copy link
Copy Markdown

Is this PR more in line with what's suggested here?
https://core.trac.wordpress.org/ticket/32101
Simply a header for a plugin to self-identify as non-wp.org repo?

@dd32

dd32 commented Feb 12, 2021 •

Copy link
Copy Markdown
Member Author

@dd32 does this actually allow updates to plugins from 3rd party hosts?

It does, but only if there's other code on the site to handle it. For example, a plugin can register itself as handling updates for github.com URI's.

If yes, is it really useful given the restrictions in Guideline 8?
https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

Since this should never be used by a WordPress.org hosted plugin, the guidelines aren't relevant.

Or am I misunderstanding it's utility outside of not updating a plugin with the same slug that is different from a plugin in the plugin directory?

The utility is that this is an abstracted API that allows two things:

  1. A plugin to declare a URI/string that if set, WordPress.org update API's ignores the plugin.
  2. Code running on the site, can use that headers hostname/data to offer an update for the the plugin to be stored into the update transient, without having to jump through hoops such as overriding the transient / checking too often / etc.

Part two is mostly already solved, as there exist libraries and plugins which can do it now safely.
Part one is the useful part, as you don't have to have the library/helper plugin enabled to take advantage of it.

@wayheming

Copy link
Copy Markdown

hi @dd32
Thanks for your work. Tell me your code will work for themes as well? and when is it planned to be added to WP?

@mrleemon

mrleemon commented Apr 19, 2022 •

Copy link
Copy Markdown

I hope this patch gets into WP 6.0 for themes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants