WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#26920 closed defect (bug) (duplicate)

The 'wpmu_delete_blog' function deletes all main site's files

Reported by: npetetin Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Networks and Sites Keywords: reporter-feedback
Focuses: multisite Cc:

Description

Hi.

I found a bug in the 'wpmu_delete_blog' function with much impact.

Actually, tables are deleted before the files. But in order to get the blog's upload directory, the 'wp_upload_dir' function, which primarily uses the 'upload_path' option, is called when the option doesn't exist anymore in the database. As a consequence, if that blog option is not cached at that time, the 'wp_upload_dir' function may return by default the main site's upload directory, and then all main site's files are deleted!

A fix is to set the '$uploads' variable before the tables are dropped.

Thanks.

Change History (6)

#1 @jeremyfelt
6 years ago

  • Component changed from Multisite to Networks and Sites
  • Focuses multisite added

#2 @jeremyfelt
6 years ago

  • Keywords reporter-feedback added

Hi @npetetin, thanks for the report.

Are you calling wpmu_delete_blog() directly when this occurs or has this happened during site management in the dashboard?

I attempted to replicate the issue on a new multisite installation, but don't yet see how it is possible. The upload_path option is autloaded, so it should be available in $alloptions when wp_upload_dir() fires whether another object cache is available or not.

Can you provide steps to replicate?

#3 @npetetin
6 years ago

Hi Jeremy.

I'm using the bulk delete action in the dashboard.

Thanks.

#4 @jeremyfelt
6 years ago

It looks like the discovery of the upload directory has always occurred after the tables where dropped. mu:1069

The use of wp_upload_dir() was added in [21823] when ms-files.php was retired in #19235.

I can't see a problem in moving the capture of the uploads directory above the deletion of the tables. That said, I haven't been able to reproduce the issue either. I'm not sure how the option would be destroyed and not available unless it was manually removed in a previous hook.

@npetetin is this a fresh 3.8.1 install or one that has been upgraded over time? Can you provide steps to reproduce?

#5 @npetetin
6 years ago

It's an install that has been upgraded over time from 3.1. There are many plugins that might clear the cache in that context but I didn't troubleshoot further.

To reproduce the issue:

  1. Get the credentials of the superadmin user I created for you on my staging install at http://plioart.staging.wpengine.com either by giving me a safe place to send them to you or by contacting me at my email address included in my WordPress.org account if you can access it
  2. Go to http://plioart.staging.wpengine.com/wp-admin/upload.php and see the thumbnails of the main blog's images (not the first 4 though, it's another issue)
  3. Go to http://plioart.staging.wpengine.com/wp-admin/network/sites.php?paged=13 and delete the last blog from the bulk actions
  4. Go back to http://plioart.staging.wpengine.com/wp-admin/upload.php and see that the thumbnails don't load anymore as the files have been deleted

If you need me to upload the images again or to provide any additional support, please tell me.

Thanks.

#6 @jeremyfelt
5 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed
  • Version 3.8 deleted

@npetetin, I'm going to close this ticket in favor of #30121 as so much progress was made there before I realized a duplicate was outstanding. Thank you for the report!

Note: See TracTickets for help on using tickets.