POST Variablen auslesen, wie?

Hallo zusammen,
es ist wirklich zum Haare raufen, ich weiß nicht, wie ich die POST-Variablen ausgelesen bekomme:
Weder

PHP-Code:

---

echo $this->Input->post('email'); 


---

noch

PHP-Code:

---

echo \Input::post('email'); 


---

noch

PHP-Code:

---

echo \Input::getInstance()->post('email'); 


---

liefert mir ein Ergebnis zurück.
Die Daten sollen in einem externen PHP-Script verarbeitet werden, das per Inserttag {{file::path/to/file.php}} geladen wurde.
Seltsamerweise wird jedoch erkannt, daß der REQUEST_TOKEN fehlt, wenn ich den Wert nicht mit übermittle.

Eine generelle Frage:
Welches ist die richtige Vorgehensweise in Contao 3.2.20, um externe Werte und Funktionen zu nutzen?

Vielen Dank für die Hilfe
LG/A

Zeig doch mal Dein ganzes Skript. Das $this in diesem Beispiel

Zitat:

---

Zitat von syntaxys

PHP-Code:

---

echo $this->Input->post('email'); 


---

---

kann alles mögliche sein, je nach dem in welchem Kontext Du gerade bist. Daher ist es etwas schwierig zu sagen was Du anders machen musst.

Zur "richtigen" Lösung: lass das includ einer "externen" *.php Datei und schreib Dir ein Modul.

Zitat:

---

Zitat von fiedsch

Zur "richtigen" Lösung: lass das includ einer "externen" *.php Datei und schreib Dir ein Modul.

---

Ehrlich gesagt frage ich mich gerade, wie es sein kann, daß ein Webmaster mit fast 10 Jahren Contao-Erfahrung sich geschätzte 2 Stunden durch das Forum und andere Websites einen Wolf danach googelt, um eine scheißdrecks POST-Variable ausgelesen zu bekommen. In der Zeit hätte ich mit Contao 2.11.17 das gesamte Projekt fix und fertig bekommen.
Ich habe zwar auch Contao 3 bei verschiedenen Projekten im Einsatz, aber nur mit gewöhnlichen Standardinstallationen ohne spezielle Anforderungen - eben einfach nur als CMS, das funktioniert ganz gut. Meinen Kunden ist das ziemlich wurscht, ob die Paradigmen eines MVC-Frameworks gerade total hip sind, die wollen einfach zu erträglichen Konditionen online sein.

Zu Deiner Nachfrage:
Im Prinzip ist das schon fast das Script, ich streiche die Segel, bevor ich mich total ins Defizit vertüftle. In Artikel 1 auf Seite 1 binde ich als Inhaltselement vom Typ HTML-Code ein PHP-Script per Inserttag {{file::script.php}} ein, das ein Formular mit verschiedenen Angaben aus einer DB generiert. Das funktioniert noch ohne Probleme.
In Artikel 1 auf Seite 2 will ich mit dem gleichen Konzept die per POST übermittelten Angaben auslesen und in eine DB schreiben.

Ich will kein Modul schreiben und keine Extension für den Rest der Welt, weil das Ganze nur ein Problem meines Kunden ist. Warum ist das mit Contao 3 so umständlich? Und mit Contao 4 wahrscheinlich noch viel viel komplizierter? Muss man dann immer gleich eine Symphonie komponieren?

Zitat:

---

Zitat von syntaxys

Muss man dann immer gleich eine Symphonie komponieren?

---

Nachdem Contao 4 ein Symfony Bundle ist - ja :Þ


Zu deinem Problem kann ich nichts sagen. \Input::post() ist prinzipiell der richtige Weg.

Ich glaub du musst in dem Fall deinem externen Script die Parameter übergeben die du darin brauchst, in der Art:
https://community.contao.org/de/show...l=1#post336475

Zitat:

---

Zitat von syntaxys

Ehrlich gesagt frage ich mich gerade, wie es sein kann, daß ein Webmaster mit fast 10 Jahren Contao-Erfahrung sich geschätzte 2 Stunden durch das Forum und andere Websites einen Wolf danach googelt, um eine scheißdrecks POST-Variable ausgelesen zu bekommen. In der Zeit hätte ich mit Contao 2.11.17 das gesamte Projekt fix und fertig bekommen.

---

Dann hast Du eben etwas falsch gemacht. Da kann Contao auch nichts dafür.

Ich habe eben schnell einen Testfall zusammengeklöppelt:


Date templates/foo.php

PHP-Code:

---

<?php
echo \Input::post("foo");

---

Artikel mit (wie von Dir beschrieben) Inhaltselement HTML mit

Code:

---

{{file::foo.php}}

---

und einem Formular: Backend ->Formulargenerator) mit einem Textfeld (Feldname "foo") und einem Absendebutton. Methode POST.

Damit bekomme ich auf der Seite nach dem Absenden den Input angezeigt.

Ist in Deinem Formular, das script.php erzeugt (wieso eigentlich nicht mit Contao Formulargenerator?) ein Request-Token enthalten?

Mir scheint, Du macht das zu umständlich und beschwerst Dich dann, das es umständlich ist (sorry).

Zitat:

---

Zitat von Spooky

Nachdem Contao 4 ein Symfony Bundle ist - ja :Þ
Zu deinem Problem kann ich nichts sagen. \Input::post() ist prinzipiell der richtige Weg.

---

Das ist ja schon so wie bei Apple: Friss es, so wie es für uns schön ist, oder stirb. ;-)
Wenn man wenigstens die neue Methode nur parallel anbieten würde, so daß man sich als Entwickler freiwillig dafür entscheiden kann.
Wo wird denn das $_POST-Array in Contao 3 abgewürgt? Das ist ist doch sicher nur eine Zeile irgendwo in der Hauptsammlung der Funktionen, die man ohne Schaden auskommentieren könnte. Ich bin so tief nicht in der Materie drin, um das schnell zu lösen, aber das wäre mir und vielleicht vielen anderen eine große Hilfe.

Danke!
LG/A

Zitat:

---

Zitat von fiedsch

Ist in Deinem Formular, das script.php erzeugt (wieso eigentlich nicht mit Contao Formulargenerator?) ein Request-Token enthalten?
Mir scheint, Du macht das zu umständlich und beschwerst Dich dann, das es umständlich ist (sorry).

---

Ja, am REQUEST_TOKEN liegt es nicht, der ist dabei. Ich kann's nicht mit dem Formulargenerator machen, weil ich individuelle Daten aus der DB auslese und im Formular aufbereiten muss. Darüber habe ich auch schon gegrübelt. Es geht einfach nur darum, daß ich $_POST ohne Einschränkung verarbeiten kann.

Zitat:

---

Zitat von syntaxys

Es geht einfach nur darum, daß ich $_POST ohne Einschränkung verarbeiten kann.

---

Machst Du Contao, nimmst Du \Input::post().

Was spricht dagegen \Input::post() zu nehmen = warum willst Du unbedingt auf $_POST zugreifen?

Zeig doch mal Deine Skripte, vielleicht kann man Dir dann ja helfen.

Seite 1, Artikel 1, Inhaltselement 'HTML' mit Inserttag {{file::datei1.php}}:

PHP-Code:

---

<form action="seite2.html" method="post">
<input type="email" name="email" value="" placeholder="me@host.tld" size="20"><br />(Sie erhalten auch die Registrierungsdaten an diese Adresse gesendet.)
<input type="hidden" name="register" value="<?php echo $hostRegister; ?>">
<input type="hidden" name="REQUEST_TOKEN" value="{{request_token}}" />
<br /><button type="submit" name="ok" value="ok">OK</button>
</form>

---

Seite 2, Artikel 1, Inhaltselement 'HTML' mit Inserttag {{file::datei2.php}}:

PHP-Code:

---

<?php
echo \Input::post('email');
echo \Input::getInstance()->post('email');
?>

---

Mit Extension 'inputvar' {{post::email}} wird auch nichts ausgegeben.

In den Threads, die ich im Forum zu ähnlichen Problemen gefunden habe, gab es keine Lösung: $_GET funktioniert, $_POST nicht.

Hi,

ich glaube nicht, dass {{file::*}} dafür gedacht ist, solche "komplexen" Sachen abzubilden bzw. Formulare zu verarbeiten.
Daher, entweder mit $_GET arbeiten oder sich mal mit Modulentwicklung für Contao beschäftigen.

Die 2 Stunden die du für Recherche für das post-Problem aufgewendet hast, hättest dir mal lieber 3-4 Videos von Tristan angesehen, dann hättest jetzt bereits dein Basismodul:
https://www.youtube.com/playlist?lis...DE9846C628F23D

Ich habe es jetzt wie in #10 beschrieben probiert:

Formular 1:1 wie dort beschrieben und auf seite.html das HTML mit {{file::echo.php}}
mit dieser echo.php

PHP-Code:

---

<?php
echo "email: " . \Input::post("email");
?>

---

die in wie die form.php templates liegt (das ist bei Dir auch so?).

Funzt. Jetzt frage ich mich, was bei Dir anders ist.

Zitat:

---

Zitat von syntaxys

Wenn man wenigstens die neue Methode nur parallel anbieten würde, so daß man sich als Entwickler freiwillig dafür entscheiden kann.

---

Welche neue Methode?

Zitat:

---

Zitat von fiedsch

Funzt. Jetzt frage ich mich, was bei Dir anders ist.

---

Tja, das wüsste ich auch gerne, hast Du es auch mit 3.2.20 getestet? Die $_POST-Werte kommen einfach nicht an ...

PHP-Code:

---

Array
(
    [_GET] => Array
        (
            [language] => de
        )

    [_POST] => Array
        (
        )

    [_COOKIE] => Array
        (
            [PHPSESSID] => 4a34r3d1gcblbiu3r7tihtnha7
            [BE_USER_AUTH] => 316a23f4595c3f37b022472df4c9f48e1a0e46d0
            [BE_PAGE_OFFSET] => 0
        ) 


---

Ich werde mich morgen darum kümmern und den Thread hier updaten.

Zitat:

---

Zitat von syntaxys

Du es auch mit 3.2.20 getestet?

---

Ja.

Zitat:

---

Die $_POST-Werte kommen einfach nicht an ...
[PHP]

---

Daß $_POST leer ist ist OK. Aber ich hatte oben schon gefragt, was gegen \Input::post() spricht.

Zitat:

---

Zitat von fiedsch

Ja. Daß $_POST leer ist ist OK. Aber ich hatte oben schon gefragt, was gegen \Input::post() spricht.

---

Warum ist es OK, daß $_POST leer ist? Und 'echo \Input::post('var')' ist ja bei mir bei mir genauso leer ...

Zitat:

---

Zitat von syntaxys

Warum ist es OK, daß $_POST leer ist?

---

Weil Contao das leert und als Sicherheitsfeature den Zugriff nur noch auf die gefilterten Werte ermöglicht (stimmt nicht ganz, denn es gibt auch \Input::postRaw()).

Zitat:

---

Zitat von syntaxys

Und 'echo \Input::post('var')' ist ja bei mir bei mir genauso leer ...

---

Das ist das Problem, das wir klären müssen. Aber dabei bringt es m.E. nichts an anderen Stellen "rumzupfrickeln". \Input::post() ist der richtige Weg und daß es so geht hat mein Test ja auch belegt.

Wo wird der Wert geleert? Bei mir hat bisher normal $_POST auch funktioniert.
Einzig in Formularen wird der Wert geleert, nachdem er in $_SESSION['FORM_DATA'] gespeichert wurde oder?

$_POST wird eigentlich gar nicht geleert.

Ist es nicht bei Contao so, dass bei Post immer die Seite mit dem Formular wieder aufgerufen wird, dort wird die Validierung und Verarbeitung der POST-Variablen gemacht und dann auf die Zielseite weitergeleitet? Bei GET läuft das anders.

Hier in Deinem Script zielt das Formular aber direkt auf die Zielseite.

Du verwendest den <button>-Tag, Contao-Formulare verwenden den <input type="submit">. Geht das überall, oder gibt es Einschränkungen?

Zitat:

---

Zitat von Spooky

$_POST wird eigentlich gar nicht geleert.

---

Das hast Du recht und ich etwas durcheinander gebracht.

In contao/system/modules/core/library/Input.php wird in initialize()

PHP-Code:

---

$_POST = static::cleanKey($_POST); 


---

(und dito für $_GET und $_COOKIE) aufgerufen, wo der Wert mit stripSlashes(), decodeEntities(), xssClean() und stripTags() bereinigt wird.

Im Zugriff mit post() wird dann geschaut, ob der Wert bereits gecached wurde und ansonsten wieder gefiltert und ausgeliefert.

Wie auch immer: der Zugriff sollte nicht direkt auf $_POST erfolgen, weil man dan die Filterung nicht bekommt.

Zitat:

---

Zitat von do_while

Ist es nicht bei Contao so, dass bei Post immer die Seite mit dem Formular wieder aufgerufen wird, dort wird die Validierung und Verarbeitung der POST-Variablen gemacht und dann auf die Zielseite weitergeleitet? Bei GET läuft das anders.

Hier in Deinem Script zielt das Formular aber direkt auf die Zielseite.

---

Hatte es ausprobiert. Funktioniert auch. Sollte also nicht das grundsätzliche Problem sein.

Zitat:

---

Du verwendest den <button>-Tag, Contao-Formulare verwenden den <input type="submit">. Geht das überall, oder gibt es Einschränkungen?

---

Falls das nicht geht würde das nach meinem Verständnis dazu führen, daß das Formular nicht abgeschickt wird. Aber das wird es ja anscheinend, denn er kommt auf seine seite2.html -- nur leider eben ohne Daten.

Guten Morgen zusammen,
vielen Dank schon mal für Eure Unterstützung bei der Lösung des Problems. Folgendes habe ich heute Morgen ausprobiert:

• Wenn ich den Prozess in einen Unterordner im Contao-Verzeichnis auslagere, funktioniert alles prima, weil Contao sich nicht einmischt.

• Testweise belade ich in der index.php vor der Initialisierung des Controllers die $GLOBALS['TL_HOOKS']['postvars'] = $_POST; und bekomme die Daten auch in der Zielseite geliefert. Also werden die $_POST-Daten irgendwo in Contao gefressen.

• Ich habe mal testweise die Option Die Sprache zur URL hinzufügen deaktiviert und nun bekomme ich auch die Ausgabe von echo Input::post('email'); bzw. echo Input::getInstance()->post('email'); hin.

Der Bug ist also dort weiter zu suchen. Auf die Sprache im URL kann ich vorerst verzichten, obwohl das Projekt später mehrsprachig werden soll.

LG/A

Zitat:

---

Zitat von syntaxys

• Ich habe mal testweise die Option Die Sprache zur URL hinzufügen deaktiviert und nun bekomme ich auch die Ausgabe von echo Input::post('email'); bzw. echo Input::getInstance()->post('email'); hin.

Der Bug ist also dort weiter zu suchen. Auf die Sprache im URL kann ich vorerst verzichten, obwohl das Projekt später mehrsprachig werden soll.

LG/A

---

Dann ist es klar, warum es bei dir nicht funktioniert. Du hast nämlich folgendes in deinem Formular stehen:

PHP-Code:

---

<form action="seite2.html" method="post"> 


---

Da fehlt die Sprache. Wenn du seite2.html ohne die Sprachvariable aufrufen lässt, gibt es einen 301 Redirect auf de/seite2.html (oder welche Sprache auch immer). Nach dem Redirect sind natürlich keine POST Daten mehr da. Der Bug liegt also in deinem Formular, nicht in Contao ;)

Zitat:

---

Zitat von Spooky

Nach dem Redirect sind natürlich keine POST Daten mehr da. Der Bug liegt also in deinem Formular, nicht in Contao ;)

---

Mir war nicht bewußt, daß die Sprachsteuerung per Redirect erfolgt, dann ist natürlich klar, daß die $_POST verloren geht. In einem anderen Projekt arbeite ich auch mit Sprachvarianten und habe das aber anders gelöst. Ich zerpflücke den URL und hole mir die gewünschten Parameter in die Session, somit macht mir ein Redirect keine Probleme, bzw. benötige ich den überhaupt nicht:

PHP-Code:

---

$uri = str_replace('.html','',substr($_SERVER['REQUEST_URI'],1));
$uri = explode('/',$uri);
$_SESSION['language'] = $uri[0];
... 


---

Zitat:

---

Zitat von syntaxys

Mir war nicht bewußt, daß die Sprachsteuerung per Redirect erfolgt

---

Naja, eine "Sprachsteuerung" passiert hier nicht. Contao erlaubt, bei aktivierter Sprache in der URL, einfach das Aufrufen von Seiten über deren ID oder Alias, auch wenn keine Sprache angegeben ist und macht dann einen Redirect auf die entsprechende (oder Fallback) Sprache, wenn eine passende Seite gefunden wurde, anstatt eine Fehlermeldung auszugeben.

Hat den Vorteil, dass man diese Funktion auch erst später aktivieren kann und alle bestehenden Links, die bereits irgendwo indiziert wurden, funktionieren weiterhin (führen aber möglicherweise nicht zur "richtigen" Sprache).

Was ist mit dem Inserttag {{post::*}} (Contao InsertTags)?

Mir ist klar, dass dieser Thread schon etwas älter ist. Wurde dieses Insert-Tag erst später aufgenommen oder warum spielt das hier in der Betrachtung des Problems keine Rolle? Für mich klingt es wie prädestiniert dafür – da muss man nix groß programmieren und updatesicher, also leichter wartbar ist es auch.

Zitat:

---

Zitat von wanst

Was ist mit dem Inserttag {{post::*}} (Contao InsertTags)?

Mir ist klar, dass dieser Thread schon etwas älter ist. Wurde dieses Insert-Tag erst später aufgenommen oder warum spielt das hier in der Betrachtung des Problems keine Rolle? Für mich klingt es wie prädestiniert dafür – da muss man nix groß programmieren und updatesicher, also leichter wartbar ist es auch.

---

Der ursprüngliche Thread bezieht sich nicht auf Insert Tags, sondern auf den Zugriff von POST Variablen innerhalb von PHP.

Zitat:

---

Zitat von Spooky

Der ursprüngliche Thread bezieht sich nicht auf Insert Tags, sondern auf den Zugriff von POST Variablen innerhalb von PHP.

---

OK, aber der Threadstarter verwendet eine PHP-Datei, deren Ausgabe er via Insert Tag {{file::...}} nachlädt – das scheint mir doch vor dem Hintergrund, dass man die POST-Übergaben direkt mit {{post::...}} auslesen kann, etwas mit dem Schinken nach der Bratwurst geworfen.

Habe ich da einen Denkfehler drin? Was ist der Unterschied?

Wir wissen nicht wie der Code des Threadstarters aussieht. Er/Sie hat nur erwähnt dass die Daten im PHP Script verarbeitet werden sollen.