[GELÖST] SMTP-Fehler bei Bestellabschluss

[Frixi]

Hallo maennchen1-Team,

wurde bei der Version 3.12.7 irgendetwas am Mail-Versand geändert? Seit Samstag bekomme ich etwa zweimal am Tag eine Kundenrückmeldung, dass beim Klick auf "kostenpflichtig bestellen" ein SMTP-Fehler auftrat - die Bestellung ist dann auch nicht abgeschlossen, sondern steht unter unvollständig. Vom Kunden gemeldeter Fehler: SMTP connect() failed. https://github.com/PHPMailer/PHPMailer/ ... leshooting - ich konnte diesen bei einigen Testbestellungen nicht nachvollziehen.

Ich hatte bis Samstag das Modul WP Mail SMTP aktiv, dieses aber nach den ersten Fehlermeldungen deaktiviert und seither arbeitet wieder der ganz normale WP-Mailer, trotzdem tritt das Phänomen weiterhin täglich auf.

Mein Provider meint, dass zu diesen Bestellungen (Zitat): "eine SMTP-Verbindung die geöffnet wurde, aber wie beim letzten mal, keine Daten kamen". Kann hier ein zusätzliches Debugging aktiviert werden?

Für einen zielführenden Tipp bedanke ich mich bereits jetzt ganz herzlich...

PS: hier ein Auszug der PHP-Einstellungen, falls das hilft:
PHP Version : 5.6.36
PHP Memory Usage: 23.51 MB
PHP Memory Limit : 256M
PHP Max Upload Size : 512M
PHP Max Post Size : 64M
PHP Allow URL fopen : On
PHP Allow URL Include : Off
PHP Display Errors : Off
PHP Max Script Execution Time : 120 Seconds

PPS: bei der Bestellbearbeitung mit Rechnungsversand per Mail ist mir das Problem noch nicht untergekommen. Kann Zufall sein... oder wird beim Bestellabschluss etwas anderes gemacht?

[maennchen1.de]

Hallo!
Die gemachten Änderungen findest du hier: https://wpshopgermany.maennchen1.de/201 ... ny-3-12-7/
Wir haben nichts am Mailverhalten verändert.
Eventuell "funkt" ein anderes Plugin dazwischen?

[Frixi]

Danke für die schnelle Rückmeldung, das Changelog hatte ich mir schon angesehen, aber dort wird ja eher wage beschrieben, was passiert ist, aber nicht wo genau... nur das es keine veränderten Templates gab.

[ThoGoe]

Hallo!

Bitte prüfe einmal, ob andere Plugins das Problem verursachen. Für unsere Liste der inkompatiblen Plugins wäre diese Erkenntnis wichtig. Danke!

Liebe Grüße

[Frixi]

Hallo ThoGoe,

wenn der Fehler dauerhaft reproduzierbar wäre, würde ich das gerne testen, aber es betrifft aktuell nur einen kleinen Prozentsatz der Bestellungen.

[Frixi]

Der SMPT-Fehler kommt nach wie vor unregelmäßig vor und mein Provider kann das Problem nicht lokalisieren - das Einzige, was in den Logs zum Zeitpunkt des Fehler steht ist:

Code: Alles auswählen

2018-06-20 13:32:36 SMTP connection from [127.0.0.1]:37878 (TCP/IP connection count = 8)
2018-06-20 13:32:38 SMTP connection from [127.0.0.1]:37878 closed by QUIT

Wie geschrieben trat der Fehler mit dem Plugin WP Mail SMTP auf, wie auch mit dem original WP-Mailer, der seit letzter Woche wieder aktiv ist.

Der Support schließt mittlerweile eine Fehlfunktion des Servers nahezu aus, weshalb ich es mal mit einem Downgrade von WPSG versuchen muss, da der Fehler tatsächlich (zufällig?) mit dem Update auf .7 erschienen ist.

Da sich ja laut Changelog nichts an der Datenbankstruktur von .6 auf .7 geändert hat, sollte es doch möglich sein, das vorhergehende Shop-Modul wieder einzusetzen und nur den Eintrag in der Datenbank ändern, der auf die Version hinweist. Könntet ihr mir verraten, wo das in der Datenbank gespeichert ist?

[maennchen1.de]

Ein Downgrade ist nicht vorgesehen und sollte maximal durch wiederherstellen der Dateien/Datenbank aus dem Backup erfolgen.
Die Mühe kannst du dir aber sparen, da wir nichts an den Mailverfahren gemacht haben, wir übergeben die Daten sauber an WordPress. Hier gäbe es evtl. einen Ansatz, sofern WordPress etwas geändert hat, was ich aber nicht glaube.
Das gepostete Systemlog ist IMHO auch keine Fehlermeldung, sondern ein klassisches Verhalten deines MTA.
Bei Verbindungsabbrüchen solltest du in erster Linie immer Sicherheitseinstellungen überprüfen (Plugins, Firewall, IDS, WFA).

[Frixi]

Wie gesagt, aktuell rätseln alle Beteiligten, wann, wie und warum der Fehler auftritt, ein "Protokoll" (außer dem obigen) gibt es offenbar nicht, in dem ein Grund nachvollzogen werden könnte.

Zur Fehlertoleranz könnte aber von eurer Seite etwas beigesteuert werden: der SMTP-Fehler unterbricht die Bestellung nach Kundenrückmeldungen direkt nach dem Klick auf "kostenpflichtig bestellen", d. h. es wird wohl zuerst versucht, die Bestellbestätigungen zu versenden, dann wird die Bestellung auf "eingegangen" gesetzt. Genau dieser letzte Punkt fehlt beim Auftritt des Fehlers, die Bestellung bleibt unter "unvollständig" stehen, sodass es auch für mich keinen Hinweis zu einem Abbruch gibt. Hätte ich eine eingegangene Bestellung ohne Bestellbestätigung, wüsste ich, dass der Fehler aufgetreten ist.

Wäre es sehr kompliziert, die Reihenfolge zu ändern? D. h. zuerst bei der Bestellung den Status "eingegangen" zu setzen, dann die Mails zu versenden?

[maennchen1.de]

Damit kannst du es doch einkreisen! Das Script wird dann wahrscheinlich komplett abgebrochen. Vergleiche doch bitte einmal die entsprechenden Bestellungen, ob es hier eine Gemeinsamkeit gibt.
Würde die Mail erst versendet werden, nach der Datenbankeintrag erfolgt, kann es passieren, dass gar keine Mail versendet wird, weil beim Eintrag in die DB etwas schief läuft. In deinem Fall wäre das noch schlimmer.

[Frixi]

Leider lassen sich überhaupt keine Gemeinsamkeiten erkennen, außer, dass es sich um das beliebteste Set handelt und mit PayPal bezahlt wird. Aber das ist aufgrund der Häufigkeit schon kein besonders genaues Muster und konnte mit Testbestellungen (auch von den betroffenen Kunden) nicht bestätigt werden.

Gäbe es eine Möglichkeit, den Fehler beim Auftreten mit einer Fehlerseite abzufangen? Im Prinzip ein On-Error-Goto-Seite?

[Frixi]

Ich teste eben das WP-Plugin Post SMTP, denn dieses erstellt ein Protokoll aller Mails, die versendet werden. Wenn ich über ein Kontaktformular oder andere Bereiche gehe, die eine Mail versenden, ist der Status "Sent", nur bei den WPSG-Mails steht als Status immer "No body specified". Es gibt dann einen Resend-Button, der die Mail nochmals verschickt, diese kommt dann aber im Quelltext an.

Könnte die Meldung No body specified einen Hinweis auf einen Fehler in euren Mails geben?

[Frixi]

Nachtrag: wenn ich die Mails in den erweiterten Shop-Einstellungen auf Plain-Text stelle, meldet das o. g. Post SMTP Plugin keinen Fehler, die Mail wird korrekt versandt, egal, ob Bestellbestätigungen, oder Änderungen am Status.

Wenn ich mir die Test-HTML-Mail des SMTP-Plugins ansehe, steht im Header folgendes:

Code: Alles auswählen

Content-Type: text/plain; charset = "UTF-8"
Content-Transfer-Encoding: 8bit

Hello!

Sent by Postman 1.8.9 - https://wordpress.org/plugins/post-smtp/

Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Diese Angaben kann ich in den HTML-Shop-Mails nicht finden. Und es werden NUR die Shop-Mails mit "No body specified" deklariert, Kontaktformulare etc. werden einwandfrei versandt.

[Frixi]

Gerade teste ich den Mail-Versand mit dem Plugin WP Mail Bank, hier tritt der Fehler mit "No body specified" mit den HTML-Mails von WPSG nicht auf. Ich weiß immer noch nicht, macht WPSG hier etwas besonderes (HTML-Kontaktformulare gingen ja auch mit Post SMTP), oder ist das neue Plugin fehlertoleranter?

Ungeachtet dessen, könntet ihr hierzu Stellung nehmen:

Gäbe es eine Möglichkeit, den Fehler beim Auftreten mit einer Fehlerseite abzufangen? Im Prinzip ein On-Error-Goto-Seite?

[maennchen1.de]

Alle Mails gehen durch eine Funktion, welche die Ersetzungen (Platzhalter, HTML, etc) vornimmt und diese dann an die WordPress eigene Funktion wp_mail() übergibt.
Wenn Fehler geworfen werden, werden die ins wpShopGermany-Logfile (Konfiguration > Über > Fehlerprotokoll) geschrieben.

Eine "On-Error-Goto-Seite" gibt es in der Form, dass dir die weiße Seite angezeigt wird bzw. hier die Debug-Meldungen ausgegeben werden.

[Frixi]

Ich habe den Fehler gefunden!

(Etwas) Asche auf mein Haupt: durch einen Serverumzug hat sich die Adresse des Mail-Servers verändert, welche auch im Newsletter-Modul (SMTP Versand) hinterlegt war, woran ich mich gar nicht mehr erinnern konnte. Alle Kunden, die in der Bestellung das Newsletter-Abo angeklickt haben, sind auf den im ersten Post genannten Fehler gestoßen, wie ich nun selbst testen konnte.

Ja, der Fehler saß zum Teil wieder nur einen halben Meter vom Bildschirm entfernt, ABER: bitte baut in das Newsletter-Modul eine Fehler-Exception ein, dass nicht einfach die komplette Bestellung abbricht, wenn der Server nicht erreichbar ist.

Ich bin darauf gekommen, weil ich mir verschiedene Einstellungen in der Datenbank angekuckt habe und dort viel mir zuerst auf, dass ihr das SMTP-Passwort im Klartext speichert. Nicht gut! Und erst dann viel mein Blick auf den Eintrag mit dem alten SMTP-Server...

Nun ja, jetzt geht es wieder, auch mit Newsletter-Haken, aber bitte kümmert euch um die Fehlertoleranz und Passwörter sollten niemals im Klartext gespeichert werden, das sollte doch mittlerweile als selbstverständlich gelten.