Media Uploader doesn't escape "+" in filenames and doesn't upload file

[devinreams]

I downloaded a photo this morning with filename Screenshot+2012-12-07+at+08.55.33.png — when I upload it in the WordPress media uploader it acts like its uploading (progress bar, crunching) but then shows a broken image as the result.

1. Upload media with "+" in filename
2. Observe progress bar uploading and complete the upload

Expected: file is uploaded A-OK to server, attachment created, image loads as expected.

Actual: no file is stored in uploads (or blogs.dir/files) directory, attachment is still created, no error, file does not exist.

FWIW the filename that WordPress expects to have uploaded is /2012/12/Screenshot+2012-12-07+at+08.55.33-150x150.png

I'm on Media Temple, running trunk as of this morning. Not sure if a regression, specific to my server configuration, etc. so more testing here would be appreciated.

Sounds like a duplicate of #16330.

I think it's similar but likely not quite a duplicate, since my file was not actually getting uploaded to the uploads directory...

I'm able to reproduce on 3.5-RC4-23121, though with slightly different results.

Uploaded a file "screen+shot+1+2+3.png" in WordPress 3.4.2 (Multisite), everything appears to work as expected. An immediate thumbnail appears showing uploaded image, accessible via ​http://domain.dev/files/2012/12/screen+shot+1+2+3-150x150.png

Uploaded same file in WordPress 3.5-RC4-23121 (Multisite), upload appears fine with proper resized versions in /blogs.dir/files/... Image is not accessible via direct URL (404) at ​http://domain.dev/files/2012/12/screen+shot+1+2+3.png (no thumbnail size attached)

This may also be server related now that I look more. My trunk and 3.4.2 environments are slightly different.

$_GET['file'] on my 3.4.2 Multisite (nginx / PHP 5.3.6 ) returns the proper filename, so passes the is_file() check in ms-files.php

$_GET['file'] on 3.5-RC4-23121 Multisite ( Apache / PHP 5.3.6 ) returns the filename with spaces instead of +, which fails the is_file()check.

Hmm, in single site, ​http://localhost/beta/wp-content/uploads/2012/12/Screen-Shot+2012-12-07+at+4.42.18-AM.png worked fine for me.

blogs.dir has always been pretty bad, though it's disconcerting this supposedly worked in 3.4.2 with the same setup?

Different setup - apache vs nginx. Setting up 3.4.2 locally now.

I *think* it's how the server is handling the URL before it hits WordPress.

Broken on Apache 3.4.2 Multisite.

Same on 3.4.2 Multisite with Apache for me, broken file.

Problem follows the server setup - Apache - rather than the WordPress setup. Confusing issue, but no regression.

Just to pile on with a quick update, this was on an existing multisite installation (not a new install) so is an issue in ms-files.

I set my sitemeta to have ms_files_rewriting = 0 then these images with characters like "+" upload fine. But, then all my existing image paths break.

Not a regression, moving version down.

#24117 was marked as a duplicate.

(as per #24117), I'm also seeing this problem on our Apache servers on our multisite installations that use ms-files.php rewriting.

The safest approach here seems to be to automatically remove + characters from file names during the upload process.

22813.diff achieves this by modifying the sanitize_file_name() function.

This problem is also similar to the one reported in #16330 (which also has a patch).

This solution solves the problem for new files that are uploaded, however it doesn't solve it for any existing media library files that contain a plus sign in their name.