Can't access $_POST variables
Moderator: General Moderators
-
Russ Dirks
- Forum Newbie
- Posts: 5
- Joined: Mon Feb 16, 2004 7:46 pm
Can't access $_POST variables
Hi,
I've got an order form on my web site which posts data to a .php script, which stuffs it into a mySql database. Last week it stopped working. I get nothing but blank entries in my database. In trying to debug the problem, I added code to my php script to output all the $_POST variables, and there are none. This happens about 80% of the time. About 20% of the time it works fine. Either the browser is not sending data, or the php engine on the server is not putting the data into $_POST variables properly. I've contacted tech support at my web host provider, but so far they have not been much help. Anybody have a clue what might be happening?
Thanks,
Russ
I've got an order form on my web site which posts data to a .php script, which stuffs it into a mySql database. Last week it stopped working. I get nothing but blank entries in my database. In trying to debug the problem, I added code to my php script to output all the $_POST variables, and there are none. This happens about 80% of the time. About 20% of the time it works fine. Either the browser is not sending data, or the php engine on the server is not putting the data into $_POST variables properly. I've contacted tech support at my web host provider, but so far they have not been much help. Anybody have a clue what might be happening?
Thanks,
Russ
-
Russ Dirks
- Forum Newbie
- Posts: 5
- Joined: Mon Feb 16, 2004 7:46 pm
-
Russ Dirks
- Forum Newbie
- Posts: 5
- Joined: Mon Feb 16, 2004 7:46 pm
This is from the PHP documentation:
HTTP POST variables: $_POST
Note: Introduced in 4.1.0. In earlier versions, use $HTTP_POST_VARS.
An associative array of variables passed to the current script via the HTTP POST method. Automatically global in any scope.
This is a 'superglobal', or automatic global, variable. This simply means that it is available in all scopes throughout a script. You don't need to do a global $_POST; to access it within functions or methods, as you do with $HTTP_POST_VARS.
$HTTP_POST_VARS contains the same initial information, but is not an autoglobal. (Note that HTTP_POST_VARS and $_POST are different variables and that PHP handles them as such)
If the register_globals directive is set, then these variables will also be made available in the global scope of the script; i.e., separate from the $_POST and $HTTP_POST_VARS arrays. For related information, see the security chapter titled Using Register Globals. These individual globals are not autoglobals.
-
Russ Dirks
- Forum Newbie
- Posts: 5
- Joined: Mon Feb 16, 2004 7:46 pm
Further info
Further info :
I used this statement to ouput the POST variables :
print_r(array_keys($_POST));
When it works, I nicely see all the names of the fields that are being sent from the form, but 80% of the time, I see nothing but an empty array ( ).
Is there some way to see what is coming from the browser, before PHP starts parsing it?
Russ
I used this statement to ouput the POST variables :
print_r(array_keys($_POST));
When it works, I nicely see all the names of the fields that are being sent from the form, but 80% of the time, I see nothing but an empty array ( ).
Is there some way to see what is coming from the browser, before PHP starts parsing it?
Russ
Don't use if(isset($_POST['submit'])) , use another element. Either use an existing one or create a hidden form element and check for that. Checking for the submit button being pressed as a sign that the form has been posted isn't reliable 
I think the 'pressing enter not working' thing is limited to IE 5.5, bit i'm not 100% sure.
I think the 'pressing enter not working' thing is limited to IE 5.5, bit i'm not 100% sure.
-
Russ Dirks
- Forum Newbie
- Posts: 5
- Joined: Mon Feb 16, 2004 7:46 pm
I found the the problem. It has to do with security
update 832894 which I installed last week. Unfortunately, it has a caveat,
something to do with problems connecting to a server that resets the http
connection for a POST operation.
The security bulletin is here ...
http://www.microsoft.com/technet/treevi ... 04-004.asp
They have issued an update to fix the problem here ...
http://support.microsoft.com/default.aspx?kbid=831167
and here ...
http://www.microsoft.com/downloads/deta ... laylang=en
When I installed this update, the problem went away.
My question to you guys is, is there something that can be done to the server (Apache/1.3.26) so it doesn't exhibit this problem (something about reseting a POST operation, which is way above my head) or do I have to put a notice on my order page to warn people about this and get them to install the fix to the update. That would be a pain!
Thanks!
update 832894 which I installed last week. Unfortunately, it has a caveat,
something to do with problems connecting to a server that resets the http
connection for a POST operation.
The security bulletin is here ...
http://www.microsoft.com/technet/treevi ... 04-004.asp
They have issued an update to fix the problem here ...
http://support.microsoft.com/default.aspx?kbid=831167
and here ...
http://www.microsoft.com/downloads/deta ... laylang=en
When I installed this update, the problem went away.
My question to you guys is, is there something that can be done to the server (Apache/1.3.26) so it doesn't exhibit this problem (something about reseting a POST operation, which is way above my head) or do I have to put a notice on my order page to warn people about this and get them to install the fix to the update. That would be a pain!
Thanks!