Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

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?

share|improve this question

2 Answers 2

up vote 2 down vote accepted

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.

share|improve this answer

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)

share|improve this answer
    
Files are identical because there's only one file. The first link (files/2012/09/example.docx) is redirected via .htaccess to the 2nd link. –  Rilwis Sep 11 '12 at 1:13
    
That is exactly my point. The issue is that the webserver is providing a different value for the Content-Type HTTP response header than what WordPress is returning. The question stated that "WordPress multisite is corrupting files in sub-blogs." I was showing that this is not the case and the difference is only in the response header, which is what is throwing off Google Docs. –  Bendoh Sep 11 '12 at 3:07
    
i tried that before but didnt work, you can see result here: http://twentyeleven.korkmaz.biz/files/2012/09/example1.docx I added your code, uploaded same file again after added code, it says application/vnd.openxmlformats-officedocument.wordprocessingml.document format in media panel but still header is application/msword when you call it via /files/ url –  Ünsal Korkmaz Sep 11 '12 at 10:14
    
Here is screenshot: link –  Ünsal Korkmaz Sep 11 '12 at 10:20
    
This doesn't work because the ms-files.php file does a SHORTINIT, which doesn't load plugins at all, including network enabled ones. You can't fix this with a plugin or a theme. However, this specific mime type was added in WordPress 3.5, as of 4 weeks ago: core.trac.wordpress.org/changeset/21541 –  Otto Sep 11 '12 at 17:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.