"Install from URL" for themes and plugins

[nacin]

We currently have a way to upload a plugin ZIP. We should make it so you can sideload a ZIP as well, via a URL. Initial patch, which is very rough, seems to do this successfully. Needs eyes.

Additionally, the URL should be sent to ​http://api.wordpress.org/themes/malware-check/1.0/ (which I'll put together) so we can maintain a blacklist of spam sites that offer encoded junk.

[hakre]

Only a rought review: There is an "@since 3.1.0" left in the patch.

Is it possible to up-/down-grade the plugins/themes with that method?

Related: #9757

[dd32]

This is specifically for installations. Once the plugin is installed, it can handle the upgrade process internally (ie. it has access to the WordPress upgrade functions)

[nacin]

Ah, I changed 2.8.0 to 3.1.0. Of course should say 3.2.0.

[markjaquith]

Need to allow the URL field to be pre-populated with a GET request, so they don't have to copy/paste.

[hakre]

Replying to markjaquith:

Need to allow the URL field to be pre-populated with a GET request, so they don't have to copy/paste.

That's nice.

[nacin]

​http://api.wordpress.org/themes/malware-check/1.0/ now works.

Accepts $_GET['url']. Response codes:

• -1 = it's a malformed URL. Ideally we should never send this to the API.
• 0 = it's a blacklisted URL. This is currently populated with a few domains that offer spam/malware themes.
• 1 = it passes the checks.

[dd32]

Replying to markjaquith:

Need to allow the URL field to be pre-populated with a GET request, so they don't have to copy/paste.

How do we want to do that?

• Accessing the url such as: ​http://dd32.id.au/wp-admin/plugin-install.php?tab=url&package=http%3A%2F%2Fdd32.id.au%2Ftest.zip
• Or ​http://dd32.id.au/?install-plugin=http%3A%2F%2Fdd32.id.au%2Ftest.zip (redirect to above url)

In the case where someone provides the url via a GET parameter, do we want to have some form of alert on the page "Site XYZ.com has pre-filled this for you" (ie. Referrer set)

​http://api.wordpress.org/themes/malware-check/1.0/ now works.

Perhaps that should be made more generic, ie. not just for themes, but plugins as well. I realise it'll work for either, but for naming consistency it might be good to have a neutral url?

What type of error are we going to display when it fails the malware check, I assume we're going to block installation through that interface.. It might be an idea to link it to a codex page explaining it.

If we're adding define the url via $_GET, perhaps we should pass the referrer to malware check as well?

[nacin]

Replying to dd32:

Perhaps that should be made more generic, ie. not just for themes, but plugins as well. I realise it'll work for either, but for naming consistency it might be good to have a neutral url?

Probably. Due to the folder structure of api.wp.org, I simply chose /themes/, with the expectation that it would simply be used for plugins as well. We could create a new top-level structure if we feel it's appropriate.

If we're adding define the url via $_GET, perhaps we should pass the referrer to malware check as well?

Sure, we can do that. I'll update it to also check against $_GET['referer'] if passed, that sound good? We'd need to properly relay the referrer through wp-login.php though.

[dd32]

Probably. Due to the folder structure of api.wp.org, I simply chose /themes/

There's no harm in leaving it there really, As long as we document that it supports plugin and theme url's. The only other location could maybe be core, as that's a bit more generic for api's utilised by core (eg. the zoneinfo ones)

Sure, we can do that. I'll update it to also check against $_GETreferer? if passed, that sound good? We'd need to properly relay the referrer through wp-login.php though.

Will have to look into passing it through properly without allowing it to be modified.. I'll attach a patch combining your above patch, and the malware API shortly for a quick once over for the malware implementation.

[dd32]

attachment 16923.patch added

• Initial integration of the malware API.

[westi]

Replying to nacin:

​http://api.wordpress.org/themes/malware-check/1.0/ now works.

Accepts $_GET['url']. Response codes:

• -1 = it's a malformed URL. Ideally we should never send this to the API.
• 0 = it's a blacklisted URL. This is currently populated with a few domains that offer spam/malware themes.
• 1 = it passes the checks.

Before we start using this we should relocate it.

Either under /core/ or just as /malware-check/1.0/

[swissspidy]

What about an 'Install now' link in the .org plugin/theme directory? The user could type in his blog URL (or maybe it could be grabbed from his profile) and the plugin gets installed. This feature has often be requested by users and could be easily integrated, I think.

[ocean90]

Replying to swissspidy:

What about an 'Install now' link in the .org plugin/theme directory? The user could type in his blog URL (or maybe it could be grabbed from his profile) and the plugin gets installed. This feature has often be requested by users and could be easily integrated, I think.

See also this page: ​http://coveredwebservices.com/wp-plugin-install/

[nacin]

I've moved malware-check to ​http://api.wordpress.org/core/malware-check/1.0/.

The patch should not prevent installation when the HTTP request to malware-check fails. The only thing that should prevent is when body === '0'. Anything else should let it pass through.

Moving to 3.3 early as this one missed the boat.

[nacin]

Note: We also need to update the string in install_dashboard()... And make it properly link to tab=upload and tab=url.

[nacin]

Wontfix'd in favor of #18289.