[Erledigt] $_POST Variable verschwindet

[B.C.]

Hey,

ich schreibe grade an einem Administrator-Bereich, basierend auf ein eigenes Framework. Nun möchte ich die INI-Dateien bearbeiten können, und genau dabei tritt ein sehr komischer Fehler auf. Ich lese die INI-Datei also aus und erstelle daraus das Formular. Wenn ich jetzt das Formular abschicke, sind im PHP-Skript selbst die $_POST-Daten vorhanden, jedoch nach dem Speichern in die Datei sieht die INI-Datei so aus:

name = ;
name2 = ;
[...]

Nun habe ich natürlich getestet und auskommentiert, und es wird noch merkwürdiger: Wenn ich die Stelle in meiner Response-Klasse auskommentiere, die den HTML-Code ausgibt, funktioniert es.

#echo $this -> body;

Dann sieht man nur noch eine weiße Seite, aber die $_POST-Daten sind vorhanden. Häää

<?
$w = serialize($_REQUEST);
$file = new CMS_File(RDIR . 'test.txt');
$file -> open('w') -> write($w) -> close();

Diesen Code führe ich immer aus und wenn ich das Formular absende, hat die datei folgenden Inhalt:

test.txt:
a:3:{s:6:"Module";s:8:"Settings";s:6:"Action";s:4: "Save";s:9:"CMSSESSID";s:32:"3c823de4b4ca79b2b2f8a badf88f38a2";}
(Sind nur die GET und COOKIE Daten)

Und nun die Ausgabe auskommentieren, sodass die Seite beim Absenden weiß bleibt:

test.txt:
a:9:{s:6:"Module";s:8:"Settings";s:6:"Action";s:4: "Save";s:6:"Global";a:9:{s:5:"Title";s:10:"MMA Spirit";s:7:"Charset";s:5:"UFT-8";s:8:"Language";s:2:"de";s:6:"Layout";s:6:"Spiri t";s:10:"URLRewrite";s:3:"Off";s:15:"StartControll er";s:4:"Page";s:27:"ParameterNameForControllers"; s:6:"Module";s:23:"ParameterNameForActions";s:6:"A ction";s:19:"ControllerOnMissing";s:4:"Page";}s:7: "Session";a:2:{s:12:"session_name";s:9:"CMSSESSID" ;s:12:"session_time";s:4:"3600";}s:8:"Debugger";a: 4:{s:23:"debugger_screen_logging";s:2:"On";s:21:"d ebugger_file_logging";s:3:"Off";s:17:"debugger_log _file";s:9:"error.log";s:27:"debugger_handle_unimp ortant";s:3:"Off";}s:9:"PreFilter";a:3:{s:13:"PreC ompressor";s:3:"Off";s:13:"BrowserSwitch";s:3:"Off ";s:16:"ChangeMenuByLang";s:2:"On";}s:10:"PostFilt er";a:1:{s:9:"Highlight";s:3:"Off";}s:4:"save";s:1 3:" Speichern ";s:9:"CMSSESSID";s:32:"3c823de4b4ca79b2b2f8abadf8 8f38a2";}
(Jetzt alles da, GET COOKIE und POST)

Alles da!

Was bitte ist das denn?
Wenn noch Informationen fehlen, bitte nachfragen.

MfG
Basti

[nikosch]

Naja, dann besitzt „$this“ vermutlich irgendeine krude Getter-Funktionalität. Aber ehrlich - auf welcher Grundlage sollen wir das Probelm einschätzen können? Hier kann niemand Hellsehen und Dein Framework kennen wir auch nicht.

Fang an zu debuggen.

[B.C.]

Es geht mir einfach darum, aus welchen Gründen es überhaupt möglich ist, dass die $_POST Variablen auf einmal in der geschrieben Datei nicht mehr vorhanden sind. Das Framework ist an der Sache sowieso unschuldig, das Problem tritt auch dann auf, wenn ich keine Klassen des Frameworks benutze.

Was meinst du mit einer "kruden Getter-Funktionalität"?

Wenn ich print_r($_REQUEST); mache, sehe ich alle POST Daten, wieso aber in der Datei nicht ??
Bin grad wohl blind wien Maulwurf...

[nikosch]

Das einzige was DU uns zeigst ist echo $this -> body;
Das ist ein OO __get-Zugriff. Wenn dort irgendwas gelöscht werden soll, dann muss es einen Getter geben, der mehr tut, als nur die Variable auszuliefern.

Wenn nicht, dann kann man nichts zu Deinem Problem sagen.

Das Framework ist an der Sache sowieso unschuldig, das Problem tritt auch dann auf, wenn ich keine Klassen des Frameworks benutze.

Ich denke es passiert, wenn Du $this -> body; auskommentierst? Ist $this kein Objekt des Frameworks?

DEBUGGING!!

[B.C.]

Heey, sorry, tut mir leid hab echt beschissen erklärt in der Hektik.
Es sieht wie folgt aus:

Eine Methode der Response-Klasse:
<?

public function flush () {
        header("HTTP/1.1 {$this->status}");
        foreach($this -> headers as $name => $value)
            header("$name : $value");

        echo $this -> body;

        $this -> body = null;
        $this -> headers = array();
    } 

Die Eigenschaft body ist private und wird über eine Methode mit Templates gefüllt...

Hier das Modul, dass die INI-Datei bearbeiten soll.

<?php

class Controller_Settings extends CMS_ControllerAbstract implements CMS_Interface_ActionController {

    public function Action () {
        $ini = parse_ini_file(CONFIGDIR . 'Global.ini.php', true);
        $this -> view -> addTemplateContent('content', array('ini' => $ini), 'settings');
    }

    public function Save_Action () {
        print_r($_REQUEST);
    $w = serialize($_REQUEST);
        $file = new CMS_File(RDIR . 'test2.txt');
        $file -> open('w') -> write($w) -> close();

        $this -> Action();
    }

}

(Ist aus Testzwecken verändert worden)

Die Flush-Methode wird nach dem Ausführen der Controller ausgeführt...
Habe nochmal Screenshots gemacht, wie man sieht ist die Request komplett vorhanden, jedoch nicht in der Datei ...

Request Ausgabe


Die nicht vollständige Test.txt:

[ChrisB]

    public function Save_Action () {
        print_r($_REQUEST);
    $w = serialize($_REQUEST); 

Die im ersten Bild gezeigte Testausgabe stammt von diesem print_r?

Was ergibt die Kontrollausgabe von $w direkt nach der serialize-Zeile?

[Chriz]

Kann es sein, dass die Datei garnicht aktualisiert wird? Dass sie durch einen Redirect neu geschrieben wird (ohne POST, daher so wenig Inhalt in der TXT)?

Fueg mal in deinen $_REQUEST noch die Microtime und am Besten einen eindeutigen Request-Token ein (evtl. findest du in $_SERVER dazu einen Wert) und fuehr das ganze nochmal aus. Sind Ausgabe/Dateiinhalt chronologisch wie erwartet ausgefuehrt worden? Wurden beide (speziell Dateiinhalt) vom selben Request erzeugt?

[B.C.]

@ChrisB
Jo, das ist dieses print_r().
$w gibt den ganzen serializierten String mit $_POST aus, fehlt danach jedoch in der Datei.

@Chriz
Wenn ich vorher per unlink() die Datei lösche, ändert sich nix. Und wenn ich, wie gesagt die Ausgabe deaktiviere, ist die Datei voll mit $_POST. Aktualisiert wird sie definitiv.
Hab es nun soweit abgeändert:

    public function Save_Action () {
        $_REQUEST['token'] = $this -> request -> getHeader('User-Agent');
        $_REQUEST['time'] = microtime();
        print_r($_REQUEST);
    $w = serialize($_REQUEST);
        unlink(RDIR . 'test2.txt');
        $file = new CMS_File(RDIR . 'test2.txt');
        $file -> open('w') -> write($w) -> close();

        $this -> Action();
    } 

Ergebnis:

Array
(
    [Module] => Settings
    [Action] => Save
    [Global] => Array
        (
            [Title] => MMA Spirit
            [Charset] => UFT-8
            [Language] => de
            [Layout] => Spirit
            [URLRewrite] => Off
            [StartController] => Page
            [ParameterNameForControllers] => Module
            [ParameterNameForActions] => Action
            [ControllerOnMissing] => Page
        )

    [Session] => Array
        (
            [session_name] => CMSSESSID
            [session_time] => 3600
        )

    [Debugger] => Array
        (
            [debugger_screen_logging] => On
            [debugger_file_logging] => Off
            [debugger_log_file] => error.log
            [debugger_handle_unimportant] => Off
        )

    [PreFilter] => Array
        (
            [PreCompressor] => Off
            [BrowserSwitch] => Off
            [ChangeMenuByLang] => On
        )

    [PostFilter] => Array
        (
            [Highlight] => Off
        )

    [save] =>   Speichern  
    [CMSSESSID] => 748a7fad14495c196fcd52ddf9f100ab
    [token] => Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3
    [time] => 0.98249900 1278408876
) 

Und die Datei:
a:5:{s:6:"Module";s:8:"Settings";s:6:"Action";s:4: "Save";s:9:"CMSSESSID";s:32:"748a7fad14495c196fcd5 2ddf9f100ab";s:5:"token";s:100:"Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3";s:4:"time";s:21:"0.00282300 1278408877";}


Die $_POST-Daten werden einfach verschluckt ... und im Formular steht definitiv method="post" und wie gesagt, Ausgabe deaktivieren geht es...
Wenn ich anstatt $_REQUEST nur $_POST verwende, bleibt die Datei leer, jedoch bei $_GET zB wird die gefüllt...
Danke schonmal für eure Bemühungen, mir zu helfen

[ChrisB]

Und wenn ich, wie gesagt die Ausgabe deaktiviere, ist die Datei voll mit $_POST. [...]

Die $_POST-Daten werden einfach verschluckt ... und im Formular steht definitiv method="post" und wie gesagt, Ausgabe deaktivieren geht es...

Das spricht stark für Chriz' Vermutung, dass im Laufe deiner Ausgabe eine Weiterleitung stattfindet.
Dabei wird nämlich die Methode auf GET geändert, und dann sind deine POST-Daten futsch.

Also untersuche das jetzt bitte! Schau in deinen Code, ob da irgendwo weitergeleitet wird; und schau dir auch clientseitig an, was passiert (LiveHTTPHeaders/Firebug/...)

[Chriz]

Das löschen bringt nichts, die Datei wird ja offenbar beschrieben. Du musst feststellen ob die Ausgabe und der Inhalt tatsächlich im selben Request erzeugt wurden.

<?php
$_REQUEST["token"] = md5(uniqid());
?>

[B.C.]

Tatsächlich, der Token hat in der Datei und in der Ausgabe verschiedene Werte...
Weiterleitungen sind entweder im HTML-Dokument per Meta-Tags oder per header() in php ...
doch keines davon tue ich ...

Ich benutze jedoch IMMER absolute Links, also das Formular sieht so aus:

<form action="http://192.168.178.35/FinalCMS/Administrator/?Module=Settings&amp;Action=Save" method="post"> 

Das sollte doch aber kein Problem sein, oder?
Am besten wäre es, wenn ich jemanden per ICQ viel Code zeigen könnte, hier möchte ich das nicht und es wäre sowieso auch viel zu viel.
Aber so eine Weiterleitung wird von mir nicht durchgeführt ... Kann sich sowas irgendwie einschleichen durch Schlampigkeit oder so?? ...

[B.C.]

Hier die HTTP-Header, es sind wirklich 2 ... Aber keine Ahnung, woher die auch nur kommen könnten...

[ChrisB]

Hier die HTTP-Header, es sind wirklich 2 ... Aber keine Ahnung, woher die auch nur kommen könnten...

Nein, eine Umleitung (Location-Header o.ä.) ist da wirklich nicht drin zu erkennen.

Damit könnte es das Problem sein, was wir hier neulich schon mal diskutiert haben:
Hast du vielleicht irgendein Bild, JavaScript, CSS o.ä. im Antwort(!)-Dokument eingebunden, dessen src-/href-Angabe nur "" lautet?
Diese „relative“ Adresse würde der Browser zu der gleichen Adresse, von der das Dokument stammt, auflösen, und diese dann per GET in einem zweiten Request anfordern. Und wenn du bei jedem Request auf diese Adresse deine Datei neu schreibst, dann überschreibt dieser GET-Request das, was dein POST-Request vorher reingeschrieben hat.

[B.C.]

HAHAHAH

Ja man, genau das ist es!
Ich hatte aus einem Template die HTML-Grundstruktur übernommen und da war ein CSS-Verweis, wobei rel="" ins Leere lief ...
Jetzt kann es endlich weiter gehen, ich liebe euch
Alleine wäre ich da niemals drauf gekommen ...