I upgraded nginx on my server and all was well, or so I thought…. (TL;DR at the bottom)
Feeling good about my self I patted my back and went to bed. The next day I was writing a new post when after uploading a photo to WordPress it did not load in the editor. So after a little struggling I figured out why non of the images from the /files/ directory in wordpress were working, but not until after I gave up trying to find the answer in Google.
I tried Googling all this to no avail: (Hopefully this will help some other Googler out there)
- Ngnix not rewriting ms-files.php properly
- my nginx default conf for wordpress was faulty
- no errors in php for ms-files.php WPMU
- ms-files.php corrupting images WPMU
- ms-files.php white (blank) screen of death
After exhaustive rebuilding nginx config files for WordPress MU I finally went back to poking at the blank screen…
When I loaded up Firefox I got “The image cannot be displayed because it contains errors” so I saved the file, and to my surprise is was actually a jpg full of data! And at first it looked fine, but as it turned out, is was incomplete. So I went back to Google and found a bug on the WordPress Core Trac Bug Reports. http://core.trac.wordpress.org/ticket/14730
Eureka moment! As it turns out it was a known bug, by an unknown cause! I know mine was caused by upgrading nginx on ubuntu Lucid, and commenting out this line in fastcgi_prams config file. # fastcgi_param HTTPS $server_https; It was added, and broke things so it was uneeded. But I think that as a side effect, it was truncating the output of ms-files.php.
TL;DR
So anyway the solution was a simple patch for ms-files.php to clear the buffers before and after reading the image file. (The entire patch is below, and goes at the very end of the file)
79 79 } 80 80 81 81 // If we made it this far, just serve the file 82 ob_clean(); 83 flush(); 82 84 readfile( $file ); 85 flush(); 83 86 ?>



Recent Comments