Add ability to hijack plugin install/upgrade downloads

[rmccue]

Problem

Many plugins have their own updating system. For paid plugins, this can involve
sending authentication/authorization headers. At the moment, to implement this,
certain parts of the plugin upgrader system have to be duplicated to replace
parts of the system, such as the downloading method. In addition, the package
download URL has to be a valid URL. Some systems may wish to use alternate URLs
apart from HTTP/FTP-based URLs.

The code for this is shared between the single plugin upgrader and the bulk
plugin upgrader. While the upgrader class can be replaced fairly easily with
existing filters for single plugins, it's not possible to do this for the bulk
upgrader (especially when multiple systems want to do this), requiring falling
back to a low-level filter like http_request_args, ensuring that one only
hooks in after the admin_action_update-selected action has failed.

Solution

Add a filter to hijack the download system before it can act at all. This allows
replacing the entire downloading system, with the only requirement being to
return a valid package filename. This filter will work across both the single
and bulk upgraders, ensuring consistency in the approach.

Patch attached. Related: #22377, #22129

[rmccue]

Add filter to WP_Upgrader::download_package()

[rmccue]

Trivial example of how to implement it:

<?php

function test_new_hook($return, $package, $upgrader) {
	if ($return !== false) {
		return $return;
	}

	$package = add_query_arg('key', 'token', $package);

	$upgrader->skin->feedback('downloading_package', $package);

	$download_file = download_url($package);

	if ( is_wp_error($download_file) )
		return new WP_Error('download_failed', $upgrader->strings['download_failed'], $download_file->get_error_message());

	return $download_file;
}

add_filter('wp_upgrader_pre_download', 'test_new_hook', 10, 3);

[scribu]

We should try to keep some consistency between hook names.

First, there's general upgrader hooks:

'upgrader_pre_install'
'upgrader_post_install'
'upgrader_source_selection'
'upgrader_clear_destination'

And then there's plugin hooks:

'install_plugin_complete_actions'
'update_plugin_complete_actions'
'update_bulk_plugins_complete_actions'

And theme hooks:

'install_theme_complete_actions'
'update_theme_complete_actions'
'update_bulk_theme_complete_actions'

So, a better hook name would be 'upgrader_pre_download'.

[rmccue]

More consistent filter name

[rmccue]

Replying to scribu:

We should try to keep some consistency between hook names.

[...]

So, a better hook name would be 'upgrader_pre_download'.

Whoops, missed that. Updated now.

[nacin]

This is not 3.5 material.

[dd32]

Needs filter documentation, moving for review

[DrewAPicture]

+ docs

[DrewAPicture]

22378.3.diff​ adds a docblock for the upgrader_pre_download filter hook.

Side note: We'll need to do a functional docs pass through this whole class in a separate ticket.

[rmccue]

If I may be so bold...

[dd32]

In 25427:

Upgrader: Allow plugins to short-circuit the package download. Props rmccue and DrewAPicture. Fixes #22378

[farinspace]

my apologies if I am not understanding this correctly ... doesn't the plugin still need to be activated in order to use the hook, if the plugin is deactivated, wordpress will always check the plugins repo and if a plugin of the same name exists will return that data?

I think wordpress would be more open if a plugin author could specify their own update URI, this would avoid namespace grabs just for the sole purpose of not having the repo interfere with and external updater .. see ticket #25314

[dd32]

doesn't the plugin still need to be activated in order to use the hook,

Yes, This is for cases where a plugin is offering a non-wordpress.org update location. This is not currently supported by WordPress in any way, except that plugins can, and do, bring such things to the table. So yes, that plugin WOULD have to be active for this to be of any use to the plugin.

[farinspace]

Would the ability for wordpress to forgo an update check for a specific "installed" but deactivated plugin sound better .. something as simple as a plugin comment header parameter .. "UpdateURI" plugin authors provide a URI but it would be used as a boolean mostly, asking wordpress to skip an update check, which then would give the plugin a chance to hook in after activation .. I just want to make a reasonable request for such a feature and understand all implications.

[dd32]

Replying to farinspace:

Would the ability for wordpress to forgo an update check for a specific "installed" but deactivated plugin sound better ..

This ticket is not really related to your request in the least, I can't find the ticket reference for it, but short story is that there are no current plans for what you're requesting.

[SergeyBiryukov]

Replying to dd32:

This ticket is not really related to your request in the least, I can't find the ticket reference for it, but short story is that there are no current plans for what you're requesting.

#22129 appears to be related (and its duplicate #25314).