Make WordPress Core

Opened 13 years ago

Closed 13 years ago

#18182 closed defect (bug) (fixed)

Upload installs of plugins/themes not cleaning up after themselves

Reported by: hew's profile hew Owned by: dd32's profile dd32
Milestone: 3.2.2 Priority: normal
Severity: normal Version: 3.2
Component: Upgrade/Install Keywords:
Focuses: Cc:

Description

Upload installs of plugins and themes are not removing the .zip file after installation.

To reproduce:

  1. Upload a zipped theme or plugin via Themes->Install->Upload or Plugins->Install->Upload.
  2. Check /wp-content/uploads and you should see the zip left over from install.

Attachments (1)

18182.diff (1.2 KB) - added by dd32 13 years ago.
3.2.x patch and initial 3.3 patch

Download all attachments as: .zip

Change History (12)

#1 @hew
13 years ago

  • Version set to 3.2.1

#2 @dd32
13 years ago

  • Component changed from Upload to Upgrade/Install
  • Owner set to dd32
  • Status changed from new to reviewing

#3 @dd32
13 years ago

  • Milestone changed from Awaiting Review to 3.3
  • Status changed from reviewing to accepted
  • Version changed from 3.2.1 to 3.2

This was caused by [17660] - which I thought I'd tested this code branch properly.

Ultimately, The uploaded file shouldn't be moved to the uploads directory at all with the current uploader, It appears to have been written with Ajax uploading in mind (Not sure that's something we really need for the plugin/theme uploaders).

The code that moves the file to the uploads directory just needs to be removed by looks of it, but i'll do some more testing.

Setting to 3.3 for now, Will need to go into the 3.2 branch as well.

#4 @dd32
13 years ago

Ultimately, The uploaded file shouldn't be moved to the uploads directory at all with the current uploader

Unfortunately, I was forgetting about FTP upgrades, the file needs to be uploaded and stored for the following request.

Previously if a user was to upload a theme, but not follow through with the install (ie. prompted for FTP details) the zip file wouldn't be deleted either.

Proposed patches:

  • 3.2.x: Just clean up after ourselves after installing.
  • 3.3: We should store uploaded items in the Media Library somehow, and as well as deleteing after installing, a cron job should clean up any non-installed items.

@dd32
13 years ago

3.2.x patch and initial 3.3 patch

#5 @dd32
13 years ago

In [18614]:

Clean up Plugin/Theme uploads after successfully installing them. Restores pre-3.2 behaviour. See #18182

#6 @dd32
13 years ago

In [18615]:

Clean up Plugin/Theme uploads after successfully installing them. Restores pre-3.2 behaviour. See #18182 for 3.2.x

#7 @dd32
13 years ago

In [18616]:

Only clean up the uploaded files after a successful (or failed) install. Allows files to persist past the FTP credential screen. See #18182

#8 @dd32
13 years ago

In [18617]:

Store Plugin/Theme uploads in the Media Library properly. Add Scheduled cleanup +2hrs to clean up any aborted installation attempts. See #18182

#9 @dd32
13 years ago

  • Milestone changed from 3.3 to 3.2.2

[18616]

That needs to be (in part at least) applied to 3.2.x as well. Needs more testing on my end before the final 3.2.x patch is done.

#10 @dd32
13 years ago

In [18713]:

Only clean up the uploaded files after a successful (or failed) install. Allows files to persist past the FTP credential screen. See #18182

#11 @dd32
13 years ago

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

Calling this one as done for 3.2 and trunk.

  • 3.2.2, 3.3: Clean up uploaded files after successful installations
  • 3.2.2, 3.3: Clean up uploaded files after failed installations
  • 3.3: Store uploads in the Media Library temporarily with the context flag set, Clean up any aborted(ie. see the FTP credentials page, and give up) installation files 2hours after install attempt.
Note: See TracTickets for help on using tickets.