formmailer
Schnubbi
- php
Hallo.
Ich habe vor kurzem meine HP erstellt. habe auch viel Hilfe aus diesem Forum bekommen. Danke ;)
Jetzt habe ich die HP auf den dafür vorgesehenen Server geladen. Leider funktioniert hier der Formmailer nicht. (http://rhein-wied.feg.de/formmailer.php) auf dem "Probeserver" hat es noch funktioniert. (http://neutorion.ne.funpic.de/hp16z/formmailer.php)
Liegt das an dem Server, dass er kein php kann, oder woran?
LG Christian
Hallo
Ich habe vor kurzem meine HP erstellt. habe auch viel Hilfe aus diesem Forum bekommen. Danke ;)
Jetzt habe ich die HP auf den dafür vorgesehenen Server geladen. Leider funktioniert hier der Formmailer nicht. (http://rhein-wied.feg.de/formmailer.php) ...
Liegt das an dem Server, dass er kein php kann, oder woran?
Doch doch, PHP kann er schon, sonst würde die Ausgabe der PHP-eigenen Fehlermeldungen auch nicht funktionieren. Aber offensichtlich existiert, unter der in der Fehlermeldung angegebenen Adresse, die Datei global_vars.php nicht. Überprüfe also zuerst die Pfadangabe im Aufruf in Zeile 102 der formmailer.php unter Zuhilfenahme der Fehlermeldung.
Tschö, Auge
Hallo
Doch doch, PHP kann er schon...
Gut, da bin ich schonmal beruhigt ;)
Überprüfe also zuerst die Pfadangabe im Aufruf in Zeile 102 der formmailer.php unter Zuhilfenahme der Fehlermeldung.
Leider kenne ich mich mit php null aus. In der zeile steht folgendes:
require_once ($_SERVER['DOCUMENT_ROOT'].$pfad."/global_vars.php");
Die datei globale_vars.php ist im gleichen Ordner wie der formmailer.php abgelegt. Was ist dann der Fehler? und wieso klappt es dann genausso bei funpic?
LG Christian
Hallo Schnubbi!
require_once ($_SERVER['DOCUMENT_ROOT'].$pfad."/global_vars.php");
Die datei globale_vars.php ist im gleichen Ordner wie der formmailer.php abgelegt. Was ist dann der Fehler? und wieso klappt es dann genausso bei funpic?
Vielleicht ist DOCUMENT_ROOT nicht Dein Webseiten-Verzeichnis (soll mal vorkommen...), während es bei funpic übereinstimmt.
Aber wenn eh alles im selben Ordner ist, dann dürfte es so auch klappen:
require_once ("global_vars.php")
Disclaimer: Diesen Tipp gebe ich Dir als nicht PHPler ;)
Viele Grüße aus Frankfurt/Main,
Patrick
Hey Patrik,
Vielleicht ist DOCUMENT_ROOT nicht Dein Webseiten-Verzeichnis (soll mal vorkommen...), während es bei funpic übereinstimmt.
Aber wenn eh alles im selben Ordner ist, dann dürfte es so auch klappen:
require_once ("global_vars.php")
Ich habs malso abgeändert:
require_once ("/global_vars.php");
Jedoch ist immer noch die gleiche Fehleranzeige da..
LG Christian
Hey Patrik,
require_once ("/global_vars.php");
ich habs grade exakt wie du es sagtes abgeändert ;) Also:
require_once ("global_vars.php");
Jetzt kommt:
Installationshinweis
Bevor Sie das Formular einsetzen, legen Sie bitte die HTML Template-Datei /home/rheinwie/htdocs//home/rheinwie/htdocs/templates/page.html an.
Jedoch ist diese html datei schon vorhanden...
LG Christian
Hallo Schnubbi!
Jetzt kommt:
Installationshinweis
Na das ist schon mal ein Fortschritt. Das ist keine PHP-Fehlermeldung mehr, sondern eine Fehlermeldung vom Skript (also eine vom Skriptautor eingebaute).
/home/rheinwie/htdocs//home/rheinwie/htdocs/templates/page.html an.
Fällt Dir da nichts auf? Der Pfad wird zwei mal vermerkt (und zwar hintereinander).
Du müsstest die Stelle im Skript, wo die page.html eingebunden wird bzw. gebraucht wird, entsprechend anpassen.
Der richtige Pfad müsste sein:
/home/rheinwie/htdocs/templates/page.html (vorausgesetzt, Du hast die page.html tatsächlich im Verzeichnis /templates abgelegt).
Viele Grüße aus Frankfurt/Main,
Patrick
Hey Patrick,
ich musste in global_vars.php von :
$html_template_file = $_SERVER['DOCUMENT_ROOT'].$pfad."/templates/page.html";
$form_file = $_SERVER['DOCUMENT_ROOT'].$pfad."/templates/feedback.inc";
$danke_file = $_SERVER['DOCUMENT_ROOT'].$pfad."/templates/danke.inc";
Zu:
$html_template_file = "templates/page.html";
$form_file = "templates/feedback.inc";
$danke_file = "templates/danke.inc";
ändern.
Jetzt klappts wohl :D
Vielen Dank!!
LG Christian
Hey Patrick,
Das Problem was ich jetzt sage hatte ich schon mal hier in nem anderen Eintrag ohne lösung Diskutiert. Vielleicht hast du ja ne lösung...
Die Mails, die ich über den formmailer verschicke, kommen nicht, bzw. ganz selten an.
Scriptausschnitt von formmailer.php:
# mail senden
$headers = "From: {$_POST['Vorname']} {$_POST['Zuname']} ";
$headers .= "<{$_POST['mail_from']}>\r\n";
$headers .= "Content-Type: text/plain; charset=iso-8859-1 \r\n";
$headers .= "Content-Transfer-Encoding: 8bit";
mail($kontakt_vars["mailto"], $kontakt_vars["subject"], ($_POST['message']), $headers);
Scriptausschnitt von global_vars.php:
# Konfigurations Teil #
$kontakt_vars = array();
$kontakt_vars["mailto"] = "_christ_@web.de"; # E_mail Empfänger
$kontakt_vars["subject"] = "Homepage-Kontaktformular"; # Den gewünschten Betreff für die Mail eingeben
Siehst du ein Problem?
Den Spamfilter hab ich sowie bei Web.de als auch bei meinem Outlook ausgestellt.
LG Christian
Hey Patrick,^^
Problem gelöst :D
Der stellt die Mails nur zu, wenn es die angegebene adresse des Sendenen auch wirklich gibt. meistens hatte ich es mit phantasieadressen probiert, wie zb. dsfjhds@web.de..Ich hoffe ich benötige deine/eure Hilfe erstmal nicht wieder ;)
LG Christian
Hallo Schnubbi!
Problem gelöst :D
Der stellt die Mails nur zu, wenn es die angegebene adresse des Sendenen auch wirklich gibt. meistens hatte ich es mit phantasieadressen probiert, wie zb. dsfjhds@web.de.
Dann veranlaßt der Provider einen DNS-Lookup. Scheint weit verbreitet zu sein.
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo Patrick,
»» meistens hatte ich es mit phantasieadressen probiert, wie zb. dsfjhds@web.de.
Dann veranlaßt der Provider einen DNS-Lookup.
offensichtlich weit mehr als das, denn ein "gewöhnlicher" DNS Lookup würde nur ergeben, dass web.de existiert. Aber vielleicht meinstest du, dass der Provider die SPF-Einträge im DNS abfragt und auswertet.
Scheint weit verbreitet zu sein.
Ja. Ist ja auch im Prinzip eine gute Sache.
So long,
Martin
Hallo Martin!
offensichtlich weit mehr als das, denn ein "gewöhnlicher" DNS Lookup würde nur ergeben, dass web.de existiert. Aber vielleicht meinstest du, dass der Provider die SPF-Einträge im DNS abfragt und auswertet.
Da musste ich erst mal gucken, was das ist. Aber schlauer als wie zuvor bin ich dennoch ;)
»» Scheint weit verbreitet zu sein.
Ja. Ist ja auch im Prinzip eine gute Sache.
Ja, wenn auch 1&1 es auf einmal eingeführt hatte, und danach schickte das unmögliche GB mir kaum noch Mails, weil die Besucher der Testversion nur Fake-Adressen angeben. Aber mit einem kleinen Trick dank Alexander(HH) tut es das GB dann doch ;)
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo
Die Mails, die ich über den formmailer verschicke, kommen nicht, bzw. ganz selten an.
Scriptausschnitt von formmailer.php:
# mail senden
$headers = "From: {$_POST['Vorname']} {$_POST['Zuname']} ";
$headers .= "<{$_POST['mail_from']}>\r\n";
$headers .= "Content-Type: text/plain; charset=iso-8859-1 \r\n";
$headers .= "Content-Transfer-Encoding: 8bit";
mail($kontakt_vars["mailto"], $kontakt_vars["subject"], ($_POST['message']), $headers);Scriptausschnitt von global_vars.php:
# Konfigurations Teil #
$kontakt_vars = array();
$kontakt_vars["mailto"] = "_christ_@web.de"; # E_mail Empfänger
$kontakt_vars["subject"] = "Homepage-Kontaktformular"; # Den gewünschten Betreff für die Mail eingebenSiehst du ein Problem?
Die Adresse _christ_@web.de ist die deine? Ansonsten sieht das erstmal, bis auf die für mich unbekannten Klammerungen (dazu unten mehr), normal aus. Zudem solltest in den Spamverzeichnis deines Web.de-Accounts schauen, ob die Emails dort abgelegt werden. Du kannst sie, falls das der Fall ist, dort als "kein Spam" markieren, sodass sie in Zukunft direkt in deinem Posteingang landen.
In der Variable $headers werden eingefügte Variablen im Text mit { und } umgeben. Normal wäre die folgende Art der Verkettung: $headers = "From: ".$_POST['Vorname']." ".$_POST['Zuname']."\r\n";
, zumal gerade in der von mir zitierten Zeile der abschließende Zeilenumbruch fehlte. Neben dieser Zeile ist die folgende anzupassen: $headers .= "<".$_POST['mail_from'].">\r\n";
. Auch der Funktionsaufruf für mail()
sieht etwas komisch aus. Lasse die Klammern ("(" und ")") um $_POST['message']
weg.
Tschö, Auge
Hello,
Die Mails, die ich über den formmailer verschicke, kommen nicht, bzw. ganz selten an.
Um was für einen Host handelt es sich? Linux oder Windows, ...?
Welches Mailprogramm wid dort benutzt?
Wird über Port 25 oder über ein Script gemailt?
Schau in deine phpinfo(), was dort eingetragen ist.
Wenn zum Mailversand ein sendmail-Script verwendet wird (also nicht wirklich Sendmail, sondern nur ein gleichnamiges Script), dann kann es sein, dass sich dieses über "\r\n" als Zeilenendezeichen beschwert bzw. eben darüber stolpert. Die SCRIPTE erwarten häufig nur "\n" und können mit "\r\n" in den erweiterten Headern bzw. den Attachments nicht umgehen.
Liebe Grüße aus Syburg
Tom vom Berg
Hallo
Wenn zum Mailversand ein sendmail-Script verwendet wird (also nicht wirklich Sendmail, sondern nur ein gleichnamiges Script), dann kann es sein, dass sich dieses über "\r\n" als Zeilenendezeichen beschwert bzw. eben darüber stolpert. Die SCRIPTE erwarten häufig nur "\n" und können mit "\r\n" in den erweiterten Headern bzw. den Attachments nicht umgehen.
"\r\n" ist aber die in Mailheadern zu benutzende Form des Zeilenumbruchs. *Eigentlich* sollten Emailprogramme, -server, -wasauchimmer damit umgehen können, auch wenn sie zusätzlich "\n" als Zeilenumbruch akzeptieren.
Tschö, Auge
Hello,
"\r\n" ist aber die in Mailheadern zu benutzende Form des Zeilenumbruchs. *Eigentlich* sollten Emailprogramme, -server, -wasauchimmer damit umgehen können, auch wenn sie zusätzlich "\n" als Zeilenumbruch akzeptieren.
DAS haben wir hier nun aber schon zur Genüge diskutiert.
Die klassischen "sendmail" Scripte auf Linux Hosts wollen keine "\r\n" geliefert bekommen, da sie die bei Verwendung in der Shell ja üblicherweise auch nicht bekommen. Darum entfernt PHP in der Mail()-Funktion auch alle Zeilenendezeichen aus den erkennbaren Headern (und der Leerzeile danach) und ersetzt sie durch "\n". Wenn Du aber nun über das $header-Argument der Funktion eigene Bereiche (für den eigentlichen Mailbody) übergibst, wie z.B. ein base64-codiertes Attachment, dann darfst Du das nicht mit "\r\n" wrappen lassen, sondern nur mit "\n". Die Mail()-Funktion würde das in diesem Fall nicht mehr selber korrigieren (also bewußt auf "\n" zurücksetzen).
Das "sendmail"-Script sorgt dann dafür, dass der MTA nur mit "\r\n" abgeschlossene Zeilen bekommt, in dem es leider alle "\r" _und_ alle "\n" in "\r\n" umwandelt.
Mag sein, dass es da inzwischen auch Scripte gibt, die das nicht tun. Mir ist aber noch keins begegnet.
Liebe Grüße aus Syburg
Tom vom Berg