Big arrays is ignored in HTTP POST

ecce

I've made av web shop, and a web page in the admin section edits the properties for a chosen product. Some products has links to LOTS of other stuff, so the form that is shown is dynamically generated with php. For example, a simple hexagon bolt fits to lots of stuff, so there are a long list of connected products for that bolt. All the connected products are shown in input form fields. Simplyfied the PHP gereating the form looks like this:

$i = 0;
foreach($connectedProduct AS $c)
{
    echo '<input type="text" name="connectedProducts[$i][ProductID]" value="$value" />';
    $i++;
}

Saving the products properties works fine for almost all products. For products having lots of connections, something like >400, the complete array "connectedProducts" is not transmitted to the web server when the form is submitted. The form uses HTTP POST. Debugging the script recieving the POST data shows that $_POST does not contain a "connectedProducts" array at all.

I'm a bit confused and lost... anybody got any ideas?

cretaceous

Why do you even need to include all products in the Post array?
Why can't you check the submission after it is posted.. and then do a lookup for matching items?

(or is each product in fact a checkbox?)

There's a thread here (on an alien forum ) might be relevant http://forums.phpfreaks.com/topic/138796-solved-post-array-size-limit-but-not-mb/

sneakyimp

Submitting an array with over 400 objects sounds like a problematic scenario. You might easily exceed post_max_size, a php.ini directive. That you would have your other values but not your connectedProducts array sounds a bit strange. The documentation says:

phpdocs wrote:
If the size of post data is greater than post_max_size, the $POST and $FILES superglobals are empty. This can be tracked in various ways, e.g. by passing the $GET variable to the script processing the data, i.e. <form action="edit.php?processed=1">, and then checking if $GET['processed'] is set.

ecce

Including all options seemed to be the most simple way to edit connected products for a specific item. List them all, then you can edit, remove and add as you want. Click save, every connected product is removed from the database and then added again according to the POST data.

cretaceous;11023211 wrote:
Why do you even need to include all products in the Post array?
Why can't you check the submission after it is posted.. and then do a lookup for matching items?

(or is each product in fact a checkbox?)

There's a thread here (on an alien forum ) might be relevant http://forums.phpfreaks.com/topic/138796-solved-post-array-size-limit-but-not-mb/

You mean a client side diff check and then submit the changes only? Sure it's a solution, but I'm not a fan of client-side programming. And it would be another thing that may contain a bug. My approach is the most simple one, and that's always a good thing. This error only happens for very few parts.

Exeeding post_max_size would generate an error in the php log, right? I can't find anything there.

sneakyimp

ecce;11023555 wrote:
Including all options seemed to be the most simple way to edit connected products for a specific item. List them all, then you can edit, remove and add as you want. Click save, every connected product is removed from the database and then added again according to the POST data.

It also sounds like a good way to accidentally destroy/corrupt a whole bunch of products at once.

I suggest you use AJAX to update one item at a time.

ecce;11023555 wrote:
My approach is the most simple one, and that's always a good thing. This error only happens for very few parts.

I disagree that it's always good to use the most simple approach. The simplest approach can introduce security problems, introduce errors, fail to encode data properly, etc. In your case, it could well be the source of your problems

ecce;11023555 wrote:
Exeeding post_max_size would generate an error in the php log, right? I can't find anything there.

I don't know. You could try reading the documentation yourself to find out. Alternatively, you could increase this value in PHP.ini and see if it has any impact on your script.

Weedpacket

sneakyimp wrote:
I disagree that it's always good to use the most simple approach. The simplest approach can introduce security problems, introduce errors, fail to encode data properly, etc. In your case, it could well be the source of your problems.

In other words,

Albert Einstein wrote:
....Make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.