Kaputten Import bei Caldera Forms reparieren

In der neuesten WordPress-Version gibt es bei manchen Serverkonfigurationen einen kaputten Import mit Caldera Forms und sicher auch mit einigen anderen Plugins. Hier beschreibe ich einen Weg zum Debugging und Lösen des Problems.

Das Problem tauchte bei mir nach dem letzten Sicherheitsrelease auf. Nach einem versuchten Import bekam ich nur folgende Fehlermeldung zu sehen:

Form could not be imported. File type must be JSON.

Laut Dokumentation von Caldera Forms liegt es an folgendem:

The second error message “Form could not be imported. File type must be JSON.” was added in Caldera Forms 1.7.5. It indicates that the file you are importing is not considered a JSON file by WordPress. The way WordPress checks this changed in WordPress 5.0.1 in a way that was not backwards compatible. If you experience this error, please try exporting again. Most likely this will happen if you created the JSON file manually. This error will not happen if you create the JSON file in Atom or VSCode.

Another reason for you may get either of these errors is that your import file is not a JSON file. While you can export a form as PHP, it is not possible to import that export file using the import button.

Und obwohl der entscheidende Hinweis auf das Sicherheitsupdate von WordPress sogar erwähnt wird, ist der nachfolgende Erklärungsversuch völliger Unsinn. Der Fehler tritt bei einer von Caldera Forms exportierten Datei ebenso auf. Das Plugin war auf beiden Websites in der gleichen Version. Die JSON-Datei wurde also weder manuell erstellt noch waren andere Editoren im Einsatz und natürlich wurde beim Export JSON gewählt und nicht die PHP-Variante.

Das Problem wurde hier also offensichtlich nicht annähernd verstanden, geschweige denn eine Lösung präsentiert. Also folgte ich dem Link zum Make-Blogeintrag. Doch in diesem Artikel zum Release steht die relevante Info gar nicht. Erst im dort verlinkten Beitrag zur Devnote stehen die wirklich hilfreichen Informationen. Und zwar im letzten Absatz:

MIME validation for uploaded files

Prior to 5.0.1, WordPress did not require uploaded files to pass MIME type verification, so files could be uploaded even if the contents didn’t match the file extension. For example, a binary file could be uploaded with a .jpg extension.

This is no longer the case, and the content of uploaded files must now match their extension. Most valid files should be unaffected, but there may be cases when a file needs to be renamed to its correct extension (e.g., an OpenOffice doc going from .pptx to .ppxs).

Aus irgendeinem Grund denkt also WordPress bzw. mein PHP das meine JSON-Datei keine JSON-Datei ist. Genauer gesagt: Die in WordPress hinterlegten, erlaubten Mime Types für diese Datei-Erweiterung stimmen nicht mit dem aktuellen Mime Type überein. Und nun? Im und unter dem Beitrag finde ich zwar unzählige Tickets aber keine Hilfe, wie ich nun vorgehen oder testen kann. Dankenswerterweise finde ich dann in einem Trac-Kommentar doch noch ein praktisches Snippet:

<?php 
echo 'PHP Version: ' . phpversion() . "<br/><br/>";
echo 'test-kontaktformular-export.json | ' . mime_content_type( 'test-kontaktformular-export.json') . "<br/>";

Eine Datei mit diesem Inhalt auf den Server hochladen, die exportierte JSON-Datei ebenfalls hochladen (der Dateiname muss natürlich passen) und so schauen welche Version von PHP läuft und was sie als Mime Type glaubt zu erkennen. In meinem Fall war das text/html. Was natürlich völliger Quatsch ist. Der korrekte Mime Type wäre ja application/json. Da aber auch ein Hinzufügen von AddType application/json .json in der .htaccess nichts daran ändert muss ich das Problem anders lösen. Wieder finde ich einen hilfreichen Trac-Kommentar mit dem ich der Erweiterung .json weitere erlaubte Mime Types hinzufügen kann:

/**
 * Support for 'text/html' as the secondary(?) mime type of .json files
 */
add_filter( 'wp_check_filetype_and_ext', 'wpse323750_secondary_mime', 99, 4 );    
function wpse323750_secondary_mime( $check, $file, $filename, $mimes ) {
    if ( empty( $check['ext'] ) && empty( $check['type'] ) ) {
        // Adjust to your needs!
        $secondary_mime = [ 'json' => 'text/html' ];
        // Run another check, but only for our secondary mime and not on core mime types.
        remove_filter( 'wp_check_filetype_and_ext', 'wpse323750_secondary_mime', 99, 4 );
        $check = wp_check_filetype_and_ext( $file, $filename, $secondary_mime );
        add_filter( 'wp_check_filetype_and_ext', 'wpse323750_secondary_mime', 99, 4 );
    }
    return $check;
}

Die bei euch zurückgelieferten Mime Types können womöglich abweichen, so dass der Code angepasst werden muss. Und warum 1und1 text/html für .json zurückliefert muss ich auch nochmal näher erfragen, aber so lassen sich zumindest wieder Formulare in Caldera Forms importieren.

Nachtrag: Der Mime Type text/plain scheint ebenfalls zu funktionieren.

9 Antworten auf Kaputten Import bei Caldera Forms reparieren

  1. Hi Torsten,
    vielen Dank für deine Hilfe zu dem Thema. Ich hänge leider am zweiten Schritt fest aber kenne mich auch gar nicht mit PHP aus. Allgemein wäre es für Fachfremde sehr hilfreich wenn du ein bisschen konkreter wirst: Wie heißen die Dateien, wo liegen sie genau, wie erreicht man sie, in den Code-Blocks, usw…trotzdem danke, ich werde es weiter probieren.

    • Die Dateien heißen so wie du sie benennst. Der erste Code wird in eine neu erstellte PHP-Datei kopiert und dann aufgerufen (natürlich mit der entsprechenden JSON-Datei am gleichen Ort).

      Das dienst nur der Analyse und kann danach gelöscht werden.

      Der zweite Block muss dauerhaft da bleiben und kann z.B. in einem Snippet landen (https://wordpress.org/plugins/code-snippets/) oder in einem Functionality-Plugin (https://gist.github.com/Zodiac1978/1d9f33ef1be377869ad3) oder falls du eh ein Child-Theme selbst gebaut hast, auch in der dortigen functions.php-Datei. Nur bitte nicht in die functions.php eines anderen Themes packen, denn sonst ist beim nächsten Update des Theme deine Ergänzung futsch.

      Das Ganze macht aber nur Sinn, wenn du das beschriebene Problem wirklich hast. Es kann auch andere Gründe für diese Fehlermeldung geben.

      Hoffe das hilft dir!

  2. Ich habe es dann wenig später hinbekommen. Vielen Dank!

  3. Hi Torsten,

    bei mir auf dem Server (all-inkl) funktioniert der zweite Code-Block in Verbindung mit .m4a nicht. Es ist eine Audio-Datei, die mein Smartphone standardmäßig generiert. Der Server hält es beim Upload für video/mp4. Richtigerweise wäre audio/mp4, aber weder das noch audio/m4a noch audio/x-m4a halfen. In allen drei Fällen kommt trotz des Codes folgende Meldung:

    „Dieser Dateityp ist aus Sicherheitsgründen leider nicht erlaubt.“

    Beim Versuch .ogg hochzuladen kommt dann folgende Meldung:

    „Dieser Dateityp wird hier leider nicht unterstützt.“

    Obwohl m4a als auch ogg offiziell unterstützt werden:

    https://codex.wordpress.org/Uploading_Files

    Erstaunlicherweise wird von Server die ogg-Datei auch richtigerweise als audio/ogg erkannt. Werde mal bei all-inkl nachfragen, woran das liegen kann.

    Das einzige, was in meinem Fall bei beiden Fällen funktioniert ist, die Holzhammermethode, folgendes in der wp-config:

    define(‚ALLOW_UNFILTERED_UPLOADS‘, true);

    Grüße

  4. Hallo Thorsten,

    hilft Deine Lösung auch bei Multisite-Installationen?

    Danke für Deine Antwort

    Grüße – Ron

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.