Beiträge von newbusinessvision

    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.

    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 :)

    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.

    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

    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.

    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 ..

    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

    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

    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

    borgwardc

    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

    borgwardc

    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/questions/1297…e-mail-function

    https://stackoverflow.com/questions/1944…error-occurring

    Liest man den einen oder anderen Eintrag, kommt man ggf. zur Erkenntnis, dass ZETA den PHP Code des Skriptes anpassen muss.

    Code

    should be changed to

    Code

    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!

    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.


    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.


    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/nachricht-konn…?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!

    Hallo Leute

    Vielen Dank für die neuen Ideen und Feedbacks.
    Ich werde das mal gleich alles ausprobieren und mich dann mit einem Update melden! :)

    Update:
    Und die Lösung lautet .... DANK AN TIRILA für den Gedankenanstoß ... die PHP Version ist scheinbar zu hoch.

    Wer sich mal an einem Downgrade versuchen will, hier für PLESK ein Info-Link:
    http://blog.emyhost.com/2013/01/how-to…rsion-in-plesk/
    Man hat mir aber davon abgeraten.

    Ich habe das Paket, wie wir es die Jahre zuvor auch getan haben, mit SFTP per FileZilla auf unseren alten Server geladen.
    Dieser ist zu 100% gleich mit dem neuen Server, nur dort läuft noch PHP 5.2 und somit auch das Skript.
    Es erscheint korrekt die hinterlegte Erfolgsseite und die Mails kommen auch an.
    Dumm nur, dass wir diesen Server ja gerade abschalten wollen.

    Dennoch DANK an Euch für die tollen Ideen und die schnelle Reaktion, das zeichnet dieses Forum echt aus!
    Daumen hoch :thumbup:

    Was ich noch getan habe und bestimmt eine gute Info für Euch ist:
    Ich habe ein anderes Emailformular von "phpFormGenerator" hoch geladen auf den aktuellen Server.
    Und das läuft ohne Probleme!
    Muss dann doch irgendwie am Quellcode liegen, oder?

    Was nun?
    Dies bedeutet, dass wir überlegen müssen, ob wir doch (obwohl uns das neue Layout der Software überhaupt nicht zusagt) auf ZP12 umsteigen?
    Was uns davon abhält ist die leidige Tatsache, dass auch mit ZP12.2.0 eine gerade erzeugte Testseite nicht auf dem neuen Server funktioniert :cursing:
    Und das, obwohl ich nun alle Anregungen in der neuen Seite umgesetzt habe.
    Es erscheint nach dem Absenden des Formulars nur wieder eine weiße Seite bzw. beim IE der Fehler 500 und in der Browserzeile ist der Link:
    http://www.hardwareplattform.de/ZP12/media/Scr…endEmail.php?sc
    zu sehen.

    TEST: http://www.hardwareplattform.de/ZP12

    Tja, ... da fällt einem nix mehr ein.

    @sT.
    Gute Idee, kann ich ja gerne noch mal parallel dazu austesten.
    Denke aber, da das Skript auf dem alten Server läuft, sowie das Skript von phpFormGenerator auch, dies nichts zur Lösung beiträgt.
    Und Du hast das was falsch verstanden.
    Ich habe geschrieben -> Der Fehler tritt nach einem neuen Upload der Webseite auf.
    Da gab es ja zwischenzeitlich ein Update für ZP 10.
    Ob und wann dann genau der Fehler aufgetreten ist, können wir nicht mehr genau nachvollziehen.
    Ich weiß nur, dass ich in ZP10.7.1 auf erstellen geklickt habe und die Page dann auf den Server hochgeladen hatte.
    Dann wollte ich testen ... und nix passierte.
    Daher liegt die Vermutung nahe, da am Server ja nix geändert wurde, bis auf dass der neue Server eine höhere PHP Version hat, dass ZP10 nach dem letzten Update auf 10.7.1 die Seiten nun anders erstellt (Quellcode, Script, ...)

    @sseiz
    Also, wenn wir nicht strukturiert vorgegangen sind, dann wie sonst bitte :)
    Aber ja, ich muss mal sehen, bestimmt kann ich das PHP Error-Log irgendwie auswerten.
    Fehler 500 steht ja u. a. für Programmierfehler :)
    Das habe ich aber bisher nicht geschafft bzw. gefunden wie es geht.
    Mit der Email ist ne gute Idee und Danke für das tolle Angebot, darf ich aber laut Aussage ZP nicht, da ich ja keinen Wartungsvertrag habe.
    Und mal ehrlich, da kauft man sich eine Software für fast 200 Euro und soll dann auch noch 1.99 Euro pro Minuten für die Hotline zahlen.
    Sorry, dazu fällt mir nix nettes ein.

    Der UWE
    Ich gebe auch zu bedenken, dass nur bei Uwe die Email oben funktioniert hat.
    Und dort auch nur die Email, die ich auf dem Zeta Server veröffentlich habe.
    Da Uwe aus dem gleichen Subnetz zugreift, denke ich das dies irgendwie damit zu tun haben könnte.
    Andere Testpersonen erhalten dort aber "auch" nur die Fehlerseite, wie man oben am Bild vom Mittwoch erkennen kann!
    Bedeutet, auch dort läuft was nicht richtig, denn bei mir und anderen Testpersonen kam keine Email an und wir alle erhielten nur die Fehlerseite zu sehen!
    Das so noch mal am Rand erwähnt!

    Wenn ich darf, dann würde ich echt mal mit ZETA Support per Email Kontakt aufnehmen und mal schauen lassen, ob die Kollegen sich das erklären können.
    Vielleicht können die Kollegen ja auch was für sich mitnehmen ... an neuer Erfahrung :)

    LÖSUNG (22.03.2015)

    Ein guter Linux Admin mit PHP und Apache Erfahrung hat die Lösung innerhalb weniger Minuten gefunden.
    Wie von SSEIZ vorgeschlagen mal das PHP LOG durchforstet :)
    Es lag also nicht nur an der PHP Version, sondern auch noch zusätzlich an:

    -->> Es hat eine PHHP Bibliothek gefehlt (mcrypt).

    Ich habe nun auch gesehen, dass es dazu bereits einen Post hier gibt, den ich aber leider nicht in Bezug setzen konnte.
    https://community.zeta-producer.com/Thread/5134-Su…mular#post25607

    Die Lösung ist also = die Bibliothek nachinstallieren und den Server neu starten :thumbup:

    Nebeninfo an ZP Admin:

    Was auch immer dazu führt, wir haben einen Test mit dem folgenden Link gemacht:
    http://hosting.zeta-producer.com/customer-27784…93/kontakt.html

    1 von 3 Leuten kann das Formular absenden.
    Diese Person stammt nicht, wie die anderen 2, aus Berlin, sondern aus Rheinland-Pfalz.

    Besucher-IP-Adresse: 95.90.97.12
    Besucher-Hostname: ip5f5a610c.dynamic.kabel-deutschland.de

    Das ist doch merkwürdig!

    Für mich ist der Fall somit abgeschlossen.

    DANKE

    Hallo Jochen

    Danke für den Hinweis, habe ich gerade im DEMO Ordner neu hoch geladen.
    Aber leider kein Erfolg.
    Wieder nur die bekannte Fehlermeldung bzw. eine leere weiße Seite.

    Ich dachte, es liegt vielleicht auch an der fehlenden index.html, daher habe ich jetzt eine entsprechende Seite eingefügt, aber auch kein Erfolg.
    Die wird nicht mal angezeigt, obwohl jetzt die index.html als Seite für Fehler und OK konfiguriert ist.

    Das Mailscript endet immer mit dem Link

    1) http://www.hardwareplattform.de/demo/media/Scr…r/SendEmail.php
    2) http://www.hardwareplattform.de/demo/media/Scr…r/SendEmail.php?sc

    und der leeren Seite und keine Email kommt an.

    Komisch ist, dass es bei UWE ja jetzt bereits 2 x geklappt hat, wenn er die Version von dem Upload auf die Zeta-Producer Webseite nutzt.
    Aber wenn meine Leute das testen, passiert nix.
    Was kann der Uwe anders machen als ich und meine Leute.
    Und warum geht es bei Uwe auf der Zeta-Producer Homepage und bei uns nicht.

    Ggf. einen anderen Browser nutzen, aber wir haben jetzt bereits Firefox, Chrome und IE durch.

    Ich bin jetzt gerade kurz vor Nervenende und würde am liebsten diese Software, die ja nicht billig war, in die Mülltonne hauen. *grrrrr*

    Hi Uwe

    Ich erhalte bei http://hosting.zeta-producer.com/customer-27784…93/kontakt.html aber einen Fehler => Seite "Nachricht konnte nicht gesendet werden".
    Siehe Bild.

    Was also machst Du anders als ich oder meine Kollegen?
    Wieso geht es nur bei Dir?
    Welchen Browser nutzt Du?

    Vielleicht hilft noch diese Info aus der Email:


    Besucher-IP-Adresse: 212.87.131.182
    Besucher-Hostname: gate-zeta-software.wan-stauferpark.imos.net

    Hallo Leute

    Vielen Dank für diese schnelle Reaktion! :thumbup:

    Ich darf mitteilen, wie immer das der "Uwe" gemacht hat, dass seine Email angekommen ist.
    War so frech Ihm mal direkt zu antworten und bin mal gespannt was er mir dazu sagen kann.
    Somit wird seine Frage auch beantwortet: Ja, ich habe als Antwortadresse eine korrekte Email hinterlegt :)

    Jochen, danke für den Tipp.
    Ich habe nun die Fehlerseiten beide mal einfach auch wieder auf diese "kontakt.html" gesetzt.
    Zuvor waren diese in ZP, wie die Jahre zuvor auch, auf die Standartseiten gesetzt, die auch mit dem Upload auf den Server mit hoch geladen werden.
    Daher verstehe ich es noch nicht ganz, weil ja die Email von Uwe bei mir angekommen ist.
    Im Moment weiß ich aber noch nicht, welches der beiden Formulare (Test1, Test2) bei mir angekommen ist.
    Damit das ab sofort aber besser ersichtlich ist, ändere ich jetzt mal schnell die Betreffzeilen.
    Da steht bei beiden im Moment leider "XXX TEST XXX" drinne.
    Das war bissle dumm von mir :)

    Danke Euch, ich werde dann noch ein Update schreiben.

    UPDATE:
    So, auf TEST1 und TEST2 sind jetzt die neuen Uploads fertig.
    Bei mir hat es leider nix gebracht, keine Email kommt an ;(

    Falls es noch wichtig ist - ich übertrage per SFTP mit meinem FTP Progrogramm (FileZilla), da wir eine hohe Sicherheitsstufe auf dem Server haben.
    Ich nehme dazu die Daten aus dem Ordner "Ausgabe", wenn ich zuvor in ZP auf "Webseite erstellen komplett" geklickt hatte.
    Das mache ich schon seit über 2 Jahren so, daher denke ich, dass dies nicht unbedingt wichtig ist, es kommt ja auf das gleiche raus :)

    Jochen, sorry, natürlich habe ich jetzt auch die "Veröffentlichung" korrekt konfiguriert.
    Da hatte ich zuvor noch den Zeta-Server drinne.
    Aber, dadurch das ich selbst per FTP übertrage, war mir das nicht aufgefallen.
    Dennoch habe ich mal einen Upload nach diesem Schema gemacht:
    http://www.hardwareplattform.de/demo/kontakt.html
    Gleicher Effekt, nix kommt an.

    Hallo Leute

    Vorab, JA ... ich habe nach dem Thema gesucht, aber keine klaren und verständlichen Antworten gefunden.
    Auch kann und will ich keine neue Version kaufen, das Geld wächst mir nicht aus den Ohren.

    Folgendes ist passiert:

    Nachdem wir schon vor einiger Zeit auf "Skript: Via PHP" als Emailversendung im Formular unter den Einstellungen von ZP 10 umgestellt hatten, werden unsere Formulare nun nicht mehr verschickt und man landet immer wieder auf einer Fehlerseite bzw. leeren Webseite des Webservers. Es scheint zwar so, als ob die Emails raus gehen, aber dies passiert nicht. Bis vor wenigen Wochen ging alles noch. Der Fehler tritt nach einem neuen Upload der Webseite auf.

    Ich habe mir die Daten des Webservers mal notiert:

    PHP Safe Mode ON
    PHP register_globals OFF
    PHP ausführen als Apache Modul
    PHP Version 5.5.9

    Ein Test mit einem anderen PHP Script (PHP-Info und Formmailer) verlief erfolgreich!
    PHP ist also aktiv und funktioniert auch.

    Folgendes fällt mir auf:

    1) Setze ich das Formular auf "Skript: Via PHP", dann wird der folgende Link nach Klick auf Absenden ausgeführt:
    http://www.hardwareplattform.de/TEST1/media/Sc…endEmail.php?sc

    Es erscheint eine leere Webseite ohne Fehlermeldung im Firefox und mit dem IE 11 kommt der Fehler HTTP 500 ...

    Für einen Test könnt Ihr hier klicken:
    http://www.hardwareplattform.de/TEST1/kontakt.html

    2) Setze ich das Formular auf "Skript: Via PHP mit Sicherheitsprüfung", dann wird der folgende Link nach Klick auf Absenden ausgeführt:
    http://www.hardwareplattform.de/TEST1/media/Sc…r/SendEmail.php? 

    Es erscheint, nach der Eingabe des Captcha, eine leere Webseite ohne Fehlermeldung im Firefox und mit dem IE 11 kommt der Fehler HTTP 500 ...

    Für einen Test könnt Ihr hier klicken:
    http://www.hardwareplattform.de/TEST2/kontakt.html

    3) Nutze ich die Veröffentlichung auf Zeta-Producer, dann kommt wenigstens die Seite "Nachricht konnte nicht gesendet werden":
    http://hosting.zeta-producer.com/customer-27784…93/kontakt.html


    Ich bin ratlos im Moment und frage mich was ich falsch mache bzw. hier schief gelaufen ist?
    Sogar eine ganz neu erstellte Test-Seite funktioniert nicht.
    Habe das Gefühl, dass dies irgendwie am Code liegt, den ZP erzeugt.

    Wer kann ggf. helfen :?:


    Gruß und Dank

    Kai