What is the amount of $_POST records of a dynamic input form?

Asked

Viewed 358 times

5

I have a form with dynamic fields but I realized that when sending it limits to 166 records.

In my form the fields are inside a WHILE so:

<input name="contagem[]" type="hidden" value="<?php echo $contagem; ?>" />
<input name="data_pgto[]" type="hidden" value="<?php echo $row['data_pgto']; ?>" />
<input name="descricao[]" type="hidden" value="<?php echo $row['descricao']; ?>" />

I’m capturing the post like this:

  $quant_linhas = count($_POST['contagem']);
     for($i = 0; $i < $quant_linhas; $i++){

         $pgt = $data_pgto[$i];
         $ds = $descricao[$i];
         echo "Data:".$pgt." - Descrição:".$ds."<br>";
     }

The form is fed from SQL and has 380 records but when sending the POST only goes 166

  • In the form is printing all the data without problem, but when sending will not all. If you echo in the variable $quant_lines it shows 167

  • 1

    It’s 1000 even, but on each line I have 6 inputs. It killed the riddle. Is there any friendlier way to do this? The problem is that I have to show the data for the user to check or change before sending

1 answer

7

Check the directive max_input_vars.

If you are really sure that there are even more than 300 fields in the form and always arrive as 166 limit, the most likely hypothesis is limitation in the configuration directive max_input_vars. The default is 1000 but its environment can be set to 165/166.

Usually when you cross the limit, you return the limit + 1 (1001). If in your case it shows 166, it is probably 165. But I cannot say.

Note that it is not allowed to modify at runtime with ini_set(). But it can be modified if custom configuration files are set with PHP_INI_PERDIR. Still it can’t change at runtime, but at least it won’t change globally.

Of course, despite everything, make sure that there really are the 380 records. Note that there are 3 of each (based on what you posted in the question). Therefore it would be with 1140 fields and that in itself would already exceed the standard limit of the installation.

Depending on the environment setting, the request is stopped by the web server. Here’s an example with Apache 2.4.20, Windows 10, Chrome:

inserir a descrição da imagem aqui

I made a test exceeding the value of max_input_vars and even enters the execution of PHP to count how many received. Chrome returns this screen above. ERR_CONTENT_DECODING_FAILED.

The test was done with PHP5.6 and PHP7. Both return the same result.

It’s 1000 even, but on each line I have 6 inputs.

If you have 380 records and each record generates 6 fields, then the form must have 2280 fields. This exceeds the standard limit of 1000. However, here we can say that there is an inconsistency. If you were actually sending the 2280, the result on receipt would be 1000 or 1001 or even the error ERR_CONTENT_DECODING_FAILED. Note also that this may depend on your environment.

To answer the question, make sure that the form actually contains the 2280 fields. For this you can use Javascript.

In the form set an id. Example: <form id="frm" action...

<script>
frm = document.getElementById("frm"); // frm é o id do formulário
console.log(frm.elements.length); // no console log do seu browser exibirá a quantidade de elementos desse formulário.
</script>

Particularly I believe it is some error in the form. Apparently it is not generating all the fields as expected. The reason is very obvious. If it were the limit of the PHP configuration, it would be cut in 1000 and not in 166. Also in an environment similar to the tests I used, the Decode error would be displayed. There are conflicts in what you described. Test with Javascript.

  • Could be the post_max_size also.

  • The post_max_size returns a Warning Warning: Unknown: POST Content-Length of... and Zera the content of $_POST. I even tested this to solve the doubt. I can’t say what the behavior is like in another environment like Nginx, IIS, Linux, PHP lower than 5.6. I believe it’s no different, but there is that possibility.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.