I have the following HTML/PHP page:

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

echo "<pre>";
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" />

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) {
  string(0) ""
  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

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...


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.

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

< memory_limit = 32M
> memory_limit = 16M      ; Maximum amount of memory a script may consume (16MB)
< variables_order = "EGCSP"
> variables_order = "EGPCS"
< include_path = ".:"
> 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?

  • 4
    Suhosin may be. Mar 30, 2010 at 11:21
  • Ya, suhosin sounds like a likely candidate
    – SeanJA
    Mar 30, 2010 at 11:27
  • Could you give some more info? Suhosin is installed on the server, should I turn it off? Should I change settings? Mar 30, 2010 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, 2010 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... Mar 30, 2010 at 11:55

13 Answers 13


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 :)


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" />
  • No, doesn't work either. Mar 30, 2010 at 11:54
  • Don't set the indices for the test array - they mess up the POST variable detection
    – adam
    Mar 30, 2010 at 11:55
  • 2
    Okay, I can leave them out. But it doesn't solve my problem. Mar 30, 2010 at 12:00

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.

  • 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... Mar 31, 2010 at 6:54

Had a quite similar problem. Well, first of all it took me quite a while to get to this post. To figure out the name of my problem, I had to install PHP console, figure out how to use it. Debug the code that I knew nothing about. Get to the root of the problem and still be puzzled.

The solution was pretty simple actually. In Chrome, press F12 to get to developer tools, select Network, try posting your form. Trace post request, look at the status. If its 301 (or anything else other than 200) - you are having same exact problem that I was having until recently!

My new host provider was redirecting http://my_site.com to http://www.my_site.com, all I had to do is change some settings as part of my CMS (yours might be different but similar in a way) from

$Configuration['BASE_URL'] = 'http://my_site.com'


$Configuration['BASE_URL'] = 'http://www.my_site.com'

And voila, the magic and the rainbows and the unicorns and my site is finally working!

P.S. Messing with your hosting settings might also solve your problem... If your problem is similar to mine of course...

  • Damn it. Redirection was my problem too!
    – Aman Alam
    Sep 17, 2018 at 19:09

I'm not sure but having


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

  • 7
    @haavee: No, PHP advertises this usage: php.net/manual/en/faq.html.php#faq.html.arrays
    – Boldewyn
    Mar 30, 2010 at 11:26
  • I've tried this, in that way the variables do work, but they're not in an array. Mar 30, 2010 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, 2010 at 11:35
  • ok thx! learned something new today.
    – haavee
    Mar 30, 2010 at 11:41
  • 1
    @adam: "It's also possible to assign specific keys to your arrays".
    – pinkgothic
    Mar 30, 2010 at 12:07

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.)

  • 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? Apr 3, 2010 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, 2010 at 0:06

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.


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).


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.


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.


Even that OP is pretty old, but today I encountered a similar problem.

After spending a few hours checking million different stuff over and over, eventually found out that after last update to PHP 5.6.17 version in our cPanel at PHP defaults settings the http wasn't selected. enter image description here

And after setting it to selected - everything back to normal :-)

enter image description here

Hope it will help any future readers


If this can help anyone else... I just spent hours to fix a similar issue and the problem was the max_input_vars = "1000" limit of php.ini. Be sure to check php.ini values of upload_max_filesize, post_max_size and max_input_vars. Exceeding one will results with an empty $_POST array.


not sure if this is already answered after 3 years. I am seeing this error today. after some comparison with a working server, I make this changes and it work.

magic_quotes_gpc = On (from off - not working) in the php.ini

my php version 5.3.3 OS Centos 6.10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .