form problem mit action und $_POST

[Hans Keutgen]

Folgender einfacher HTML Code mit dem form Tag bereitet mir Probleme:

<form action="http://Xxxxxxxxxx.de/ris/email-senden/" enctype="text/plain" method="post">Mein Name <span style="color: red;">*</span>
<input name="name" required="" size="40" type="text" />
Meine E-Mail <span style="color: red;">*</span>
<input name="email" required="" size="40" type="email" />
Betreff
<input name="betreff" size="40" type="text" />
Nachricht <span style="color: red;">*</span>
<textarea cols="30" name="nachricht" required="" rows="10"></textarea>
<input name="empfaenger" type="hidden" value="[e-mail]" />
<input type="submit" value="Absenden" /></form>

Bei Aufruf der Seite Xxxxxxxx.de ist das Feld $_POST leer. Wenn ich die enctype-Clause weglasse, bekomme ich eine 404-Fehlermedlung. Wenn ich mit $_GET aufrufe, sind die Paramter ?... korrekt aufgebaut, aber es kommt ebenfalls zu einem 404-Fehler.

Was kann die Ursache sein????

[Gunnar Bittersmann]

@@Hans Keutgen

Folgender einfacher HTML Code mit dem form Tag bereitet mir Probleme:

Er bereitet Nutzern Probleme, denn deine Eingabefelder haben keine Beschriftung. Bitte die erforderlichen label ergänzen.

<input type="submit" value="Absenden" />

Für Buttons gibt es ein HTML-Element, das vorzugsweise zu benutzen ist:

<button type="submit">Absenden<button>

(Wobei type="submit" default ist; also nicht unbedingt angegeben werden muss.)

LLAP 🖖

[Hans Keutgen]

Vielen Dank für die Anmerkungen. Soweit ich die Beschreibung verstanden habe, ist label für Radio- und Checkboxen sinnvoll und nützlich. Für input ist diese m.E. nicht notwendig. Die Einführung des Buttons hat leider keine Änderung des Verhaltens gebracht.

P.S.: Ich nutze das form Tag in einer Wordpress-Seite.

[Rolf b]

Label ist immer nützlich, vor allem für Anwender, die auf Assistenzsysteme angewiesen sind.

Der Span mit dem Sternchen ist für Assistenzsysteme eher störend, weil sie es mit vorlesen. Man müsste ihn dann mit einem aria-Attribut ausblenden. Sollte ich mich da irren, wird Gunnar mich bestimmt gern korrigieren 😂. Es dürfte besser sein, ihn per :after hinzuzufügen.

Darf ich folgenden HTML Verbesserungsvorschlag machen:

<form action="http://example.com/ris/email-senden/" enctype="text/plain" method="post">
<label class="pflichtfeld">
   <span>Mein Name</span>
   <input name="name" required="" type="text"/>
</label>
<label class="pflichtfeld">
   <span>Meine E-Mail</span>
   <input name="email" required="" type="email" />
</label>
<label>
   <span>Betreff</span>
   <input name="betreff" type="text" />
</label>
<label class="pflichtfeld">
   <span>Nachricht</span>
   <textarea name="nachricht" required="" rows="10"></textarea>
</label>
<input name="empfaenger" type="hidden" value="[e-mail]" />
<button>Absenden</button>
</form>

label { display: block; margin-bottom: 0.25em; }
input { width: 30em; padding: 1px;}
textarea { vertical-align: top; width: 30em; }
span { display: inline-block; width: 10em; }
.pflichtfeld span:after { content: '*'; color:red; }

Rolf

[Gunnar Bittersmann]

@@Rolf b

Der Span mit dem Sternchen ist für Assistenzsysteme eher störend, weil sie es mit vorlesen. Man müsste ihn dann mit einem aria-Attribut ausblenden. Sollte ich mich da irren, wird Gunnar mich bestimmt gern korrigieren 😂.

Soweit richtig.

Es dürfte besser sein, ihn per :after hinzuzufügen.

Hier ist Korrektur angesagt: (Einige/die meisten?) Screenreader lesen auch generierten Inhalt vor.

In Heydon Pickerings „Inclusive Design Patterns“, Seite 275:

<label for="email">Your email address <strong class="red" aria-hidden="true">*</strong></label>
<input type="text" id="email" name="email" aria-required="true">

(Wobei class="red" ebenso fragwürdig ist wie die Verwendung des strong-Elements. Den falschen type hab ich schon angemeckert.)

aria-required statt HTML5 required (noch) wegen besserer Untestützung in AT.

LLAP 🖖

EDIT: Ich schieb dann mal noch hinterher:

<label for="email">Your email address <span class="marker" aria-hidden="true">*</span></label>
<input type="email" id="email" name="email" aria-required="true">

[TS]

Hello,

Folgender einfacher HTML Code mit dem form Tag bereitet mir Probleme:

<form action="http://Xxxxxxxxxx.de/ris/email-senden/" enctype="text/plain" method="post">  
Mein Name <span style="color: red;">*</span>  

... >

Bei Aufruf der Seite Xxxxxxxx.de ist das Feld $_POST leer. Wenn ich die enctype-Clause weglasse, bekomme ich eine 404-Fehlermedlung. Wenn ich mit $_GET aufrufe, sind die Paramter ?... korrekt aufgebaut, aber es kommt ebenfalls zu einem 404-Fehler.

Was kann die Ursache sein????

Es handeöt sich bei der URL vermutlich nicht um ein PHP-Skript. Wie leutet denn die Ressourcebezeichnung vollständig?

Liebe Grüße
Tom S.

[Hans Keutgen]

Hallo Tom,

die aufgerufene Seite Xxxxxxx.de/ris/email-senden/ enthält einen Shortcode, der vollständig in PHP geschrieben ist. Diese Form der Übergabe habe ich auf anderen Seiten schon durchgeführt.

Wie komme ich an die vollständige Ressourcenbezeichnung????

LG Hans

[TS]

Hello,

wie heißt denn die Datei?

Liebe Grüße
Tom S.

[Rolf b]

Naja, $_GET und $_POST müffeln schon etwas nach PHP. Vielleicht hat er eine rewrite-Rule drin und arbeitet mit Controller/Action Routing.

Hier steht, dass PHP zwei enctype Werte versteht, nämlich application/x-www-form-urlencoded und multipart/form-data. Letzteres ist für file uploads und passt hier nicht, ersteres ist der Default für forms. Mit text/plain kommt er nicht klar, deshalb ist $_POST nicht gefüllt.

Hans, du sprichst von ?... Parametern, dein HTML zeigt sie aber nicht. Hast Du die URL zusammengestutzt?

Für die Ursache des 404 könnte im übrigen der Serverlog helfen, da sollte nämlich stehen, welche Ressource er wirklich anfordern will (falls mod_rewrite im Spiel ist).

Rolf

[TS]

Hello,

ich nehm eigentlich immer multipart/form-data. Das geht immer.

Kann es jetzt nicht ausprobieren, aber ich meine, dass reine name:value-Paare mit text/plain früher auch ins $_POST übertragen wurden.

Wenn dad Action-Ziel nicht als PHP-Datei gekennzeichnet ist, wird es nicht geparst.

Liebe Grüße
Tom S.

[Hans Keutgen]

Leider komme ich an den Serverlog nicht dran - werde bei Strato gehostet. Oder wer weiß wie ich da den Serverlog lesen kann?

Ich habe andere Seiten, auf denen Alles wunderbar funktioniert, aber das hilft bekanntlich nicht weiter.

Wenn ich enctype weglasse, kommt der 404.

?... steht hinter der Adresse bei $_GET mit den richtigen Parameter, aber auch dann 404!

Es scheint hoffnungslos zu sein.

[TS]

Hello,

Was pssiert denn, wenn Du die Ressource direkt über die Adressleiste aufrufst, also per GET?

Liebe Grüße
Tom S.

[Rolf b]

Strato hat doch bestimmt Support...

Rolf

[Julius]

Hallo Hans,

Leider komme ich an den Serverlog nicht dran - werde bei Strato gehostet. Oder wer weiß wie ich da den Serverlog lesen kann?

Ich war vor nicht allzu langer Zeit Kunde bei Strato (Webspace, kein eigener Server) und ich konnte damals das ErrorLog des Webservers einsehen. In den FAQ beschreiben sie auch wo.

Gruß
Julius

[dedlfix]

Tach!

Was kann die Ursache sein????

Den enctype auf text/plain zu stellen, ist jedenfalls keine Lösung. Lass das ganz weg, wenn du nicht mit Datei-Uploads in diesem Formular arbeitest. Der Browser scheidet als Ursache aller Voraussicht nach ebenfalls aus. Aber der hat Entwickler-Tools an Bord, mit denen du zumindest mal nachschauen kannst, dass der Request beim Abschicken an die richtige Adresse geht und die Daten mitsendet. Vermutlich ist aber das Problem serverseitig zu finden, aber das kann alles mögliche sein. Ohne das Problem genauer untersuchen oder nachstellen zu können, wirst du da zielführende Hinweise nur auf Zufallsbasis bekommen können.

dedlfix.

[Auge]

Hallo

<form action="http://Xxxxxxxxxx.de/ris/email-senden/" enctype="text/plain" method="post">

Dass das Attribut enctype weg soll, wurde ja schon oft genug gesagt. Mir stellt sich aber eine andere Frage. Was passiert, wenn du http://Xxxxxxxxxx.de/ris/email-senden/ im Browser aufrufst? Findet sich das die Eingaben verarbeitende PHP-Skript als automatisch aufzurufende Ressource z.B. als „index.php“ in diesem Verzeichnis und wird dann mit einer Fehlermeldung aufgerufen? Oder heißt dein verarbeitendes Skript ganz anders? Dann sollte der Name der Datei auch in der URL im Action-Attribut genannt werden.

Nachricht <span style="color: red;">*</span>
<textarea cols="30" name="nachricht" required="" rows="10"></textarea>

Dass Labels nicht nur für Radio-Buttons und Checkboxen wichtig sind, sondern auch für alle anderen Formularelemente, die Eingaben ermöglichen, wurde auch schon gesagt. Zudem lässt sich der Text der Feldbenennungen so auch leichter per CSS erreichen.

Hier kommt aber noch ein bisher nicht benanntes riesengroßes Sicherheitsloch hinzu.

<input name="empfaenger" type="hidden" value="[e-mail]" />

Die Anfrage an das verarbeitende Skript kann man — vorausgesetzt, das funktioniert grundsätzlich — auch ohne das HTML-Formular oder auch ohne einen Browser erzeugen. Dann mann man aber auch einen anderen Empfänger angeben. Dein Skript wird so zur Spamschleuder. Nimm dieses Eingabefeld aus dem Formular heraus und gib den Empfänger hartkodiert im verarbeitenden Skript an.

Tschö, Auge

[Rolf b]

ris/email-senden/ kann ein Order sein, muss aber nicht. Sowas kann über rewrite-Regeln oder HTTP-Module (im IIS) anders verarbeitet werden.

Rolf

[Auge]

Hallo

Was passiert, wenn du http://Xxxxxxxxxx.de/ris/email-senden/ im Browser aufrufst?

ris/email-senden/ kann ein Order sein, muss aber nicht. Sowas kann über rewrite-Regeln oder HTTP-Module (im IIS) anders verarbeitet werden.

Deshalb frage ich ja, ob das denn das richtige Ziel ist und ob die Ressource auch direkt im Browser aufgerufen werden kann (evtl. mit Fehlermeldung). Es war ja mehrfach von Änderungen, die 404-er ausgelöst haben, die Rede. Und beim mutmaßlichen Wissenstand des OPs, den ich aus seinen Ausführungen ableite, bezweifle ich, dass er Kostruktionen mit Rewrite selbst angelegt hat. Wenn da Rewrite imSpiel ist, hat das jemand anderes eingerichtet und er benutzt es einfach, ohne sich über die Hintergründe im Klaren zu sein.

Tschö, Auge