An example file:
http://twentyeleven.korkmaz.biz/files/2012/09/example.docx
and here is same file but direct url without ms-files.php:
http://twentyeleven.korkmaz.biz/wp-content/blogs.dir/3/files/2012/09/example.docx
Its same file. Just first one is getting call with ms-files.php. Problem is
first file is not working in google docs viewer:
http://docs.google.com/viewer?url=http://twentyeleven.korkmaz.biz/files/2012/09/example.docx
giving this error:
Sorry, we are unable to generate a view of the document at this time.
Please try again later. You can also try to download the original
document by clicking here.
But if i call same file with directly without ms-files.php:
http://docs.google.com/viewer?url=http://twentyeleven.korkmaz.biz/wp-content/blogs.dir/3/files/2012/09/example.docx
Its working! So for some reason wordpress multisite is corrupting files in sub-blogs. There is no problem in main blog because main blog’s files getting direct call and not using ms-files.php
So how can i fix this? If you think i cant fix it, how can i get real path url from WordPress generated /files/ url?
Only fix for 3.4.2 involves hacking a core file. The issue is already corrected in the upcoming version 3.5.
Edit wp-includes/functions.php. Around line 1810, you’ll find this:
Change that to this:
The docx file extension is actually already handled properly later down in the file, line 1819:
So it will work properly once you remove the spurious extension.
Again, hacking core files is a bad thing, but seeing as the refactorization in WordPress 3.5 corrects the issue already, and there’s no way to do this in a plugin or theme or even with a proper drop-in, I think that this specific case might justify it.
The resulting file is identical regardless of the link that you use. I downloaded the file via each link and compared the files, they are identical.
So the conclusion is that it’s a matter of headers. What I get from the ms-blogs version of the url is:
Versus what I get from direct link:
Which appears to be a type which Google Docs understands.
My concluson is that the MIME type that WordPress provides for this file,
application/msword
, is not one that Google Docs understands.You can fix this by filtering
upload_mimes
, and changing the result MIME type for .docx files to match the correct one that Google Docs understands:WordPress uses this filter in the function
get_allowed_mime_types()
, which is used bywp_check_filetype()
to determine the output MIME type inwp-includes/ms-files.php
Update
wp-includes/ms-files.php
usesSHORTINIT
, so themes are not loaded, and thus the above code will not work if you place it in your theme code.Plugins, on the other hand, will still be loaded even withSHORTINIT
enabled.(Edit by Otto: This is incorrect, SHORTINIT prevents plugin loading. See wp-settings.php, around line 95 for where the SHORTINIT flag cuts off the loading process, and note that plugins load after that. The following code will not work.)
(Edit by Bendoh: D’oh! I had commented out the SHORTINIT declaration while testing and thus my solution did work, but you’re correct that it won’t work without mucking with core. I removed the code below as it doesn’t actually work. Otto’s answer is correct)