Problem bei PHP, $_POST Variable ist leer

[Gast]

Mit
print_r($_POST);

liefert sie mir ein leeres Array() zurück.


Woran kann das liegen?
Wo soll ich den Fehler suchen, hab schon überall gesucht was MIR eingefallen ist, aber ich finde den Fehler nicht, eigentlich sollte es funktionieren, tut es aber nicht.

[Gast]

Ok, habe das Problem gefunden.

PHP mag keine id="name" Tags sondern verlangt name="name" Tags,
damit dessen Inhalt in der $_Post Variable gespeichert wird.


Das bringt mich zur nächsten Frage, warum kann PHP mit dem id= Tag nicht umgehen?
Der ist doch inzwischen Standard und soll das name= Tag ablösen.

[The_Invisible]

$_POST liefert nur die werte die du auch per post-methode gesendet hast. hast du das gemacht?

mfg

[The_Invisible]

Ok, habe das Problem gefunden.

PHP mag keine id="name" Tags sondern verlangt name="name" Tags,
damit dessen Inhalt in der $_Post Variable gespeichert wird.


Das bringt mich zur nächsten Frage, warum kann PHP mit dem id= Tag nicht umgehen?
Der ist doch inzwischen Standard und soll das name= Tag ablösen.

das ist eher ein problem der webserver und nicht der dahinterliegenden programmiersprache. wenn der webserver die nicht weitergibt kann php & co auch nicht dafür.

mfg

[darph]

Der ist doch inzwischen Standard und soll das name= Tag ablösen.
Das kommt vielleicht in der nächsten (X)HTML-Version, aktuell ist dem aber nicht so.

WebForm 2.0, die wohl vorraussichtlich ohne normative Veränderungen in HTML 5 übernommen werden (http://www.w3.org/html/wg/html5/#the-form), verlangen immer noch das name-Attribut, wie du hier (http://www.whatwg.org/specs/web-forms/current-work/#extend-form-controls) nachlesen kannst. Dort sieht es zum Haifisch so aus:

<label>E-mail address: <input type="email" name="addr"></label>
<label>Start date: <input type="date" name="start"></label>

Aktuell sieht es korrekterweise so aus:

<form action="input_text.htm">
<p>Vorname:<br><input name="vorname" type="text" size="30" maxlength="30"></p>
<p>Zuname:<br><input name="zuname" type="text" size="30" maxlength="40"></p>
</form>


Außerhalb von Formularen ist natürlich das ID-Feld bezeichnend. Das ist auch sinnvoll so, daß das Formularfeld nicht durch ein id-Attribut definiert wird, denn ein id-Attribut darf pro Dokument auch nur einmal vorkommen, ich kann aber ohne Probleme in ein Dokument zwei Formulare mit jeweils einem input mit dem jeweils gleichen Namen definieren. id und name haben völlig unterschiedliche Aufgaben und können so ohne jede Schnittmenge oder Berührung nebeneinander koexistieren.

[Gast]

Das kommt vielleicht in der nächsten (X)HTML-Version, aktuell ist dem aber nicht so.


Aus XHTML 1.1 wurde das name Tag verbannt, bzw, sollte man es nicht mehr nutzen, auch wenn das noch möglich ist.



Außerhalb von Formularen ist natürlich das ID-Feld bezeichnend. Das ist auch sinnvoll so, daß das Formularfeld nicht durch ein id-Attribut definiert wird, denn ein id-Attribut darf pro Dokument auch nur einmal vorkommen, ich kann aber ohne Probleme in ein Dokument zwei Formulare mit jeweils einem input mit dem jeweils gleichen Namen definieren.

Dann bekommen aber beide Eingabefelder die selben Werte in der post Bearbeitung zugewiesen. Wo ist da also der Sinn von 2 Eingabefeldern mit gleichem name Tag?

[Kinman]

Neben OPtionsfeldern (Radiobuttons) kann man, wie darph bereits erwähnte mehrere komplette Formulare auf einer Seite haben, welche aber ident aufgebaut sind.

mfg Kinman

[DanMan]

Der Zweck des "name" Attributs war schon immer die Programmierung (mittels z.B. PHP - oder Javascript und getElementsByName, womit man dann genau bestimmte Elemente auf der Seite ansprechen kann. V.a. deshalb nützlich, weil es ja sowas wie getElementsByClass nicht gibt und IDs ja nur 1x vorkommen dürfen). Das und Sprungmarken, aber die funktionieren auch mit IDs.

Was das "deprecated" angeht: http://derickrethans.nl/html_name_attribute_deprecated.php

[darph]

Aus XHTML 1.1 wurde das name Tag verbannt, bzw, sollte man es nicht mehr nutzen, auch wenn das noch möglich ist.
Wie DanMan schon schrub: Verbannt beispielsweise als Anker für seiteninterne Verweise, nicht aber aus Formularen.