ZP14 > Formular > Could not instantiate mail function.

Hallo Andre G. ,

bei welchen Hoster bist Du? Wir haben das Thema gerade auch in einem anderen Thread, aber mit Zeta 13 und PHP 7.1.26. Hierzu existiert von mir bereits eine Testveröffentlichung mit genau den gleichen Versionen auf einem 1&1 Server ohne Fehlermeldung. Auf unserer eigenen Seite (Zeta 14.3.3 und PHP 7.2) eben auch nochmal ein Testformular (via php) eingebaut, auch dieses funktioniert auf einem 1&1 Server.

Du kannst ja mal mit meiner php-info auf der Vereinshomepage vergleichen, dort läuft Zeta 14 unter PHP 7.2.

ich würde jetzt nur "mcrypt" ausschließen wollen, da dieses in 7.1 abgekündigt und offiziell in 7.2 nicht mehr vertreten ist. Da gehe ich davon aus, dass dies bei Zeta 14 bereits berücksichtigt ist. Habe aber in diesem speziellen Fall nicht die passende Testumgebung, da 1&1 "mcrypt" auch in der 7.2 noch unterstützt.

Hallo,

ob alle benötigten PHP-Module / -Funktionen vorhanden sind, sollte von "Website-Features prüfen" erkannt werden. Also am besten zunächst mal "Extras > Optionen > Aktionen > Website-Features prüfen" ausführen.

Danach dann im error.log des Web-Servers schauen ob es da mehr Details zum fehlerhaften Formularversand gibt.

Wenn das nix bringt, bitte im Formular in "Optionale Einstellungen" nach unten scrollen und die Option "DEBUG Ausgabe" aktivieren (nicht vergessen, das später wieder zu deaktivieren). Danach dann veröffentlichen, das Formular "live" absenden und ggf. die Debug-Ausgabe beachten.

Auf diese Art sollte man eigentlich genau ermitteln können, was schief läuft.

Wenn beim Versand ein Fehler auftritt, sollte das Debug-Protokoll im Browser ausgegeben werden.

Auf dem Server liegt in assets/php/formmailer/ eine Datei namens "debug.inc.php". Diese können Sie auch mal öffnen und beide Werte von false auf true stellen, damit ggf. mehr Fehler-infos ausgegeben werden.

Ich glaube, Sie haben recht und die Formular-Option betrifft nur die DEBUG-Ausgabe, wenn SMTP aktiviert ist. Aber mit obiger Einstellung sollte man mehr sehen. Ansonsten error.log auf dem Server…

Hmm, da scheint ein Fehler im Formular vorzuliegen. Da müsste ich die Seite mit dem Formular sehen können.

Also ich habe mir lokal mal PHP 7.2.15 installiert und ein Testprojekt unverändert geladen. Es funktionierte sowohl mit, als ach ohne SMTP-Option bestens. An PHP 7.2liegt es also definitiv nicht.

Könnten Sie dem Formular testweise bitte noch ein paar weitere Felder spendieren, nicht dass wir hier einen Edgecase haben, der nur Auftritt, wenn ein Formular lediglich 1 Feld definiert hat.

Auf den Xdebug Debugger komme ich von hier aus nicht drauf. Mir erschließt sich nicht, was hier genau vorgeht und mir fehlt auch die Zeit, dies zu debuggen. Wenn Sie diesen Fall man mit einem richtigen Projekt haben, schauen wir uns das ggf. gerne via Support-Ticket an. Sorry.

Ja, wenn ich das wüsste. Schicken Sie mir doch interessehalber mal Ihr Projekt, mal sehen, ob es bei mit unter 7.2 läuft:

1. Öffnen Sie Ihr Projekt in Zeta Producer
2. Gehen Sie auf das Menü "Extras"
3. Klicken Sie auf den Button "Optionen"
4. Klicken Sie auf "Aktionen"
5. Klicken Sie rechts auf die Aktion "Projekt Senden" damit diese Markiert ist
6. Klicken Sie unten auf den Button "Ausführen"
7. Geben Sie im 1. Feld Ihre E-Mail-Adresse ein, damit wir Sie für Rückfragen kontaktieren können
8. Geben Sie als Referenz ins Feld Bemerkungen den Link zu diesem Forum-Artikel ein(per Kopieren und Einfügen)
9. Klicken Sie auf den Button "Senden"

Also hier sendet es gleich ohne Fehler. Vermutlich haben Sie nun auch bereits 3 Testmails erhalten.

Würde mal sagen, die PHP-Version, die Sie da installiert haben ist nix. Die Ursache kann ich aber nicht ermitteln (zu Aufwändig).

Moin, da bin ich aber froh, dass ich nicht der Einzige bin den es auf diese Art erwischt hat (Sorry Unkown)

Ich bin der Meinung es steht alles bereits in #13 was man braucht.
Jedoch bin ich kein PHP Spezi, mein Lehrgan liegt 13 Jahre zurück.
Aber es wird doch klar, dass der Fehler vom Script /functions.php erzeugt wird, in Zeile 34

if ( isset(Configuration::$conf_smtp_useSmtp) && Configuration::$conf_smtp_useSmtp == "0" ){

header("Location: $errorPage?e=". urlencode($e->errorMessage()));

}

die;

Jetzt fragt sich der Laie, warum sich die Schleife auf SMTP bezieht, das ja nicht aktiv ist, sondern Send py PHP.

Das Scipt kann den Header für die Email nicht schreiben ... daher habe ich das Mal in das PHP Forum geschrieben.

Vielleicht kommt dort eine Antwor.

Bei mir hat sich leider auch nichts geändert, nachdem ich die Debug-Datei aktiviert habe.
Auf der Webseite kommt kein Fehler, jedoch lautet der String immer noch:
/nachricht-konnte-nicht-versendet-werden.html?e=%3Cstrong%3ECould+not+instantiate+mail+function.%3C%2Fstrong%3E%3Cbr+%2F%3E%0A

Sie das im Browser aussieht, siehe bitte Anlage.

Ich habe genau den gleichen Zustand wie hier Unknow!
Nur das ich auf 7.1.26 fahre, ansonsten genau alles so wie von Unknow beschrieben.

Vom Update auf 7.2 haben wir erst Mal abstand genommen.
Merkwürdig ist, dass wir die Seite auf einen anderen Server hoch geladen haben , ebenfalls mit PHP 7.1.26, dort tatsächlich aber alles funktioniert!
Wir haben die Ausgabe von phpinfo auf beiden Seiten verglichen, es gibt "keinen" Unterschied!
Unsere Lösung, bis zur Umstellung auf Wordpress = SMTP.

Unser technischer Hoster hat uns bestätigt dass alles korrekt umgesetzt wurde.

Das Unix System, auf dem unser Webserver läuft, ist auch aktuell gepflegt.

Wirklich merkwürdigt ..

Hallo newbusinessvision mit dem Header für SMTP hat die erwähnte "Warning" (kein Fehler) nichts zu tun (header() sendet einen http-header z.B. um die Seite umzuleiten). Ob Sie den gleichen Fehler wie Unknown haben ist nicht klar, sie haben ggf. lediglich die gleiche Fehlermeldung.

Der Fehler sollte übrigens auch in einer Datei phperrors.log protokolliert werden. Dort steht aber wahrscheinlich auch nur "Could not instantiate mail function" drin. Der Fehler weist meist darauf hin, dass der php mail()-Befehl nicht funktioniert oder der Provider die benutzte E-Mail-Adresse dafür nicht zulässt (um sich vor Spammern zu schützen). Siehe auch: https://duckduckgo.com/?q=phpm…ail+function&t=osx&ia=web

Erst gestern hatte ich so einen Fall in einem Support-Ticket und da war die Ursache, wie meist, die als Formular-Empfänger definierte E-Mail-Adresse. Der Provider hat info@domain zugelassen, spezialadresse@domain (konfigurierte Adresse) aber nicht…

Ich denke, bei Ihnen könnte der Versand über SMTP auch gut funktionieren (funktioniert ja bei Andre G. ) und das würde den Fall sicher abkürzen.

Bitte aktivieren Sie die SMTP-Option oder nutzen Sie ggf. ein Premium-Support-Ticket damit wir das direkt auf ihrem Server prüfen können…

Besten Dank!

HI

OK; dann reduzieren wir das auf "gleiche Fehlermeldung".
Das habe ich damit ja auch nicht sagen wollen, sondern nur dass dort der Fehler erzeugt wird und dann habe ich als Ansatz den Code hier notiert.
Nichts weiter wollte ich damit aufzeigen.

Wo finde ich die phperrors.log?

Danke, auf das habe ich ja selbst hingewiesen in meinem eigenen Beitrag, das ist jetzt ja auch nur eine Widerholung.
Die Links von Stackoverflow kenne ich alle und hatte ich in meinem Beitrag bereits auch genannt

Um das Problem auszuschliessen haben wir bereits eine Domain-Eigene Emailadresse genommen, auch wenn das eigentlich nicht gewünscht war, hat aber auch nix gebracht!

Hinzu gekommen ist nun, was das Fass zum überlaufen bringt, dass ReCapcha meldet: Fehlerhinweis für Inhaber der Website: Schlüsseltyp ungültig

Den Schlüsseltyp und das Schlüsselpaar nutzen wir bereits seit langer Zeit, da kann nix falsch sein.
Zum wird ReCapcha plötzlich nur noch auf einem von 3 Formularen angezeigt, obwohl in allen 3 Formularen aktiviert.

Was ist denn mit dem Programm los, das gab es ja noch nie ... *stöhn* ... jedoch konnten wir das jetzt schnell lösen in dem wir das raus genommen haben, Sinn der Aktion ist das aber nicht.

Zudem haben wir auf einem weiteren Testserver vielleicht ein Hinweis gefunden, der jedoch im Zusammenhang mit der Aktivierung von SMTP erscheint:
=>Deprecated: Function mcrypt_module_open() is deprecated in /var/www/vhosts/xxxxxxx.de/httpdocs/assets/php/formmailer/functions.php on line 427

Scheinbar hängt es doch mit dem Script zusammen, dass hier eine veraltete Funktion in PHP nutzt!

Jedenfalls sagt das diese Meldung aus.

Somit ist auch SMTP für uns keine Lösung, da es dabei zu diesem Fehler kommt *kotz*

Direkt gefragt: Kann es nicht doch sein, dass es in Ihren erzeugten PHP Scripts ein Problem gibt, dass gewisse alter / neue Funktionen innerhalb der PHP Versionen nicht sauber abfängt / erkennt?

Anbei das PHP Error Log meines Kollegen.

Nachtrag: SMTP

Keine Lösung!

Wir haben es jetzt mit den Einstellungen von Web.de, von Hotmail und Apple versucht, sowie unseren eigenen Servereinstellungen.

Immer nur wieder => SMTP Error: Could not authenticate.

Unknown schrieb:

newbusinessvision ,

Wo das Problem genau liegt habe ich noch nicht herausgefunden.

Da mir das Problem aktuell nur auf meinem privaten System aufgefallen ist, kann ich damit leben, mich auf den SMTP Versand zu beschränken, was vielleicht auch vorteilhafter/sicherer ist.

Mein System benötigt für einige andere Webanwendungen noch PHP 5.6 sowie PHP 7.2. Allerdings stehen mir keine aktuelleren Versionen als die 7.2.13 zur Verfügung.

Ich habe ein eigenes Script, sowie Wordpress und noch andere Generatoren zum Versand getestet, auch da hatte ich meine Probleme mit 7.2.13.

Da Stefan S ein von mir zuvor voll funktionierendes Projekt für funktionsfähig beglaubigt hat, bleibt halt die Tatsache, dass meine derzeit aktuelle PHP Version fehlerhaft ist.

Scheinbar ist der vermutliche Bug in der Version 7.2.15, die Hanabi verwendet beseitigt. Anders kann ich es mir nicht erklären.

Alles anzeigen

Danke, genau deshalb haben wir ja "nicht" auf 7.2 umgestellt, um das Thema Bug auszuschliessen
Zudem läuft es ja auf anderen Servern mit 7.1.26.

Und da uns der Hoster aktuell bestätigt hat, dass alles korrekt eingestellt ist, bleibt es für mich bei der Vermutung, siehe meinen letzten Post, dass es an ZETA liegt.

Denn SMTP geht ja leider auch nicht und diese Fehlermeldung ist ja sehr deutlich

Happy Wochenende

Unknown schrieb:

Nur was ich komisch fand und darauf schließen ließ, dass es an Zeta lag ist, dass ich Matomo und eine Helpdesksoftware auch mit 7.2 ohne Probleme betreibe.
Gerade Matomo, die haben ja auch eine Systemprüfung und darüber versende ich auch Auswertungen.

Wie bei mir! Genau wie bei mir!
4 Verschiedene Systeme laufen bei mir, keines hat nach der PHP Umstellung ein Problem, auch nicht ZETA, erst nachdem, siehe in meinem eigentlichen Posting, ich die Seite (Projekt) bearbeitet hatte und neu hoch geladen habe. Zuvor hatten wir irgendwann auf Zeta 13.3.0 umgestellt, wann aber genau weiss ich nicht mehr.
Ab diesem Moment funktionierte garnix mehr, weder SMTP, noch PHP Mail, noch ReCapcha ...

PS: Verzeichnis: zp-server > code > log´s - gibt es bei mir nicht.

Unknown schrieb:

Dann wurden noch keine Logs geschrieben.
Wenn Log´s geschrieben werden, hast du ein Verzeichnis mit Log´s.

Aktiviere mal deinen Shop, dann werden massig Daten geschrieben.

hi, ich denke wir haben unterschiedliche systeme, daher gibt es das verzeichnis so nicht bei mir.
ich habe einen ubuntu server mit apache webserver auf einem echten root server, so wie diverse andere server.

auch nutze ich eine andere Softwareversion ... die 13.3.0 Express, ich denke da gibt es diese verzeichnisse nicht.

dennoch danke für den tipp

newbusinessvision schrieb:

Zudem haben wir auf einem weiteren Testserver vielleicht ein Hinweis gefunden, der jedoch im Zusammenhang mit der Aktivierung von SMTP erscheint:
=>Deprecated: Function mcrypt_module_open() is deprecated in /var/www/vhosts/xxxxxxx.de/httpdocs/assets/php/formmailer/functions.php on line 427

Scheinbar hängt es doch mit dem Script zusammen, dass hier eine veraltete Funktion in PHP nutzt!

Jedenfalls sagt das diese Meldung aus.

Ich vermute, Sie haben die Einstellungen in debug.inc.php beide noch auf dem Wert true stehen? Falls ja, bitte wieder auf false stellen und nochmals SMTP testen. Die zitierte Meldung ist nämlich eigentlich nur ein Hinweis und keine Fehlermeldung und sollte daher auch zu keinem Abbruch führen (der müsste ggf. andere Ursachen haben). Wenn der SMTP-Versand nicht auf anhieb klappt, in den Formulareinstellungen die DEBUG-Option.

Ansonsten, wie bereits vorgeschlagen, ein Premium-Support-Ticket nutzen.

Stefan S schrieb:

Ich vermute, Sie haben die Einstellungen in debug.inc.php beide noch auf dem Wert true stehen? Falls ja, bitte wieder auf false stellen und nochmals SMTP testen. Die zitierte Meldung ist nämlich eigentlich nur ein Hinweis und keine Fehlermeldung und sollte daher auch zu keinem Abbruch führen (der müsste ggf. andere Ursachen haben). Wenn der SMTP-Versand nicht auf anhieb klappt, in den Formulareinstellungen die DEBUG-Option.

Ansonsten, wie bereits vorgeschlagen, ein Premium-Support-Ticket nutzen.

Moin

Nein, es steht aktuell wieder auf "false"!
Siehe oben unseren Nachtrag.

Nachtrag: SMTP

Keine Lösung!

Wir haben es jetzt mit den Einstellungen von Web.de, von Hotmail und Apple versucht, sowie unseren eigenen Servereinstellungen.

Immer nur wieder => SMTP Error: Could not authenticate.

Ich habe ja angegeben, dass wir das auf einem Testserver ausprobiert haben, um den Fehler vielleicht eingrenzen zu können.