Composer, die Zweite

[Anton Korduan]

Hallo nochmal!

Ich weiß nicht mehr weiter, ich denke, es hängt mit dem Composer zusammen, bin aber nicht sicher.

Folgende Situation:

• Ich setze den HTML2PDF ein um PDF-Dateien zu erzeugen.
• In meiner Testumgebung läuft alles.
• In der offiziellen Umgebung (anderer Order), entstehen dagegen Fehlermeldungen (wenn eine GIF-Datei ausgegeben werden soll).

Ich habe jetzt alles brachial heruntergebrochen und vereinfacht um gleiche Situation herbeizuführen:

• Habe HTML2PDF jeweils neu installiert (siehe https://github.com/spipu/html2pdf/bl...doc/install.md),
• Setze zwei SubDomains von der selben Domain ein (PHP7.2), eine deutet auf den offiziellen, eine auf den Testordner.
• verwende beide Male die gleiche, Test-Datei:

<?

    header('Content-Type: text/html; charset=utf-8');
    error_reporting(E_ALL | E_STRICT);
    ini_set('arg_separator.output','&amp;');
    setlocale(LC_TIME, "de_DE.utf8");

    require_once __DIR__.'/html2pdf_test/vendor/autoload.php';

    use Spipu\Html2Pdf\Html2Pdf;
    use Spipu\Html2Pdf\Exception\Html2PdfException;
    use Spipu\Html2Pdf\Exception\ExceptionFormatter;                

    ob_start();

    echo 'images/aufzaehlung_grau.gif: <img src="images/aufzaehlung_grau.gif" />';

    $content = ob_get_clean();

    try
    {


        $html2pdf = new HTML2PDF('P', 'A4', 'de', true, 'UTF-8', array(25, 25, 25, 15));
        $html2pdf->pdf->SetDisplayMode('fullpage');
        $html2pdf->writeHTML($content, isset($_GET['vuehtml']));
        $html2pdf->Output('_pdf_test.pdf');

    }
    catch(HTML2PDF_exception $e) {
        echo "Konnte PDF nicht erstellen: ".$e;
    }

?>

Ergebnis:



1) Testumgebung

Neuinstallation HTML2PDF via Composer in root/testordner/html2pdf_test;
Testlauf: Alles funktioniert einwandfrei, das PDF wird erzeugt, Screenshot:

2) Offizielle Umgebung

Neuinstallation HTML2PDF via Composer in root/offiziellerordner/system/html2pdf_test;

Testlauf (identische Datei): wirft wieder Fehler aus, Screenshot:

Es geht mir jetzt nicht um die Fehlermeldung selbst.
Sondern:

Ich frage mich, warum die identischen Installationen unterschiedliche Ergebnisse erzeugen.

Die einzigen Unterschiede, die jetzt noch bleiben sind:

• Unterschiedliche Ordnernamen
• Der Testordner ist durch eine .htaccess geschützt (da funktioniert's aber dennoch)

Das kann die Ursache also nicht sein.

Übersehe ich etwas?
Kann das mit dem Composer zusammenhängen?
(Aber beide Installationen liefen doch fehlerfrei durch)

Danke für Eure Hilfe, verzweifelte Grüße
Anton


PS: Bei der Composer-Installation habe ich damals keine PHP-INI angeben, hier der zugehörige Thread, der mit diesem (im Grunde zufriedenstellenden) Posting endete:
https://forum.df.eu/forum/user-f%C3%...=2548#post2548

[masterframe]

Probiere doch mal die komplette URL incl. Domainame zu verwenden.
Also: http://domain.de/images/grau.gif

[Anton Korduan]

Probiere doch mal die komplette URL incl. Domainame zu verwenden.
Also: http://domain.de/images/grau.gif

Danke - aber die Frage bleibt, warum das mit den relativen Dateinamen in der Testumgebung wunderbar funktioniert?

Nachtrag: Hab's gerade getestet - gleicher Fehler.

Es funktioniert davon abgesehen auch mit relativen Dateinamen, wenn es z.B. eine PNG ist, habe diesen Code erfolgreich getestet in der offiziellen Umgebung - fehlerfrei:

echo 'images/aufzaehlung_hackerl.png: <img src="images/aufzaehlung_hackerl.png" />'; 

[Christian]

Hallo Herr Korduan,
ich würde kein System - Problem vermuten. Wenn Ihnen eine Library fehlen würde, dann kann man das im Stacktrace bzw. Logging sehen.

Wenn das PDF ohne das Bild problemlos generiert wird, dann ist es ein guter Indikator für die weiter Fehlerprüfung.


„Unable to get the size of the image“ könnte vielleicht bedeuten dass das Bild nicht lesbar oder verfügbar ist. Vielleicht sollte du einmal eine absolute Adresse http://….. shepherd.de/dein-bild.de verwenden. Vielleicht liegt es an einer php Einstellung, die sich zwischen Testumgebung und Livesystem unterscheidet. Auch Datei- bzw. Nutzer-rechte könnten zu diesem Problem führen

[Lukas M.]

Wie sieht dann deine Testumgebung aus?
Selbe PHP-Version ist ja nun nicht das einzige Thema. Dazu kommt auch noch: Wie ist das in den Webserver eingebunden, wie sind die Owner gesetzt, wie die Rechte, etc.

Ein "unable to get the size" kann ja auch heißen: Ich hab da als Script keinen Zugriff.

[Anton Korduan]

Danke für Eure Antworten,
Christian
Lukas M.

Es ist unglaublich.

Und unglaublich peinlich:

Tatsächlich war in der offiziellen Umgebung (aus mir unerklärlichen Gründen) die Datei "aufzaehlung_grau.gif" nicht vorhanden.

Ich setzte jetzt meine Tests fort und melde mich, wenn mir noch etwas auffällt.
Aber so wie's aussieht ... einfach nur peinlich.

Unglaublich, wie tief man da manchmal drinsteckt, im Tunnelblick ...

Sorry und danke für die Hilfe!

Ganz herzliche Grüße
Anton

[Christian]

Guten Abend Herr Korduan, das passiert den Besten!

Beste Grüße
Chris von 365layouts.com

[masterframe]

Dann hast du es aber auch nicht mit der "kompletten" URL getestet.
Sonst hätte es in beiden Instanzen funktionieren müssen.

[Anton Korduan]

Dann hast du es aber auch nicht mit der "kompletten" URL getestet.
Sonst hätte es in beiden Instanzen funktionieren müssen.

Nein, Mißverständnis: Die Datei existiert zweimal, in jeder Instanz einmal.
(Bzw. hat sie in der offiziellen Instanz ja gefehlt).

Daher machte der absolute/relative Pfad keinen Unterschied, weil die Datei in der offiziellen Instanz so oder so nicht vorhanden war.

[masterframe]

Ah, dann hattest du mich falsch verstanden.
Mit absoluter URL meinte ich natürlich, dass du in beiden Instanzen mit _derselben_ URL testest.
Ansonsten hätte man ja wieder einen Unterschied gehabt.

Aber gut, das Problem ist geklärt.