Alles anzeigenHallo,
ich habe festgestellt, dass es z.Zt. nicht mehr möglich ist, auf unserer website ein Kontaktformular zuzusenden. Es erscheint eine Fehlermeldung: HTTP ERROR 500.
Ich kann damit allerdings nichts anfangen. Wie behebe ich diesen Fehler?
Vielen Dank für die Auskunft im Voraus
Matthias Dickmann
Die Zugriffsrechte sind nicht korrekt eingestellt
fehlerhafte Zugriffsrechte zeigen sich eher als "403 Error", die 500-er Gruppe ist beim Ionos-Support ganz gut erklärt. Trotzdem kann es sich lohnen, zunächst die Datei- und Ordnerberechtigungen mitttels Filezilla zu prüfen.
Ordnerrechte sollte für das Verzeichnis /assets/php/formmailer auf "705" oder "755" stehen. Die Dateiberechtigungen im Ordner sollten für alle Dateien auf "604" stehen. Wenn diese beiden Werte stimmen, im Serverprotokoll nachsehen, ob sich dort ein Eintrag findet. Hilfsweise eine eventuell vorhandene .htaccess im Root-Ordner umbenennen, um diese zu deaktivieren.
Hallo,
ein 500er Fehler bedeutet meist, dass ein Skript nicht ausgeführt werden konnte oder einen Fehler enthält. In diesem Fall, das Skript, welches das Formular versenden sollte.
An die genaue Fehlerursache kommt man nur auf dem Webserver. Dieser schreibt meist genauere Fehlerdetails in eine Protokoll-Datei, die meist error.log heißt. Erkundigen Sie sich bitte bei Ihrem Provider, ob und wo Sie so ein Protokoll auf dem Webserver finden. Darin sollten wir dann nach den genaueren Fehlerdetails suchen.
Wichtig ist zunächst auch, dass Sie mal generell die Server-Voraussetzungen prüfen, also ob überhaupt die für den Formularversand notwendigen Skriptsprachen auf dem Webserver verfügbar sind. Das geht so (lassen Sie uns das Ergebnis hier wissen):
p.s. 
Wenn ich mir meine Protokolldateien anschaue, sind das für mich spanische Dörfer. Damit kann ich nichts anfangen.
Ggf hat der Provider die php-Version geändert.
Das wissen wir ja auch nicht, wir versuchen ja nur zu helfen. Sehen Sie denn im Fehlerprotokoll Einträge bezüglich "SendEmail.php"? Wenn ja, könnte es uns ggf. helfen, wenn Sie ein paar dieser Einträge hier im Beitrag per Kopieren und Einfügen mit uns teilen.
Hallo borgwardc ,
Im Moment des Absendens versucht das Script "SendEmail.php" eine Aktion auf dem Server auszuführen. Irgendetwas auf dem Server verhindert diese Aktion aber. Wir hier im Forum können aber auf Deinen Server nicht rauf schauen und daher auch nicht sagen, was dort nicht stimmt. Erster Ansprechpartner ist daher Dein Provider one.com.
Der Verdacht von Uwe ist eine durchaus denkbare Möglichkeit, falls bisher für die Domain PHP 5.6 oder 7.0 aktiviert waren. Beide Versionen haben zum 31.12.2018 Supportende gehabt, da kann es sein, dass der Provider auf 7.2 umgestellt hat.
Theoretisch kann folgendes möglich sein: Falls das Formular von Zeta 13.3.0 die Funktion "mcrypt" verwendet, so ist diese in PHP 7.2 nicht mehr vorhanden. Einige Provider binden "mcrypt" auch in die 7.2 mit ein, bei Dir wird "mrypt" aber nicht auf der PHP-Info angezeigt. Ob es tatsächlich daran liegt, kannst Du über das Control-Center Deines Providers herausfinden. Dort wählst Du statt der aktuellen 7.2 die PHP-Version 7.1, die sollte noch "mcrypt" enthalten.
Sieht so aus, als ob Ihr Provider die PHP sendmail() Funktion nicht benutzt. In dem Fall kann das Skript keine Mails über den Webserver versenden. Bliebe nur der Ausweg, das über einen eigenen Mailserver zu versuchen: https://docs.zeta-producer.com…e-per-smtp-versenden.html
Wenn one.com Ihr Provider ist, steht hier mehr Info:
https://help.one.com/hc/de/articles/115005594345
Laut dem Artikel muss die im Formular konfigurierte Adresse (Formular-Empfänger) ein aktives Konto auf Ihrer one.com Domain sein. Wenn das nicht der Fall ist, wäre der Fehler oben zu erklären. In dem Fall hilft die im selben Artikel beschriebene, zweite Methode.
Bietet Ihr Provider denn keinen Support an?
Habe auf PHP-Version 7.1 umgestellt. Nun erscheint die Fehlermeldung: Could not instantiate mail function.
Habe eben bei einem anderen Supportfall mit dem selben Provider festgestellt, dass die Meldung "Could not instantiate mail function." dann erscheint, wenn im Formular eine Empfänger-Adresse definiert ist, die nicht über one.com gehostet wird.
Siehe Hinweis "Beachten Sie, dass die "An" oder "Von" Adresse ein aktives E-Mail-Konto auf Ihrer One.com Domain sein muss." unter https://help.one.com/hc/de/articles/115005594345
Die Empfänger-Adresse legt man im Formular-Widget im Feld "Empfänger-E-Mail" fest.
Auf Basis dieser neuen Infos können wir nur raten? Sie sollten uns zumindest sagen, wer und was seit dem letzten umstellen auf PHP 7.1 mit dem Fehler "Could not instantiate mail function." verändert wurde. Mich würde auch interessieren, ob der Provider nicht helfen will, oder bisher noch gar nicht um Hilfe gebeten wurde.
Hallöchen
Ich habe genau den gleichen bzw. einen sehr ähnlichen Fall.
Wir haben eine funktionierende Webseite mit Zeta 13 und haben diese, nach Umstellung von PHP 7.0 (veraltet) auf jetzt neu 7.1.26 , neu hoch geladen.
Alles sah bisher gut aus, bis wir versucht haben unsere Formulare abzusenden.
Fehler: Nachricht konnte nicht versendet werden.
Im String des Browsers steht das hier:
https://www.meine-webseite.de/…erden.html?e=%3Cstrong%3ECould+not+instantiate+mail+function.%3C%2Fstrong%3E%3Cbr+%2F%3E%0A
Die Emailfunktion per PHP ist auf dem Server aktiviert und hat zuvor ja auch funktioniert.
Die Webseite wird per SFTP und privatekey Option vom PC auf den Webserver übertragen, was bisher auch keine Probleme verursachte.
Im Formular nutzen wir die Option Via PHP".
Nun sind wir ganz schon irritiert!
Von ZETA PRODUCER haben wir keinerlei Infos (Newsletter) etc. erhalten, dass die Umstellung einer PHP Version, die sogar in der gleichen Versionsgruppe erfolgt, wir reden hier ja nicht von einem Masterchange wie PHP5 auf PHP 7, solche Probleme verursachen kann.
Wir sind jetzt ganz schon aufgeschmissen!!!!
PS: Der Kollege hat den Hinweis gegeben von ONE.com, bitte noch Mal genau lesen 
Auch ich habe als Empfängeradresse eine andere Adresse als die der Domain. Doch dies ist grundsätzlich kein Problem bei uns, da es hier keine Restriktiongibt!
newbusinessvision Wie ist denn Ihre Webadresse und bei welchem Provider sind Sie denn?
Genereller Hinweis: Provider passen Ihre Sicherheits-Einstellungen und Restriktionen, wie z.B. die Einschränkung auf von Ihnen gehostete E-Mail-Adressen (oder Adressen, die über das Verwaltungs-Interface eingestellt sind), immer wieder mal an. Über solche Änderungen könnten wir gar nicht informieren, weil uns diese Änderungen nicht bekannt sind.
Lieber Stefan S
1. Wollte ich den Hinweis geben, das hier technisch ein sehr ähnlich gelagertes Problem auftaucht und das bei einer Seite, die bis dato ohne Probleme lief.
Vielleicht sollte Sie Ihre automatisch erstellten PHP Scripte überprüfen?
Vielleicht sollten Sie einen Test durchführen und versuchen den Fehler zu reproduzieren?
2. Ich betone gerne noch Mal dass es keine Änderungen in den Einstellungen gab oder gibt, warum Sie das jetzt hier zum Thema machen verstehe ich nicht.
Es wurde auf dem Server "einzig" von einer PHP Version auf die andere PHP Version umgestellt; was hat das nun mit anderen Einstellungen aka Restriktionen zu tun?
Nichts!
3. ZETA PRODUCER sollte nicht über die Änderungen eines Hoster informieren, sondern ggf. darüber, dass bei der Umstellung von einer PHP Version auf die Andere ggf. Probleme auftauchen könnten.
Es ist doch schon sehr sonderbar dass bei uns Beiden der gleiche Fehlerkern auftritt, nachdem wir auf eine andere, höhere PHP Version umgestellt haben.
Grundsätzlich erwarte ich jetzt eine Lösungsfindung von ZETA PRODUCER, denn die hoch geladene Homepage hatte ja bis zu diesem Zeitpunkt bei uns gut funktioniert.
Gerne lade ich die Seite auf den ZETA PRODUCER Test-Server hoch um das nachvollziehen zu können.
Dazu müsste dort aber die entsprechende PHP Version eingestellt sein.
Und warum beantworten Sie meine Fragen nicht?
Es ist doch schon sehr sonderbar dass bei uns Beiden der gleiche Fehlerkern auftritt, nachdem wir auf eine andere, höhere PHP Version umgestellt haben.
Es ist auch sonderbar, dass anscheinend in beiden Fällen die Seite bei one.com gehostet ist. Zur Eingrenzung, ob der Fehler bei Zeta oder bei one.com zu suchen ist, habe ich unter test.hanabi-pirna.de mit Zeta 13.3.0 ein Projekt hochgeladen. Eingestellte PHP-Version ist die 7.1.26. Der Formularversand funktioniert fehlerfrei.
Bei einer mit Zeta 13.3.0 veröffentlichten Seite auf einem Server mit PHP 7.1.26 kommt es nicht zwangsläufig zu einem "Could+not+instantiate+mail+function".
Interessant ist in diesem Zusammenhang, dass beim Server vom http://oldtimerclub-lachendorf.de bereits im ersten Abschnitt der PHP-Info ein wesentlicher Unterschied zu http://test.hanabi-pirna.de festzustellen ist:
als geladene Konfigurationsdatei wird auf die /etc/php/php-7.0.ini verwiesen, bei meiner Testseite ist es /etc/php7.1/php.ini
Da könnte es durchaus sein, dass in der ini für die 7.0 Werte drinstehen, die bei der 7.1 so nicht verwendet werden. Also bitte mal one.com mit ins Boot holen.
Lieber Stefan S
Weil Sie meine Webseite nichts angeht und ich den Link hier nicht posten will.
Zudem liefert die Info zum Provider keinerlei Lösungsansatz, daher bin ich darauf nicht eingegangen.
Wir sind nicht bei One.com - stehen aber in engen und guten Kontakt zum Hardwareprovider und betreiben dort auch eigene Server.
Uns wurde bestätigt, dass das Update korrekt gelaufen ist und die Einstellungen auch so wie zuvor sind.
Ich habe den Fehlerlink ja bereits gepostet; denke das sollte fachlich reichen.
Wie Sie sehen können hat Hanabi den Fall auch verstanden und bereits einen sehr guten Ansatz geliefert.
Mein Angebot haben Sie sicherlich überlesen, denn dann hätten Sie sich die Frage schenken können, damit hätten Sie den Domain-Namen ja erhalten
Hanabi : Nein, siehe bitte mein Text, meine Webseite ist nicht bei One.com! Dennoch ist Ihre Vorgehensweise sehr gut! Sowas hätte ich jetzt vom ZETA Support erwartet Aber, so die Meinung der PHP Experten, ist das der falsche Ansatz. Denn der Weg ist genau anders rum. Es ist vollkommen korrekt dass beim Aufruf der neuen Version in der php.ini das 7.1 steht, denn das ist ja die neue PHP Version die mit dem Update aufgeladen wurde. Alle anderen Versionen gelten - lt. offizieller Mitteilung - als veraltet und unsicher.
Tatsächlich, wie beschrieben, sind wir nicht bei One.com - stehen aber in engen und guten Kontakt zum Hardwareprovider und betreiben dort auch eigene Server.
Daher habe ich eine Domain mit 7.0.33 installiert und dort steht, wie von Ihnen schon festgestellt, als Pfad => /.../.../php/7.0
In der Domain, um die es hier geht, steht im Pfad => /.../.../php/7.1
Also alles so wie es sein soll nach einem Update / Upgrade, denn ich will ja die neue PHP Version nutzen und nicht die Alte.
Etwas verwundert mich in Ihrer Auswertung.
Wie kann 7.2.16 installiert sein, aber die php.ini immer noch die 7.0 sein?
Auch wundert mich der Punkt, dass der Versand bei Ihnen ja funktioniert, mit den gleichen Einstellungen wie bei mir.
Ebenfalls ist auch UTF-8 freigegeben (so wie im Emailformular als Option angeklickt) und alle weiteren PHP Module sind ON.
Es gibt keinerlei Einschränkungen oder Restriktionen!
In Summe ist dies nun eigentlich der Ansatz den ZETA klären muss.
Scheinbar gibt es in PHP 7.1 eine Änderung, die sich auf das Script, dass ZETA PRODUCER 13 erzeugt, auswirkt.
Das haben Sie ja bereits mit Ihrer Auswertung bewiesen.
Danke für Ihren sehr guten fachlichen Ansatz!
Ich melde mich zu der Sachlage noch Mal, wenn ich die Page auf das System mit 7.0.33 geladen habe.
Hallo Kai,
bitte den Teil zur PHP-ini genau lesen:
bei der php-info von http://oldtimerclub-lachendorf.de/ (bei one.com) findet sich der Verweis auf die "/etc/php/php-7.0.ini" als Konfigurationsdatei, obwohl die php-info die Version 7.1.26 ausgibt. Hier liegt meiner Ansicht nach ein Fehler vor, der durch den Hoster zu prüfen wäre.
Dass Sie nicht bei one.com sind, geht aus den bisherigen Beiträgen nicht hervor. weder haben Sie Ihren Hoster konkret genannt noch einen Link zu Ihrer Seite gepostet. Sie haben aber daruf bestanden, dass Sie das selbe Problem haben.
Zur Vorgehensweise:
Der Support von Zeta ist schon hervorragend. Er ist jedoch darauf ausgelegt, das Produkt "Zeta Producer" zu unterstützen. Die Software ist tausendfach im Einsatz, über die Zahl der mit Zeta Producer 13 veröffentlichten Homepages kann man nur spekulieren, wir können aber davon ausgehen, dass es hier um eine beträchtliche Größenordnung geht. Hiervon wiederum laufen diverse Seiten völlig problemlos auf Servern mit PHP 7.1.26. Wenn jetzt ein generelles Problem mit dieser PHP-Version auftreten würde, wäre das Forum voll von Meldungen. Ist es aber nicht.
Daher erfolgte kein Nachbau. Mein Nachbau bestätigt lediglich, dass es bei einer Standardkonfiguration eines Servers mit PHP 7.1.26 (in diesem Falle beim Massenhoster 1&1) und Erstellung einer Webseite mit Zeta 13.3.0 nicht zu einem Problem beim Formularversand kommt.
Wir sind also wieder beim Hoster, egal ob dieser nun one.com oder in Ihrem Falle anders heißt, dieser muss zur Problemlösung mit ins Boot.
Bei der Seite von borgwardc haben wir eine php-info vorliegen, ebenso bei meiner Seite. Wenn ich beide mal grob überfliege, fallen mir, trotz gleicher Versionsnummer, diverse Unterschiede auf. Zum einen fehlt mir aber die Zeit, beide Versionen Zeile für Zeile zu vergleichen und auf Relevanz zu prüfen (dazu fehlen auch die Kenntnisse), zum anderen wäre es wesentlich zielführender, hierzu noch die php-info Ihrer Seite zu haben, damit die Analyse in folgende Richtung gehen kann:
Vergleiche Seite A mit B und C, finde hierbei die Einträge, in denen sich A und B unterscheiden, der entsprechende Eintrag bei B aber auch bei C vorhanden ist. Das ist dann rein analytisches Vorgehen, bei dem ich keine PHP-Kenntnisse brauche. Ob die dann gefundenen Unterschiede eine Auswirkung auf das Problem haben, darum können sich dann die Entwickler kümmern.
Ich bin nach mehr als 4 Jahren Nutzung über verschiedene Versionen von Zeta sehr zufrieden. In der gesamten Zeit sind vielleicht 3 oder 4 mal Probleme aufgetaucht, die tatsächlich durch das Programm verursacht wurden, davon die Hälfte Fehler, die Features betreffen, die nur auf Wunsch einzelner Nutzer aufgenommen wurden. Deshalb reagiere ich etwas angekratzt, wenn "aus dem Nichts" Probleme auftauchen, die - wenn tatsächlich vorhanden - das Forum zum Absturz bringen würden; aber gleich im ersten Beitrag sich darauf versteift wird, dass Zeta einen Fehler hat.
In diesem Sinne bitte ich zu entschuldigen, wenn dieser Beitrag stilistisch auf "klare Kante" angelegt ist.
Hallo newbusinessvision ,
auf dieser Basis kann ich Ihnen leider nicht helfen.
Hallöchen
Leider bleibt es beim Problem nach der Umstellung auf /etc/php/php-7.0.ini bei PHP Version 7.0.33 => Could+not+instantiate+mail+function
Leider bleibt es beim Problem nach der Umstellung auf /etc/php/php-7.1.ini bei PHP Version 7.1.26 => Could+not+instantiate+mail+function
Ich will und werde hier den Domain-Namen nicht posten und verbleibe bei meinem Angebot die Seite auf den Test-Server hoch zu laden.
Dazu gab es leider kein Feedback!
Scheinbar wird überlesen dass ich ja "deutlich" geschrieben habe:
Wir sind nicht bei One.com - stehen aber in engen und guten Kontakt zum Hardwareprovider und betreiben dort auch eigene Server.
Uns wurde bestätigt dass das Update korrekt gelaufen ist und die Einstellungen auch so wie zuvor sind.
Ein Vergleich beider php.ini zeigt keinerlei Unterschied, bis auf die gelinkte PHP Version.
Mag sein dass dies einfach überlesen wird, aber dann bitte hinterfragen Sie das doch bitte nicht jedes Mal, das ist nicht zielführend.
Auch habe ich geschrieben dass alle Module in PHP ON / ENABLED sind, das sollte doch reichen, oder?
Was One.com da macht ist mir schleierhaft, denn das ist ja absurd auf eine 7.0 zu verweisen wenn eine 7.1 installiert ist.
Doch wie man nun sieht, ergibt das ja auch leider keine Lösung, denn bei uns ist das so wie bei Ihnen, funktioniert aber dennoch nicht.
Wenn Andere hier fleissig Ihre wichtigsten Server-Interna posten ist das ja deren Sache, doch ich werde das nicht machen.
Wäre schade wenn wir nun doch auch bei dem Rest unserer Seiten auf Wordpress umsteigen müssten, denn wir nutzen ZETA bereits seit der ersten Version.
Das wird wohl nicht Jeder von sich behaupten können hier im Forum
An uns hat die Firma schon recht gut verdient, würde ich hier frech behaupten wollen!
Bei
ist es ja wohl nun so, so lese ich den letzten wichtigen Eintrag, dass es an der mail() Funktion liegt, was ich mir aber eigentlich nicht denken kann, da es laut
ja bis davor funktioniert hat und ich kenne keinen Hoster der mail() nicht unterstützt.
Ich wiederhole:
Wir haben einzig das getan was Jeder tun sollte, wir haben unsere PHP Version aktualisiert.
Dies ist ein Standartvorgang - die Grundeinstellungen wurden weder verändert noch sonst was daran unternommen.
Dann haben wir die Seite mit der Zeta Version 13.x geöffnet (Projekt) und ein neues Formular eingefügt und die Seite neu hoch geladen.
Alles hat funktioniert wie zuvor auch, bis auf die Formulare, die nun diesen Fehler produzieren.
Wie also kann ich weitere sachdienliche Hinweise zur Lösung liefern?
Nicht sicherheitskritische Infos aus der phpinfo wären möglich, sind jedoch bereits gegeben worden, auch wenn dies scheinbar überlesen wird.
Oder sollte ich lieber ein Ticket beim Support aufmachen?
Bisher war dies noch nie nötig, JA .. das spricht eigentlich für diese Software, von der wir bis dato ja auch FAN waren
Doch ist dies jetzt aktuell der Gau und es besteht eigentlich jetzt nur noch die Möglichkeit auch diese Domain auf Wordpress umzustellen, damit wir schnell wieder korrekt online sind.
Eigentlich hatten wir das nicht vor, auch wenn dies bei 90% unserer X Seiten bereits der Fall ist.
Danke will ich hier sagen, denn das mit dem PHP und der php.ini war ja ein guter Ansatz.
Scheinbar, schaut man sich Mal ein wenig um, ist dies aber nicht nur bei ZETA ein Problem, sondern in der Erzeugung des Codes für das PHP Skript selbst:
https://stackoverflow.com/ques…instantiate-mail-function
https://stackoverflow.com/ques…-why-this-error-occurring
Liest man den einen oder anderen Eintrag, kommt man ggf. zur Erkenntnis, dass ZETA den PHP Code des Skriptes anpassen muss.
should be changed to
This worked for my case..
Dies ist nur Einer der vielen möglichen Ansätze.
Tatsächlich ergeht daraus auch der bereits genannte Ansatz, dass die Emailadresse für den Empfänger eine sein muss, die der Domain gehört.
Das ist befremdlich und muss ich testen, denn dies ist ja bei uns der Fall (Email-Empfänger ist nicht gleich Domainname.de).
Anders könnte ich auch auf SMTP ausweichen, was wir aber eigentlich nicht wünschen, doch wenn es hilft, würden wir unser Problem damit lösen!
Hallo newbusinessvision ,
auf dieser Basis kann ich Ihnen leider nicht helfen.
TRAURIG ... da hat man seit so vielen Jahren Mal ein Problem und dann sowas ... fachlich guter und freundlicher Support sieht anders aus.
Aber Ihr Ton hat mir eh nicht gefallen, Danke ... ich gebe das Mal so an den Verkauf weiter ... storniere ich doch gleich mal den Kauf der aktuellen Version ...
Vielleicht hat es ja ZETA nicht mehr nötig höflich und zuvorkommend zu bleiben ... gut so, haben wir wieder Geld gespart.
Nehmen Sie sich lieber ein Beispiel an Hanabi
Ihre Formular funktioniert gerade auf Ihrem Server nicht. Also muss die Seite auch dort getestet werden. Es wäre ein schlechter Test, Ihre Seite auf einem anderen Server mit völlig anderer Umgebung und Webserver-Einstellungen zu testen. Das würde zu nichts führen.
Wenn Sie eine Lösung wollen, biete ich Ihnen an uns das Projekt (inkl. funktionierender FTP-Einstellungen) zu senden (das FTP-Passwort können Sie gerne vor und nach meinen Tests ändern), damit wir das Projekt ansehen können und ein paar Tests auf dem Server durchführen können. Wenn Sie das auch nicht möchten, kann ich wirklich nicht helfen, weil mir schlicht die Datenbasis dazu fehlt, den Fehler zu ermitteln.
Falls Sie uns das Projekt zusenden möchten, geht das so:
Ihre Kritik bzgl. meinem Ton können Sie gerne weitergeben. Ich fand meinen Ton bisher aber absolut sachlich und kann auch nicht erkennen, welche Aussage "unhöflich" gewesen sein sollte.
Danke das Sie doch noch die Kurve bekommen, ... das liest sich doch schon viel besser!
Es war ja auch nur eine Idee, dies ggf. auf einem anderen Server mit den gleichen PHP Einstellungen zu testen.
Wenn dies aus Ihrer Sicht, ich habe hier eine andere Sichtweise, zu nichts führt, dann können wir uns einfach vom Ergebnis überraschen lassen.
Ich werde dies mit einem meiner eigenen Server auf einem anderen Hoster / technischen Plattform einfach Mal ausprobieren.
GERNE schicke ich Ihnen das Projekt, das ist doch jetzt mal wirklich ein guter Vorschlag den ich schon vorher ähnlich erwartet habe.
Aber vielleicht habe ich im Stress und im Ärger ggf. Ihre Hinweise und Fragen falsch gedeutet.
Jedoch, da der Server private-key verschlüsselt ist (siehe #21), kann ein SFTP nicht funktionieren, wäre das nun ein Problem?
Vermutlich Ja.
Ich bin ebenfalls Dienstleister und wenn Sie mit "auf dieser Basis kann ich Ihnen leider nicht helfen." kommen, dann sollten Sie das auch näher beschreiben, so wie Sie dies jetzt ja super getan haben.
Dieses "Und warum beantworten Sie meine Fragen nicht?" kann man schon mal in den falschen Hals bekommen, wenn man vorher angedeutet hat dass man gewisse Infos nicht preisgeben will, nicht preisgeben kann (weil z. B. private-key = hohe Sicherheit) - die nach meinem Empfinden auch technisch nicht viel helfen würden. Doch auch dies ist ggf. meiner Aufregung geschuldet.
Lassen Sie mich ggf. jetzt erst Mal den anderen Server und die Sache mit dem SMTP versuchen, dann können wir ja gerne noch Mal schreiben.
ThanX
Die SMTP-Option in den Formular-Einstellung sollte das Problem mit sehr hoher Wahrscheinichkeit auch umgehen und wäre die präferierte Lösung.
Das Zusenden und analysieren von Projekten bieten wir eigentlich nur im Rahmen eines Premium-Support-Ticket an, daher kam der Vorschlag nicht gleich. Bei hohem Support-Aufkommen, fehlt uns oft einfach die Zeit für nicht sachbezogene Kommunikation und wir erwarten einfach, dass uns überlassen wird, wie wir helfen und ggf. unsere Fragen beantwortet werden. Das führt dann eigentlich auch immer zu einer Lösung.
Habe eben bei einem anderen Supportfall mit dem selben Provider festgestellt, dass die Meldung "Could not instantiate mail function." dann erscheint, wenn im Formular eine Empfänger-Adresse definiert ist, die nicht über one.com gehostet wird.
Siehe Hinweis "Beachten Sie, dass die "An" oder "Von" Adresse ein aktives E-Mail-Konto auf Ihrer One.com Domain sein muss." unter https://help.one.com/hc/de/articles/115005594345
Die Empfänger-Adresse legt man im Formular-Widget im Feld "Empfänger-E-Mail" fest.
Hallo Stefan S ,
Sorry, dass ich mich einfach mal so reinhänge!
Da ich bei mir selber schalten und walten kann, würde mich auch interessieren, Welche Einstellungen aktiv sein müssen, um das senden der Nachricht über das Formular zu ermöglichen.
Ich bekommen ebenfalls den Fehler "Could not instantiate mail function." nach der Umstellung von 5.6 auf 7.2.
Ich habe die Einstellungen von 5.6 übernommen und mir sind keine Abweichungen aufgefallen. Ich habe das Problem zwar über das Senden via smtp gelöst, welches ich auch vorziehe, doch wissen würde ich schon gern, wo es klemmt.
Ihr könnt ja sicherlich sagen, wo die Unterschiede der der PHP Versionen liegen, die das Formular zum versenden brauch.
Andre G. ich antworte im von Ihnen neu geöffneten Beitrag: ZP14 > Formular > Could not instantiate mail function.
Hallo Matthias,
bei inzwschen 39 Beiträgen zu dem Thema fällt es mir schwer, noch den Überblick zu behalten. In die ursprüngliche Fehlerdiskussion sind inzwischen mehrere User eingestiegen mit einem "gleichartigen", aber nicht "gleichem" Poblem eingestiegen. Ich halte es daher für zielführend, den Thread aufzuspltten. Umsetzung erfolgt in den nächsten Minuten, wenn ich wieder am großen Rechner und nicht mehr am Tablet sitze.
