Rechung PDF leere Seite

[the_dot]

Hey,

also ich wollte im Backend das PDF zur Rechnung generieren, welches ich natürlich vorher über Dokumente eingerichtet hab.

Wenn ich dies in den Bestellungen tun möchte, kommt bei mir aber nur eine leere Seite.

Also Contao bzw. Isotope greift schon auf die Standardtemplates zu, bzw müsste ja zumindest eine Fehlermeldung kommen, wenn irgendwas falsch ist, oder??

Hab ich was vergessen?

Vielen lieben Dank

[tintifax]

sieht das bei dir so aus wie im Screenshot ?

Shopkonfig / Dokumente / Neues Dokument (Rechnung)

rechnung.JPG

[the_dot]

Hey Tintifax,

ja genau so siehts aus, aber ich bekomme keine Ausgabe!?!

[tintifax]

Welche Contao und Isotope Version ist das eigentlich ?

Hast Du eine neue Bestellung ausgeführt ? Wird beim Emailversand, wenn Du das schon eingerichtet hast, das PDF korrekt angezeigt ?

Integritätscheck ok ?

[the_dot]

Integrationscheck ist i.O.

Ich hab aktuell die Contao 3.5.35 und Isotope 2.5.8 installiert

E-Mail Versand hab ich noch nicht aktiviert. Ich wollte die Bestellungen manuell bearbeiten, weil meist noch Sachen individuelle dazu kommen.

Also die Bestellung war "in" und danach hab ich das Dokument angelegt.

[tintifax]

Erst Dokument anlegen, dann bestellen, das wirds wohl gewesen sein, warum das PDF leer ist.
Das füllt sich nicht nachträglich, wird bei Bestellung "befüllt"

[the_dot]

Also ich habs jetzt nochmal ganz von vorn gemacht. Genau in der Reihenfolge. Bekomme aber trotzdem immer noch einen weissen Screen.

Ich habs jetzt auch mal anders gemacht, das ich nach der Bestellung (also aus der Benachrichtigung heraus) als Kunde das PDF direkt ausgegeben bekommen, hab ich aber auch einen weissen Screen.

Bin ich irgendwie bisschen ratlos :-/

[tintifax]

überprüfe mal die templates, ob die Codierung paßt => utf-8 ohne bom
contao check ebenso machen

[the_dot]

Hey Tintifax,

ich hab mal schnell den errorlog gecheckt und ich glaube da könnte irgendwo der Fehler sein.

[31-Oct-2018 23:16:00 Europe/Berlin] PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 1843962 bytes) in /var/www/web3/html/vendor/tecnickcom/tcpdf/tcpdf.php on line 8785

Aber irgendwie ergibt die erlaubte Grösse, zur versuchten erzeugten Grösse, nicht wirklich Sinn!

Könnte das serverseitig sein???

Gruss

[xchs]

Wenn des PHP Memory Limit tatsächlich nur bei 32 MB liegt, dann wäre es nicht weiter verwunderlich, dass es zu einem Fehler kommt.

[the_dot]

Moin XCHS,

kannst du die Aussage näher erläutern? Weil für mich zum Verständnis, hat doch das Ausgabe PDF mit Sicherheit keine 32MB, wobei es ja nur 1,9MB belasten möchte. Oder schlussfolgert dies darauf, das der Rest des Systems schon komplett am Limit läuft?

Dank dir

[xchs]

Kontrolliere mal mittels phpinfo(), auf welchen Wert das PHP Memory Limit (memory_limit) gesetzt ist. Erstelle dazu im Contao Hauptverzeichnis ein Skript phpinfo.php mit folgendem Inhalt

<?php phpinfo(); ?>

und rufe anschließend das Skript im Browser auf.

[the_dot]

Tatsächlich: 32MB

Ich checks nicht, aber irgendwo muss da der Fehler sein.

Für alle anderen die diesen Beitrag vielleicht mal lesen sollten: Für phpInfo gibt es auch im Backend über Erweiterungen die Applikation "be_phpinfo" dafür (ist aber nur bis Vers.2.11. gepflegt)

[xchs]

Das Limit solltest Du – falls möglich – entsprechend erhöhen (lassen). 32 MB sind für den Betrieb von Contao und Isotope schon mehr als "sportlich". Eh schon ein Wunder, dass es nicht schon früher zu Problemen gekommen ist.

[the_dot]

Werde ich auf jeden Fall machen!!! Da ich auch denke das die Performance, mehr als nur am Limit ist.

Ich habe gerade mal noch was anderes gecheckt, weil ich da auch schonmal ein Problem hatte.

Wenn ich (System/Einstellung) die GD Höhe + Breite auf "0" setze (=unendlich :-), dann kommt die Seite ganz normal. Sobald ich diese aber auf zb. 3000x3000 setze = weisser Bildschirm

Schlussfolgernd = läuft es doch wieder auf das gleiche Problem (MemoryLimit) hinaus, oder?

[tab]

Also da bin ich mir jetzt nicht ganz sicher, ob "0" da wirklich die Begrenzung aufhebt. Bei der Frontenendbreite/höhe steht das in der Erklärung dabei, bei GD nicht. Ich fürchte, dass "0" da wirklich Null meint, das heißt, die GD Library wird überhaupt nie versuchen, ein Bild zu verarbeiten (z.B. verkleinern), jedenfalls nicht, solange die Breite > 0 ist . Dann passt das auch wieder mit dem Memory Limit, das wird wohl wirklich auch damit zusammenhängen.

32 MB ist nicht viel, gerade bei der Bearbeitung von Bildern. Auch ein 1000x1000 Pixel Bild, das vielleicht als PNG, JPG oder GIF nur ein paar KB groß ist, braucht im Speicher trotzdem mehrere MB, 4 Bytes pro Pixel wenn ich mich recht erinnere. Ansonsten halt 3 Bytes . Und das System selbst braucht auch noch RAM. Das klappt trotzdem mit 32 MB noch erstaunlich oft, ich hatte auch einige Kundenwebsites, die bei 1&1 unter diesen Bedingungen liefen. Natürlich nur einige wenige relativ kleine Bilder dabei.

[the_dot]

Ich würde sagen, erstmal dickes danke an alle, die sich dem Problem angenommen haben

Schlussfolgernd würde ich mich mal um die Basics kümmern und mit einem Endresultat wieder kommen!

Alles andere wäre wohl erstmal unnötig, aber ich gebe auf jeden Fall für die Community nochmal das nötige Feedback.

In dem Fall eine gute Restwoche und schönen Start in den Donnerstag :-D

THANKS