I'm triying Dev-PHPportable_2.4.0.337
Using php-5.3.2-Win32-VC6-x86
I Have a form (which call to himself) with:
- 1 Input type=hidden
- 1 Input type=text
- 1 Input type=submit
When the form is submited, I make a print_r of $_GET and $_POST and I get that the values are reversed… I MEAN
$_GET have the values of the $_POST and viceversa.
But, this behaviour happend in Dev-PHPportable_2.4.0.337 version, I tested the same project in
Dev-PHPportable_2.3.2, Dev-PHPportable_2.3.1, Dev-PHPportable_2.3.0, Dev-PHPportable_2.2.2; and that version works fine
PD: each version was used with the same php version.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the example script.
Weird: the $_SERVER variable seems ok
…
=>
string(4) "POST"
=>
string(44) "cmd=1&txtEstCod=hello+world&cmdEstCod=Buscar"
…
Well… Work in progress.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In short, as a workaround, use the $_REQUEST array, instead of the $_POST
So, I reviewed the changes from now (June 2010) until October 2006.
The main difference is relative to the recent use of "unicode environment" when launching the php-cgi process.
As far as I can see, the environment variables are the same, and are correctly sent to PHP.
In fact, with the "GET" method, everything works fine. On the opposite, the "POST" method is not good.
Now, PHP seems unable to initialize its $_POST internal array. Curiously, PHP seems to stop its parsing at the first character of the name of the first variable of the form, although the value of this first variable is correctly initialized - the next variables of the form are simply ignored.
Because all variables are displayed at the bottom of the report…
It's possible to replace the following code
$cmd=$_POST;
switch($cmd){
case 1:{
$ce = $_POST;
}
break;
}
by:
phpinfo();
Best regards,
Pierre.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks you for the answer.
So, is this a PHP issue?
Cuz, some times a use a "trick" sending a query string in the action property of the form tag (for example):
<form name="frmAction" action="register.php?cmd=<?php echo $command ?>" method="post">
……
…..
</form>
Then I check if the request mode was "POST" then I get the form controls values with $_POST.
And the variable which say what to do is Sent in the query String (cmd) and I get that value $_GET (…."register.php?cmd=1 / 2 / 3)
I did print rows to the $_POST / $_GET arrays, just like a debug to see what was happening.
I'm using XAMPP and the code works fine (ok, ok, ok XAMPP doesn't use php-cgi.exe).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm triying Dev-PHPportable_2.4.0.337
Using php-5.3.2-Win32-VC6-x86
I Have a form (which call to himself) with:
- 1 Input type=hidden
- 1 Input type=text
- 1 Input type=submit
When the form is submited, I make a print_r of $_GET and $_POST and I get that the values are reversed… I MEAN
$_GET have the values of the $_POST and viceversa.
But, this behaviour happend in Dev-PHPportable_2.4.0.337 version, I tested the same project in
Dev-PHPportable_2.3.2, Dev-PHPportable_2.3.1, Dev-PHPportable_2.3.0, Dev-PHPportable_2.2.2; and that version works fine
PD: each version was used with the same php version.
Hello,
Thanks for having provided all the version numbers.
Could you send a little script as an example of this inversion?
Sorry for the late response. Regards,
Pierre.
has been the same code
filename register.php
<?php
$cmd=null;
$ce = null;
$msgs=null;
if ( (strtoupper( $_SERVER ) == "POST" ) &&
( strpos($_SERVER, $_SERVER ) )
){
$cmd=$_POST;
switch($cmd){
case 1:{
$ce = $_POST;
}break;
}
}
?>
<html>
<head>
<title></title>
</head>
<body>
<font face="Verdana, Arial, Helvetica, sans-serif">
<?php
echo "$cmd \n<br/>";
echo "$ce \n<br/>";
print "GET:<br>\n";
print_r($_GET);
print "<br>\nPOST:<br>\n";
print_r($_POST);
?>
<form name="selStudent" action="register.php" method="POST">
<input type="hidden" name="cmd" value="1"/>
<input type="text" name="txtEstCod"/>
<input type="submit" name="cmdEstCod" value="Buscar"/>
</form>
</font>
</body>
</html>
Thanks for the example script.
Weird: the $_SERVER variable seems ok
…
=>
string(4) "POST"
=>
string(44) "cmd=1&txtEstCod=hello+world&cmdEstCod=Buscar"
…
Well… Work in progress.
In short, as a workaround, use the $_REQUEST array, instead of the $_POST
So, I reviewed the changes from now (June 2010) until October 2006.
The main difference is relative to the recent use of "unicode environment" when launching the php-cgi process.
As far as I can see, the environment variables are the same, and are correctly sent to PHP.
In fact, with the "GET" method, everything works fine. On the opposite, the "POST" method is not good.
Now, PHP seems unable to initialize its $_POST internal array. Curiously, PHP seems to stop its parsing at the first character of the name of the first variable of the form, although the value of this first variable is correctly initialized - the next variables of the form are simply ignored.
Because all variables are displayed at the bottom of the report…
It's possible to replace the following code
by:
phpinfo();
Best regards,
Pierre.
Thanks you for the answer.
So, is this a PHP issue?
Cuz, some times a use a "trick" sending a query string in the action property of the form tag (for example):
<form name="frmAction" action="register.php?cmd=<?php echo $command ?>" method="post">
……
…..
</form>
Then I check if the request mode was "POST" then I get the form controls values with $_POST.
And the variable which say what to do is Sent in the query String (cmd) and I get that value $_GET (…."register.php?cmd=1 / 2 / 3)
I did print rows to the $_POST / $_GET arrays, just like a debug to see what was happening.
I'm using XAMPP and the code works fine (ok, ok, ok XAMPP doesn't use php-cgi.exe).
> So, is this a PHP issue?
In fact it was not. See also Bug #3113430
3113430
Shame on me!
Technically speaking, $_POST is an UTF8String and not an UnicodeString
The fix is only 2 lines of code.
*Fixed* ( Version >= 2.4.1.347)
Sincere apologies,
Pierre.