Tableau $ _POST mystérieusement vide

J'ai la page HTML / PHP suivante:

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

Comme vous pouvez le voir, le formulaire sera soumis et la sortie attendue est un tableau POST avec un tableau contenant les valeurs remplies et une entrée "action" avec la valeur "Go" (le bouton). Cependant, quelles que soient les valeurs que j'entre dans les champs; le résultat est toujours:

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

D'une manière ou d'une autre, le tableau nommé test est vidé, la variable "action" le fait.

J'ai utilisé l'extension Live HTTP Headers pour Firefox pour vérifier si les champs POST sont soumis, et ils le font. Les informations pertinentes des en-têtes HTTP en direct (avec a, b et c remplis comme valeurs dans les zones de texte):

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

Quelqu'un at-il une idée de pourquoi cela se produit? Je flippe sur celui-ci, cela m'a déjà coûté tellement de temps ...

Mise à jour:

Nous avons essayé cela sur différents serveurs, sur les boîtes Windows, cela fonctionne, sur le serveur Ubuntu avec PHP version 5.2.4 (avec Suhosin), ce n'est pas le cas. Il fonctionne même sur un serveur différent, également avec Ubuntu et la même version PHP, également avec Suhosin installé.

J'ai différencié les deux fichiers, voici la sortie ( 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
>

Dans ce phps.ini est celui du serveur sur lequel il fonctionne et php.ini est l'actuel. On dirait qu'il n'y a pas de problème ici, non?

Cela fonctionne-t-il sans les indices explicites? Essayer:

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

Il y a un certain nombre de raisons possibles pour lesquelles le tableau de messages peut être vide - il y a de fortes chances qu'il revienne à une erreur humaine / développeur. J'ai rencontré ce problème lors de la mise à niveau de PHP 5.2 vers 5.4, c'était simple mais il a fallu des heures de dépannage pour trouver le bogue. Dans notre fichier config.php, nous avions l'instruction ci-dessous pour traiter les tableaux $ _POST:

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

Magic quotes était une fois activé, et dans les versions PHP jusqu'à 5.2, ce qui fonctionnait bien, mais tout ce qui est supérieur à la version 5.2 ne sera pas traité et un tableau vide sera retourné.

Si vous ne l'avez pas error_reporting()activé, je vous suggère de le faire et je suis sûr que vous serez en mesure de résoudre le problème.

Vous devez également vérifier les fonctionnalités obsolètes du système, comme " magic_quotes", car leur utilisation ne permet tout simplement pas de renvoyer les résultats. J'espère que ça aide. Bonne chance. JCS :)

Il existe des rapports de bogues sur ce problème ou des problèmes similaires dans le bugtracker de PHP:

• http://bugs.php.net/bug.php?id=49945
• http://bugs.php.net/bug.php?id=45043

Malheureusement, il ne mentionne pas de solution, mais vous pouvez essayer de définir un autre CONTENT_TYPE ou aucun type de contenu.

Eu un problème assez similaire. Eh bien, tout d'abord, il m'a fallu un certain temps pour arriver à ce poste. Pour comprendre le nom de mon problème, j'ai dû installer la console PHP, comprendre comment l'utiliser. Déboguez le code dont je ne savais rien. Allez à la racine du problème et restez perplexe.

La solution était en fait assez simple. Dans Chrome, appuyez sur F12 pour accéder aux outils de développement, sélectionnez Réseau, essayez de publier votre formulaire. Tracez la demande de post, regardez le statut. Si c'est 301 (ou autre chose que 200) - vous avez exactement le même problème que j'avais jusqu'à récemment!

Mon nouveau fournisseur d' hébergement redirigeait http://my_site.com vers http://www.my_site.com , tout ce que j'avais à faire était de modifier certains paramètres dans le cadre de mon CMS (le vôtre pouvait être différent mais similaire dans un sens)

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

à

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

Et le tour est joué, la magie et les arcs-en-ciel et les licornes et mon site fonctionne enfin!

PS Messing avec vos paramètres d'hébergement pourrait également résoudre votre problème ... Si votre problème est similaire au mien bien sûr ...

Je ne suis pas sûr mais ayant

name="test[1]"

etc. peut confondre php. Je changerais les noms d'entrée en test_1, test_2 et voir ce qui se passe.

En PHP de base, je ne peux penser qu'à une seule option de configuration qui pourrait casser cela, c'est-à-dire post_max_size, vérifiez votre php.ini et les fichiers associés pour vous assurer que cette valeur est saine et non définie sur zéro ou une valeur non valide comme un caractère alphabétique .

Suhosin permet de bloquer les variables de publication dans diverses conditions, y compris des éléments tels que la longueur du tableau et la longueur du nom de variable. Grepez vos fichiers php.ini pour «suhosin» pour voir si des paramètres sont présents, en particulier tout ce qui commence par «suhosin.post». (Voir http://www.hardened-php.net/suhosin/configuration.html#suhosin.post.max_array_depth pour plus de détails sur les paramètres auxquels je pense.)

Malheureusement, à moins d'une erreur majeure dans la configuration qui définit une valeur à un ou zéro, votre code (et vos variables) sont suffisamment courts pour que ce soit un peu long. Si cela ne s'affiche pas, ma prochaine suggestion serait de sauvegarder vos configurations Apache et PHP, de supprimer leurs répertoires, de purger les packages, de réinstaller et de commencer à remettre les morceaux de configuration en place jusqu'à ce que le code cesse de fonctionner (alternativement, commencez à mettre à jour ce serveur qui fonctionne avec les configurations du serveur non fonctionnel jusqu'à ce qu'elles soient toutes les deux cassées). Étant donné que le même serveur PHP-même-PHP fonctionne correctement, il s'agit presque certainement d'une erreur de configuration sur le serveur défectueux quelque part, mais c'est une assez grosse botte de foin à rechercher.

Le contrôle de version de / etc est fortement recommandé avant de commencer - regardez dans le paquet etckeeper. (En fait, je recommande son utilisation, point final. Économiseur d'esprit majeur, en particulier sur une machine où plus d'une personne a un accès root.)

J'ai des échecs de soumission de formulaires partout depuis que j'ai mis à niveau vers Debian "testing" de "stable". Il semble qu'apache2 ou php5 ne gère pas plusieurs éléments dans la soumission avec le même nom. Par exemple; votre formulaire a deux entrées nommées "mo". Dans le passé, une seule des valeurs de "mo" pouvait passer. Maintenant, le formulaire semble supprimer toutes les données après la première occurrence d'une clé en double. Pas encore sûr. J'essaie toujours de comprendre.

Essayez de copier le php.ini du serveur qui fonctionne sur celui-ci (sauvegardez d'abord le php.ini du serveur qui ne fonctionne pas). Si c'est le cas, c'est quelque chose là-dedans (peut-être le variables_order, ou peut-être la mémoire, les deux sont cependant peu probables).

Essayez de renommer votre bouton d'envoi en autre chose que l'action. J'ai eu quelques problèmes avec cela dans le passé. Avoir une entrée nommée «action» semble être le problème.

Les éléments suivants ne devraient PAS vous aider. Il s'oppose à tout ce que je sais de la configuration PHP:

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

Celui-ci m'a sauté dessus. Vos superglobaux sont enregistrés dans différents ordres. Cela ne devrait tout simplement pas être un problème car, puisque vous n'utilisez pas register_globalset ne vous fiez pas à eux, cela ne devrait pas être un problème de changer l'ordre dans lequel les variables d'ordre sont traitées.

Mais vous devriez définitivement essayer et changer l'ordre des variables.

Même ce PO est assez ancien, mais aujourd'hui j'ai rencontré un problème similaire.

Après avoir passé quelques heures à vérifier des millions de choses différentes encore et encore, nous avons finalement découvert qu'après la dernière mise à jour de la version PHP 5.6.17 dans nos paramètres par défaut de cPanel à PHP, le http n'était pas sélectionné.

Et après l'avoir réglé sur sélectionné - tout revient à la normale :-)

J'espère que cela aidera tous les futurs lecteurs

Si cela peut aider quelqu'un d'autre ... Je viens de passer des heures à résoudre un problème similaire et le problème était la limite max_input_vars = "1000" de php.ini. Assurez-vous de vérifier les valeurs php.ini de upload_max_filesize, post_max_size et max_input_vars. Dépasser un entraînera un tableau $ _POST vide.