7 replies to this topic

[mikef]

One of my users has put some long descriptions on images in an Etogal table (somewhat modified with extra fields, but I don't think these are relevant).
For some galleries edits fail, and the obvious symptom when debugging is that the last field from the table isn't present when the REQUEST variables are read. (This field is simply a count; its absence results in an implied zero records, so no updates are made). Its not the number of records being posted that's the problem, as one of the smaller galleries (only 4 images) is affected as well as the largest, but if I look at the data for the smaller gallery it has images with long descriptions.
Can anyone tell me whether there is a limit on the total size of form variables sent with an HTTP POST message, or on individual variables in the post messages.
Or is there some other possible reason that the last variable should not be sent. (I've checked with the w3c validator that the form page itself is valid (XHTML 1.0 Transitional) - I don't know how to trap and look at (or check) the actual data that is submitted.)

Any ideas on whats happening would be very welcome!

[Ralph]

Yes, there is a maximum for HTML POST's... Check Etomite Manager > System Info > Server Information > PHP info - View > post_max_size to see the servers current setting... I don't recall whether this figure includes file uploads or not...

[Cris D.]

As for looking at the submitted data, maybe I'm oversimplifying it, but have you stuck a

echo"<pre>";
print_r($_POST);
echo"</pre>";

in your snippet?

This will format and output all the post variables that the form sent as collected by the server (without all the cookie and session stuff). I think that this is as close as you can get to intercepting the post data short of a browser tool like Chris Pederic's Web Developer or FireBug.

[mikef]

As for looking at the submitted data, maybe I'm oversimplifying it, but have you stuck a

echo"<pre>";
print_r($_POST);
echo"</pre>";

in your snippet?

The simple solutions are always the best ... I'd got trapped down the 'I want to see what is actually being sent' path ...

Thanks Cris, thats sorted out exactly what the problem is - there's a limit of 232 fields being posted back, and thats being exceeded. (I was wrong about the 'small gallery' - in counting the number of images per gallery I'd forgotten that this version has the capability of effectively hiding some images from display.)
The total post size doesn't seem to be the problem.

Its not the post max size thats the problem, as thats set at 8M which should be ample, but thanks for the pointer Ralph.

[Ralph]

Not being familiar with the snippet, I wasn't aware that the entire gallery was being passed as an array - or at least it sounds like it is... Form field count would never have come to mind...

[mikef]

'the entire gallery' is those images associated with one page (the page from which they were loaded, and are usually displayed on). When hugelmopf originally designed etogal, there were two visible fields per image (title and filename) and three hidden fields on the from (id, modified, delete). For reasonable numbers of images (remember screens were smaller then, too!) this didn't cause a problem.

Since then the number of fields has grown a little for the released version of etogal, and a lot on this particular customised version (a total of 14 fields per record). A redesign of the edit process is required

At least none of the heavily customised versions have been made available here

[devincampbell]

The discussion of the topic really sounds good but i don't know about snippet?
Please explain me in full details....
Thanks & Regards
Devin Campbell

[mikef]

see etogal section