WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#16923 closed task (blessed) (wontfix)

"Install from URL" for themes and plugins

Reported by: nacin Owned by: nacin
Milestone: Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords:
Focuses: Cc:

Description

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.

Attachments (2)

16923.diff (3.4 KB) - added by nacin 3 years ago.
16923.patch (8.0 KB) - added by dd32 3 years ago.

Download all attachments as: .zip

Change History (26)

nacin3 years ago

comment:1 nacin3 years ago

  • Keywords has-patch added

comment:2 hakre3 years ago

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

comment:3 dd323 years ago

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)

comment:4 nacin3 years ago

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

comment:5 follow-up: markjaquith3 years ago

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

comment:6 in reply to: ↑ 5 hakre3 years ago

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.

comment:7 follow-up: nacin3 years ago

  • Keywords needs-patch added; has-patch removed

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.

comment:8 follow-up: dd323 years ago

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?

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?

comment:9 in reply to: ↑ 8 nacin3 years ago

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.

comment:10 dd323 years ago

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.

dd323 years ago

comment:11 dd323 years ago

attachment 16923.patch added

  • Initial integration of the malware API.

comment:12 ocean903 years ago

  • Cc ocean90 added

comment:13 in reply to: ↑ 7 westi3 years ago

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/

comment:14 toscho3 years ago

  • Cc info@… added

comment:15 follow-up: swissspidy3 years ago

  • Cc hello@… added

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.

comment:16 in reply to: ↑ 15 ocean903 years ago

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/

comment:17 nacin3 years ago

  • Keywords has-patch 3.3-early added; needs-patch removed
  • Milestone changed from 3.2 to Future Release

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.

comment:18 nacin3 years ago

  • Owner set to nacin
  • Status changed from new to accepted

comment:19 nacin3 years ago

  • Milestone changed from Future Release to 3.3

comment:20 nacin3 years ago

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

comment:21 WraithKenny3 years ago

  • Cc Ken@… added

comment:22 sabreuse3 years ago

  • Cc sabreuse@… added

comment:23 nacin3 years ago

  • Resolution set to wontfix
  • Status changed from accepted to closed

Wontfix'd in favor of #18289.

comment:24 ocean902 years ago

  • Keywords has-patch 3.3-early removed
  • Milestone 3.3 deleted
Note: See TracTickets for help on using tickets.