Korrupte Dateien von Download-Artikeln

In einem neu aufgesetzten Shop verwende ich eine bereits öfters genutzte Funktion, um zu Artikeln dynamisch Downloads hinzuzufügen. Diese kommen aus einer Web2Print-Anwendung, welche der Benutzer im Shop aufrufen und (Druck-)Artikel individualisieren kann. Der Kunde bestellt also seinen Artikel und bekommt in der Bestellmail, sowie in seinem Download-Bereich im Shop einen Link zu der Datei. Soviel zum Ablauf.

Jetzt hatte ich aber den Fall, dass diese Dateien (PDFs) sich nach dem Downloaden über den Link nicht öffnen ließen – Adobe Acrobat beschwerte sich, die Dateien seien irreparabel defekt! Allerdings waren andere Vorschauprogramme nicht so pingelig…

Jetzt war die Frage, woher das auf einmal kommt! Die bisherigen Shops mit diesem Feature hatten das Problem nicht. Um dem Problem auf den Grund zu gehen, wollte ich mir erstmal die Originaldatei ansehen – Download vom Server über SSH, geöffnet: geht! Dateigröße mit der heruntergeladenen verglichen: identisch. Beide Dateien in einen Hex-Vergleich stecken war aber aufschlussreicher: hier gab es einen Unterschied  am Dateianfang und -ende. Im Dateianfang der defekten PDF war eine Leerzeile (2 Byte) und am Dateiende war statt einem „EOF.“ nur noch ein „EO“ übrig – 2 Bytes fehlten.

dateianfang

dateiende Der OXID-Skype-Chat hatte aber schliesslich die Lösung: in den Modulen (von denen es in dem Shop sehr viele gab) muss sich ein schliessendes PHP-Tag befinden! Diese soll man ja gemäß PSR-Standard vermeiden, wenn sich dieses am Ende einer PHP-Datei befindet! Ansonsten wird eine Leerzeile ausgegeben, wenn sich nach dem ?> ein Zeilenumbruch befindet. Dieser wandert dann in die Download-Datei!

In den Modulen habe ich viele davon gefunden! In neuen Modulen hatte ich das bereits berücksichtigt.  Nachdem ich diese überall entfernt hatte, waren die Dateien auch wieder in Ordnung! Das komische war, dass viele der Module auch in den anderen Shops im Einsatz waren. Wahrscheinlich war ein ?>-Tag in einer überladenen Core-Klasse wie oxViewConfig schuld…?!

apps4print_logo
Andreas Dorner

 

 


0 Antworten

Hinterlassen Sie einen Kommentar

Wollen Sie an der Diskussion teilnehmen?
Feel free to contribute!

Schreibe einen Kommentar

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