SVG-Dateien werden seit dem letzten WP-Update nicht hochgeladen

Ich habe einen Ausschnitt in meiner Funktions-PHP-Datei, mit dem ich SVG-Dateien hochladen kann. Seit dem heutigen Upgrade auf die neueste Version von WP kann ich keine svgs mehr hochladen. Ich habe auch einen zweiten Codeausschnitt von der CSS-Tricks-Website ausprobiert, und das funktioniert auch nicht.

Kennt jemand a) was dies mit dem letzten Update verursacht haben könnte und b) kennt jemand eine Abhilfe?

Hier ist der Code, den ich normalerweise benutze:

function svg_mime_types( $mimes ) {
   mimes['svg'] = 'image/svg+xml';
   return $mimes;}
add_filter( 'upload_mimes', 'svg_mime_types' );  

Danke vielmals

Paul.

In WordPress 4.7.1 wurde eine Änderung eingeführt , die nach dem echten MIME-Typ einer hochgeladenen Datei sucht. Dadurch wird das Hochladen von Dateitypen wie SVG oder DOCX unterbrochen. Es gibt bereits Tickets für dieses Problem in WordPress Core, wo Sie mehr darüber lesen können:

• Einige Nicht-Bilddateien können nach 4.7.1 nicht hochgeladen werden ( https://core.trac.wordpress.org/ticket/39550 )
• SVG-Upload-Unterstützung in 4.7.1 unterbrochen ( https://core.trac.wordpress.org/ticket/39552 )

Eine vorübergehende und empfohlene Problemumgehung (für die Zeit, bis dieses Problem behoben ist) ist das folgende Plugin:
Deaktivieren Sie Real MIME Check

Wenn Sie dieses Plugin nicht verwenden möchten, finden Sie hier die gleiche Funktionalität:

add_filter( 'wp_check_filetype_and_ext', function($data, $file, $filename, $mimes) {
    global $wp_version;

    if ( '4.7.2' !== $wp_version ) {
       return $data;
    }

    $filetype = wp_check_filetype( $filename, $mimes );

    return [
        'ext'             => $filetype['ext'],
        'type'            => $filetype['type'],
        'proper_filename' => $data['proper_filename']
    ];

}, 10, 4 );

Beachten Sie, dass in diesem Snipping eine Versionsüberprüfung enthalten ist, um das Update zu deaktivieren, sobald WordPress aktualisiert wird.

Bearbeiten

Das Problem wurde ursprünglich in 4.7.2 behoben. Da es sich bei 4.7.2 jedoch um ein dringendes Sicherheitsupdate handelte , hat es der Fix nicht in diese Version geschafft. Es soll nun in 4.7.3 behoben sein.

Scheint so, als könnte dies mit diesem Ticket zusammenhängen https://core.trac.wordpress.org/ticket/39552 , sieht aus wie etwas, das in 4.7.1 kaputt gegangen ist

Niemand scheint nur mit dem gearbeitet zu haben, was ist und das ist schade, also hier ist, wie ich gehandhabt habe ...

Geschichte / Hintergrund

Ich habe 2015 einen SVG-Uploader basierend auf einem CSS-Tricks-Artikel erstellt. Ich habe auch Gitter für die Bildvorschau arbeiten lassen und ein paar andere Korrekturen verwendet. Einfaches Plugin (IMO-Plugins sollten einfach sein)

Lösung

In 4.7 wurden einige Änderungen vorgenommen. Die wahre PITA war, dass image/WP für Pantomimetypen jetzt GD für die Bilder verwendet. Um dies zu umgehen, habe ich die svgErweiterung application/svg+xmlso eingestellt , dass GD nicht mit der Datei herumwirbelt.

Update: Ab 4.7.2 hat ein heller Funke das in einigen Fällen auch gebrochen

Dann später über Haken wir es zurück zu hotwire image/svg+xml. Es ist dasselbe, das in anderen Antworten verwendet wird, aber wir beschränken es zunächst auf unseren speziellen Fall, um Effekte zu eliminieren (ist es eine SVG-Datei); Wir können uns auf das Lesen verlassen $data['ext'](sollte billiger sein als die Funktion zum Abrufen von Dateiinformationen, da nur ein Vergleich und ein Array / Hash-Zugriff möglich sind).

Update: Ab 4.7.2 $data['ext']ist nicht immer festgelegt, daher wird jetzt, wenn die Länge <1 ist, die (möglicherweise unsichere) Erweiterung aus dem Dateinamen extrahiert strtolower(end(explode('.', $filename))). Der Grund, warum ich wirklich mit FileInfo kämpfe, ist, dass es im Wesentlichen zu undurchsichtig ist, sich auf eine PHP-Erweiterung zu verlassen, und nicht immer für alle funktioniert (insbesondere nicht für diejenigen, die ohne oder ohne Zugriff kompilieren, um Erweiterungen zu aktivieren, wenn sie nicht vorhanden sind). Ich hätte gerne etwas, das anstelle einer Erweiterung funktioniert. Es geht nicht mehr darum, die richtigen Informationen zu haben. Für diejenigen, die auf die Ausgabe von FileInfound die Erweiterung vertrauen (ich glaube, es ist Standard in 5.6+), sollte dies funktionieren. Auch weil es sich um ein Plugin handelt, das den Kern nicht verändert, können Sie diesen Code deaktivieren oder die Registrierung des Hooks aufheben.

https://github.com/Lewiscowles1986/WordPressSVGPlugin

Sehen

• https://github.com/Lewiscowles1986/WordPressSVGPlugin/blob/master/wp-content/plugins/lc-wp-svg/index.php#L38
• https://github.com/Lewiscowles1986/WordPressSVGPlugin/blob/master/wp-content/plugins/lc-wp-svg/index.php#L74
• https://github.com/Lewiscowles1986/WordPressSVGPlugin/blob/master/wp-content/plugins/lc-wp-svg/index.php#L23
• https://github.com/Lewiscowles1986/WordPressSVGPlugin/blob/master/wp-content/plugins/lc-wp-svg/index.php#L79

Andere Problemumgehungen

Ungefilterte Uploads zuzulassen, ist eine schreckliche Lösung, da, wie andere bereits gesagt haben, die Verlinkung zu diesem Thread dazu führen könnte, dass PHP-Dateien über den Media-Uploader hochgeladen werden (das ist schlecht, und wenn Sie es tun, sollten Sie innehalten und nachdenken!).

Erzwinge jede Datei durch irgendeine Funktion ohne Prüfung (Ironischerweise image/kann man nicht einfach eine Ext-Prüfung durchführen, wenn man den MIME-Typ hat). Dies hat das Potenzial, weitreichendere Effekte zu erzielen, um ein relativ nischenhaftes Problem zu lösen und insgesamt mehr Arbeit zu verursachen.

Wenn wir die MIME als application / svg + xml belassen und einfach die MIME-Typen gefiltert würden, die das Bild hochladen würde, aber AFAIK Korrekturen als empfohlenes Bild usw. benötigt. Es gibt mehr zu tun, um eine universelle SVG-Erfahrung zu gewährleisten Schlachten sorgfältig auswählen.

Hoffe das hilft.