Eine Beispieldatei: http://twentyeleven.korkmaz.biz/files/2012/09/example.docx
und hier ist die gleiche Datei, aber direkte URL ohne ms-files.php: http://twentyeleven.korkmaz.biz/wp-content/blogs.dir/3/files/2012/09/example.docx
Die gleiche Datei. Zuerst ruft man mit ms-files.php an. Problem ist die erste Datei funktioniert nicht in Google Docs Viewer: http://docs.google.com/viewer?url=http://twentyeleven.korkmaz.biz/files/2012/09/example.docx
diesen Fehler geben:
Leider können wir momentan keine Ansicht des Dokuments generieren. Bitte versuche es später erneut. Sie können auch versuchen, das Originaldokument herunterzuladen, indem Sie hier klicken.
Aber wenn ich dieselbe Datei direkt ohne ms-files.php anrufe: http://docs.google.com/viewer?url=http://twentyeleven.korkmaz.biz/wp-content/blogs.dir/3/files /2012/09/beispiel.docx
Es funktioniert! Aus irgendeinem Grund beschädigt WordPress Multisite Dateien in Sub-Blogs. Es gibt kein Problem im Hauptblog, da die Dateien des Hauptblogs direkten Aufruf erhalten und keine ms-files.php verwenden
Wie kann ich das beheben? Wenn Sie denken, ich kann es nicht beheben, wie kann ich echte Pfad-URL von WordPress generiert / Dateien / URL?
Nur Fix für 3.4.2 beinhaltet das Hacken einer Core-Datei. Das Problem wurde bereits in der kommenden Version 3.5 behoben.
Bearbeiten Sie wp-includes / functions.php. Um die Linie 1810 finden Sie folgendes:
'doc|docx' => 'application/msword', Ändere das zu diesem:
'doc' => 'application/msword',
Die docx-Dateierweiterung wird tatsächlich später in der Datei Zeile 1819 bereits richtig behandelt:
'docx|dotx' => 'application/vnd.openxmlformats-officedocument.wordprocessingml',
So wird es richtig funktionieren, sobald Sie die falsche Erweiterung entfernen.
Nochmals, das Hacken von Core-Dateien ist eine schlechte Sache, aber da die Refactorisierung in WordPress 3.5 das Problem bereits korrigiert, und es gibt keine Möglichkeit, dies in einem Plugin oder Thema oder sogar mit einem richtigen Drop-in zu tun, denke ich, dass dieser spezielle Fall könnte es rechtfertigen.
Die resultierende Datei ist unabhängig von der verwendeten Verknüpfung identisch. Ich habe die Datei über jeden Link heruntergeladen und die Dateien verglichen, sie sind identisch.
Die Schlussfolgerung ist, dass es sich um Header handelt. Was ich von der ms-blogs Version der URL bekomme ist:
Content-Type: application/msword
Versus, was ich von direktem Link bekomme:
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Dies scheint ein Typ zu sein, der Google Docs versteht.
Mein Fazit ist, dass der MIME-Typ, den WordPress für diese Datei, application/msword , application/msword , nicht von Google Docs verstanden wird.
Sie können dies beheben, indem Sie upload_mimes filtern und den Ergebnis-MIME-Typ für .docx-Dateien so upload_mimes , dass er dem richtigen entspricht, den Google Docs versteht:
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 verwendet diesen Filter in der function get_allowed_mime_types() , die von wp_check_filetype() , um den Ausgabe-MIME-Typ in wp-includes/ms-files.php
Aktualisieren
wp-includes/ms-files.php verwendet SHORTINIT , daher werden die Themen nicht geladen, und daher funktioniert der obige Code nicht, wenn Sie ihn in Ihren Themencode einfügen.
Plugins dagegen werden auch bei aktivierter SHORTINIT noch geladen.
(Edit by Otto: Das ist falsch, SHORTINIT verhindert das Laden von Plugins. Siehe wp-settings.php, um Zeile 95 herum, wo der SHORTINIT-Flag den Ladevorgang abbricht und die Plugins danach geladen werden. Der folgende Code funktioniert nicht. )
(Edit von Bendoh: D’oh! Ich hatte die SHORTINIT-Deklaration beim Testen auskommentiert und somit hat meine Lösung funktioniert, aber Sie haben Recht, dass es nicht funktioniert, ohne mit Core zu murren. Ich habe den Code unten entfernt, da er nicht Ich arbeite tatsächlich. Ottos Antwort ist richtig.