Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have the following HTML/PHP page:

<?php
if(empty($_SERVER['CONTENT_TYPE'])) {
    $type = "application/x-www-form-urlencoded";
    $_SERVER['CONTENT_TYPE'] = $type;
}

echo "<pre>";
var_dump($_POST);
var_dump(file_get_contents("php://input"));
echo "</pre>";
?>

<form method="post" action="test.php">
<input type="text" name="test[1]" />
<input type="text" name="test[2]" />
<input type="text" name="test[3]" />
<input type="submit" name="action" value="Go" />
</form>

As you can see, the form will submit and the expected output is a POST array with one array in it containing the filled in values and one entry "action" with the value "Go" (the button). However, no matter what values I enter in the fields; the result is always:

array(2) {
  ["test"]=>
  string(0) ""
  ["action"]=>
  string(2) "Go"
}
string(16) "test=&action=Go&"

Somehow, the array named test is emptied, the "action" variable does make it through.

I've used the Live HTTP Headers extension for Firefox to check whether the POST fields get submitted, and they do. The relevant information from Live HTTP Headers (with a, b and c filled in as values in the textboxes):

Content-Type: application/x-www-form-urlencoded
Content-Length: 51
test%5B1%5D=a&test%5B2%5D=b&test%5B3%5D=c&action=Go

Does anybody have any idea as to why this is happening? I'm freaking out on this one, it has cost me so much time already...

EDIT: We've tried this on different servers, on Windows boxes it does work, on the Ubuntu server with PHP version 5.2.4 (with Suhosin), it doesn't. It even works on a different server, also with Ubuntu and the same PHP version, also with Suhosin installed.

2nd EDIT: I've diffed the two files, this is the output (diff php.ini phps.ini):

270c270
< memory_limit = 32M
---
> memory_limit = 16M      ; Maximum amount of memory a script may consume (16MB)
415c415
< variables_order = "EGCSP"
---
> variables_order = "EGPCS"
491d490
< include_path = ".:"
1253a1253,1254
> extension=mcrypt.so
>

In this phps.ini is the one from the server on which it works and php.ini is the current one. Looks as if there are no problems here, right?

share|improve this question

migrated from stackoverflow.com Mar 30 '10 at 13:48

This question came from our site for professional and enthusiast programmers.

4  
Suhosin may be. –  Col. Shrapnel Mar 30 '10 at 11:21
    
Ya, suhosin sounds like a likely candidate –  SeanJA Mar 30 '10 at 11:27
    
Could you give some more info? Suhosin is installed on the server, should I turn it off? Should I change settings? –  Lex Mar 30 '10 at 11:27
3  
Try this, it'll log if it's a sihosin problem. hardened-php.net/suhosin/configuration.html#suhosin.simulation –  Zoltan Lengyel Mar 30 '10 at 11:39
    
I tried turning on the simulation mode. The array is still emptied. I can't seem to find the log files however... –  Lex Mar 30 '10 at 11:55
show 6 more comments

9 Answers

There's a number of possible reasons why the post array could be empty - chances have that it comes back to human/developer error. I experienced this exact issue when upgrading from PHP 5.2 to 5.4, it was simple but it took hours of troubleshooting to find the bug. In our config.php file we had the below statement to process $_POST arrays:

if (!get_magic_quotes_gpc()) {
    if (isset($_POST)) {
        foreach ($_POST as $key => $value) {
            $_POST[$key] =  trim(addslashes($value));
        }
    }

Magic quotes was once on, and in PHP versions up to 5.2 the above worked fine but anything above version 5.2 it won't process and an empty array is returned.

If you don't have error_reporting() switched on I suggest that you do and I'm sure you'll be able to troubleshoot the issue.

You should also check for deprecated system features, like "magic_quotes" as using them simply fails to return results. I hope this helps. Best of luck. JCS :)

share|improve this answer
add comment

The following should NOT help you. It stands against everything I know of the PHP Configuration:

< variables_order = "EGCSP"
---
> variables_order = "EGPCS"

This one jumped on me. Your superglobals are getting registered in different orders. This just shouldn't be a problem because since you aren't using register_globals and don't rely on them it shouldn't be a problem to change the order in which order variables are being processed.

But you should definitively give it a try and change the order of the variables.

share|improve this answer
add comment

Try renaming your submit button to something other than action. I've had some problems with this in the past. Having an input named 'action' seems to be the problem.

share|improve this answer
add comment

Try copying over the php.ini from the server that works to this one (backup the non-working server's php.ini first though). If it does, it's something in there (perhaps the variables_order, or possibly memory, both unlikely though).

share|improve this answer
add comment

I am having form submittion failures all over the place since I upgraded to Debian "testing" from "stable". It appears that apache2 or php5 is not handling multiple items in the submission with the same name. For example; your form has two inputs name "mo". In the past only one of the values for "mo" would make it through. Now the form seems to drop all data after the first occurence of a duplicate key. Not sure yet. Still trying to figure it out.

share|improve this answer
add comment

In base PHP, I can think of only one configuration option that could break this, which is post_max_size, so check your php.ini and related files to make sure that this value is sane and not set to zero or an invalid value like an alphabetic character.

Suhosin makes it possible to block post variables on a variety of conditions, including such things as array length and variable name length. Grep your php.ini files for 'suhosin' to see if any settings are present, particularly anything starting with 'suhosin.post'. (See http://www.hardened-php.net/suhosin/configuration.html#suhosin.post.max_array_depth for more details on the parameters I'm thinking of.)

Unfortunately, barring a major screwup in configuration that set some value to one or zero, your code (and variables) are short enough that this is something of a long shot. If that comes up blank, my next suggestion would be to backup your Apache and PHP configs, nuke their directories, purge the packages, reinstall, and start putting config chunks back into place until the code stops working again (alternately, start updating that server that's working with configs from the nonfunctioning server until they're both broken). Since you have same-OS-same-PHP server working correctly, this is almost certainly a configuration error on the malfunctioning server somewhere, but that's a pretty large haystack to search through.

Version control of /etc is highly recommended before you start this -- look into the etckeeper package. (Actually, I recommend its use, period. Major sanity saver, particularly on a machine where more than one person has root access.)

share|improve this answer
    
My post_max_size is 8M, I think that would be enough. My php.ini doens't contain any entries with suhosin in it, so that may be a problem... Does suhosin have it's own conf-files? –  Lex Apr 3 '10 at 9:57
    
Not by default, but settings for any PHP module can be set by any file in /etc/php5/conf.d on a Debian system, and thus I presume also an Ubuntu system. Like I said, this was something of a long shot. Still, I'd start by diffing each config file against a working system. –  Zed Apr 5 '10 at 0:06
add comment

There are bug reports on this or similar issues in PHP's bugtracker:

Unfortunately it doesn't mention a solution, but you could try to set another CONTENT_TYPE or no content type at all.

share|improve this answer
    
These bugs are similar, but not the same as mine. I did try setting the content-type (as you can see in the code snippet in my original answer). If I set no content-type at all it also doesn't work... –  Lex Mar 31 '10 at 6:54
add comment

I'm not sure but having

name="test[1]"

etc. may confuse php. I'd change the input names to test_1, test_2 and see what happens.

share|improve this answer
6  
@haavee: No, PHP advertises this usage: php.net/manual/en/faq.html.php#faq.html.arrays –  Boldewyn Mar 30 '10 at 11:26
    
I've tried this, in that way the variables do work, but they're not in an array. –  Lex Mar 30 '10 at 11:26
    
@haavee: Nah, the notation doesn't confuse PHP, it's standard usage of PHP + forms. See Boldewyn's link. :) –  pinkgothic Mar 30 '10 at 11:35
    
ok thx! learned something new today. –  haavee Mar 30 '10 at 11:41
1  
@adam: "It's also possible to assign specific keys to your arrays". –  pinkgothic Mar 30 '10 at 12:07
show 1 more comment

Does it work without the explicit indices? Try:

<form method="post" action="test.php">
<input type="text" name="test[]" />
<input type="text" name="test[]" />
<input type="text" name="test[]" />
<input type="submit" name="action" value="Go" />
</form>
share|improve this answer
    
No, doesn't work either. –  Lex Mar 30 '10 at 11:54
    
Don't set the indices for the test array - they mess up the POST variable detection –  adam Mar 30 '10 at 11:55
2  
Okay, I can leave them out. But it doesn't solve my problem. –  Lex Mar 30 '10 at 12:00
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.