HTTP 500 Error beim Verschicken der Auftragsbestätigung

[JPW]

Hallo zusammen,
wir nutzen die manuelle Auftragsbestätigung. Das Verschicken der Auftragsbestätigung löst immer einen HTTP 500 Error aus.
IONOS meint, es liegt am Shopsystem.

Ich habe in den letzten Tagen allerdings Einiges geändert, sodass ich nun ratlos bin, wo ich suchen muss:
- Update 2.0.4.2 -> 2.0.5.0
- PHP-Version auf 7.4 (versuchsweise auch 7.2 und 7.1)
- css_product_attribut_lagerampel_fuer_shopversion_2.x wieder eingebaut
- attribute_price_updater_v2.25-BETA -> v2.27-BETA
- PDFBillNext-1.1.8c -> 1.1.8d

Nun wollte ich ausprobieren, ob der Kunde möglicherweise trotzdem eine Auftragsbestätigung bekommt und dazu eine Testbestellung anlegen. Jedoch ist der Checkout ebenfalls fehlerhaft. Die checkout_shipping.php ist weiß. Ob das im Zusammenhang steht oder unterschiedliche Themen sind, weiß ich nicht.
Ich habe mir die verschiedensten Logs des Shops angesehen, werde aber aus den Infos nicht schlau. Es bleibt mir nur, wieder hier um Hilfe zu bitten.

Viele Grüße
Jens

Linkback: https://www.modified-shop.org/forum/index.php?topic=40878.0

[Timm]

Moin

Hast du mall testweise die Komprimierungen ausgeschaltet und dann versucht in den checkout zu gelangen?

Bei pdf bill next hast du aber nicht einfach die alten Dateien des Moduls hochgeladen, sondern die nötigen Stellen per Hand eingefügt, oder?

Fehlermeldungen wäre gut, um Hilfe zu geben.

Gruß Timm

P.S. immer wenn du an den emaileinstellungen was änderst, musst du das Passwort erneut eintragen vor dem speichern, da viele Browser dort automatisch das Shoppasswort eintragen.

[JPW]

Hallo Timm,
danke für deine Nachricht. An die Komprimierung habe ich natürlich nicht gedacht, hatte nur den Cache gelöscht. 
Ich konnte jetzt eine Testbestellung generieren. Das mail_order_step-Mail kommt automatisch (allerdings von Thunderbird als Spam markiert). Beim Klick auf den Button "Auftragsbestätigung" kommt mehrere Sekunden die Sanduhr und dann HTTP 500 Error. Das mail-order-Mail wird auch nicht verschickt. Ich denke, ein fehlerhaftes Passwort ist nicht die Ursache, denn der SMTP-Server ist ja erreichbar..
Im mod_error_2020-03-04.log ist kein Eintrag mit passendem Zeitstempel. Im Server-Log von IONOS stoße ich nur auf Traffic-Statistiken. Was kann ich tun, um Infos zur Ursache zu erhalten?

Beim PDFBillnext-Update habe ich die neuen (zusätzlichen) Dateien überschrieben. Die geänderten Dateien wurden zuvor durch das Shopupdate überschrieben, hier habe ich den jeweiligen Code erneut eingebaut.

Viele Grüße
Jens

[Timm]

Kann es sein, dass das pdf bill next modul immer noch nicht upgrdated wurde und die Änderung für das neue phpmail enthält?

https://www.modified-shop.org/forum/index.php?topic=12939.msg355113#msg355113

Gruß Timm

[JPW]

Hallo Timm,
das Posting kenne ich und die Änderungen hatte ich bereits ausgeführt.
Du verbeißt dich gedanklich so auf das PDFBillnext-Modul. Das ist aber nicht für die Auftragsbestätigung zuständig. Oder sehe ich irgendeinen Zusammenhang nicht?
Ich hatte ja eher die PayPal-API im Verdacht. Wir nutzen PayPal-Link, hier wird ja immer der individuelle Bezahl-Link in der Auftragsbestätigung "abgebildet". Aber ich habe keinen Hinweis auf ein Kommunikationsproblem gefunden.

Viele Grüße
Jens

[Timm]

Der Zusammenhang wäre, dass bei der Auftragsbestätigung die Rechnungs-Pdf angehangen wird. So ist es zumindest bi meinem pdf Modul.

Ich hatte ehrlich gesagt nur gelesen, dass die Order_mail_step gesendet wird und somit angenommen, dass alle normalen Shopmails funktionieren. Und dachte, dass du eine Auftragsbestätigung über das pdf Bill Modul meinst. Sorry-Nutze pdf Bill next selbst nicht.

Das mit der Paypal API kannst du ja recht schnell ausschließen, wenn du mal eine Bestellung mit anderer Zahlungsweise erstellst.

Es muss nicht unbedingt ein error sein. Vielleicht steht auch was in mod_warning oder mod_warning_admin. Hast du bei Ionos Zugriff auf das Logverzeichnis was eine Ebene über dem Shoproot liegt? Da findet man oft mehr Infos als im Shopbackend.

Gruß Timm

[JPW]

in der mod_warning_admin habe ich das gefunden:

[2020-03-05 01:43:18]   [warning]   [modified]   [pid:91750]   Use of undefined constant TEXT_IMAGE_NONEXISTENT - assumed 'TEXT_IMAGE_NONEXISTENT' (this will throw an Error in a future version of PHP) in File: /homepages/3/d677661278/htdocs/admin_xxxxxxxxxxx/includes/functions/general.php on Line: 397   {}   {}

Das deckt sich mit dem Fehlerzeitpunkt. Jedoch kann ich damit nichts anfangen.

Viele Grüße
Jens

[JPW]

Update:
Da die Zeit drängt, habe ich die 2.0.5.0 neu installiert. Als einziges externes Modul kam die dhlgkapi dazu.
Wieder HTTP 500 Error beim Versenden der Auftragsbestätigung! Derselbe Fehler kommt aber auch bei normalem Mailversand über Kunden - Kunden - EMail.
Da sicher kein fehlerhafter PHP-Mailer im Paket war, liegt der Fehler wohl irgendwo in der Datenbank, den ich mir vermutlich beim Update eingetreten habe. Aber auch hier weiß ich mir nicht zu helfen. Wie kann man das fixen?

Viele Grüße
Jens

[Timm]

Vielleicht das hier?

Re: modified eCommerce Shopsoftware 2.0.5.0 rev 12487 veröffentlicht

bzw mit changeset in Ticket #1726

Ich würde die 2.0.5.0 nicht produktiv einsetzen oder alle bereits gelösten Tickets für 2.0.5.1 durchgehen und die changesets runterladen und auf den server hochladen.

Gruß Timm

[Timm]

Fehler bei "Auftragsbestätigung senden" im Adminbereich

[JPW]

Vielleicht das hier?

Re: modified eCommerce Shopsoftware 2.0.5.0 rev 12487 veröffentlicht

bzw mit changeset in Ticket #1726

Vielen herzlichen Dank, Timm! Das war die Lösung. Bei uns ist gerade allgemeines Aufatmen.

Viele Grüße
Jens

[Timm]

Das freut mich zu hören.

Zieh dir die anderen changesets aber lieber auch. Vor allem das mit dem compactor damit du die Komprimierung wieder einschalten kannst ohne die weiße Seite im checkout zu haben.

Gruß Timm

[JPW]

Hallo Timm,
die general_bottom.js.php habe ich ebenfalls angepasst. Jedoch muss die HTML-Komprimierung aus bleiben, sonst kommt die checkout_shipping.php wieder als weiße Seite.

Viele Grüße
Jens

[Timm]

Hallo Jens

Trotz der angepassten compactor.php?

Seh grad nicht den Zusammenhang deiner Aussage mit der general_bottom.js.php und meiner Aussage zur compactor.php 

Jedenfalls kann das ja kein Dauerzustand sein die html Komprimierung auszuschalten.

Im Ticket 930 wurde nach dem changeset nochmal was geändert wegen weißer Seite bei Umlauten in eingebundenen Sprachdateien zb. Vielleicht hast du Umlaute statt entities in Sprachdateien die auf der checkout_shipping eingebunden werden.

Gruß Timm

[JPW]

Ich nahm an, du meintest das:
Tutorial: Template eines xt:Commerce Shops in der modified eCommerce Shopsoftware weiter verwenden - Korrektur der JavaScript Komprimierung im Template

Ich habe das Changeset r12501 aus Ticket #930 eingepflegt, aber die HTML-Komprimierung muss trotzdem aus bleiben.

Viele Grüße
Jens