Google Docs Viewer have problem in MultiSite sub-blogs

Question

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?

Answer 1

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:

'doc|docx' => 'application/msword',

Change that to this:

'doc' => 'application/msword',

The docx file extension is actually already handled properly later down in the file, line 1819:

'docx|dotx' => 'application/vnd.openxmlformats-officedocument.wordprocessingml',

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.

Answer 2

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:

Content-Type: application/msword

Versus what I get from direct link:

Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document

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:

function my_filter_upload_mimes( $mimes ) {
     $mimes['doc|docx'] = "application/vnd.openxmlformats-officedocument.wordprocessingml.document";
     return $mimes;
}
add_filter( 'upload_mimes', 'my_filter_upload_mimes' );

WordPress uses this filter in the function get_allowed_mime_types(), which is used by wp_check_filetype() to determine the output MIME type in wp-includes/ms-files.php

Update

wp-includes/ms-files.php uses SHORTINIT, 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 with SHORTINIT 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)