MRT update breaks if more than 248 form field repeat selections/regions

Is there any known issues where having more than 248 repeating checkboxes, or any form elements, breaks the MRT update?

I have an update page with a MRT. The checkboxes (and other form fields) are in a repeat region/repeat selection. This page has worked for a long time but as the number of products increased, it finally exposed an issue.

The page is used to create packages of products. So basically 4 tables are being used for the MRT.

tblProducts (267 products in my case)
relProduct_Options (relational table for size and color options and products)
tblPackages (id and name of packages)
relPackage_Products (relational table for the products in each package)

There is another table for the size options title but it’s not required for the MRT to perform the updates.

I shouldn't say that the MRT is broken totally. As long as you check or uncheck any of the boxes from 0 up to the 247th, click update and it works. But click any of the boxes that are beyond that, the update ignores them.
When I print out the post array, I can see that even that breaks part of the way through the 248th group of fields.

Each iteration of the repeat select contains 5 total fields currently used by the MRT

WADA_RepeatID_ProductOptionID (hidden)
ProductOptionID (checkbox)
ProductID (hidden)
PackRequired (checkbox)
ProductQty (text)

And another hidden for future use called PackSteps (hidden)

I found that if I remove that hidden field, PackSteps, everything works. It’s not even included in the MRT behavior at the moment.
If I do include it, it still doesn’t work. At first I thought it was a syntax error for that field, I wasn’t seeing but it’s not. If I remove the ProductQty field instead but leave the PackSteps field, it all works. So basically it comes down to a max of 5 fields allowed and/or a maximum of 248 rows of repeating regions.

I’m including the stripped down version of the page. I’ve stripped out everything I can but it still doesn’t respect the fields beyond the 248th. (the 248th is actually #247 in the counter since it starts at 0).

To test this issue, you would need to query a products table with more than 249 products. In my case I have 264 repeating regions of the fields. All of them show correctly all the way down to the 264th. If I view the source, I don’t find anything that is broken. But they won’t all post.

I’m using the latest version of DataBridge in DW CS6. I saw there were some updates but not for this version, just the CC versions so I’m not sure if maybe there has been an issue that was fixed or not.

The wa_appbuilder_php.php that I have has a copyright of “Copyright 2005-2007…” Is that they latest version?

Oh, one last thing. The redirect in the MRT doesn’t work either, unless I remove one of the form fields in the repeat.

I can provide more information if needed.

Thanks,
TroyD

This is probably an issue with your php.ini settings you would have to get updated on the server.

PHP has a couple of settings that could limit the form size:
post_max_size
max_input_vars
memory_limit

Most likely it is the post_max_size that you are running up against. You might be able to change it in your htaccess file:
[code]
php_value post_max_size 10KB
[/php]

Check your phpinfo to see which one is the likely problem and talk to your hosting provider about changing the value if the .htaccess entry doesn't work.

Ray,

This is happening on both my LOCAL and live server. Here are the settings I see when looking at phpinfo();

LOCAL (MAMP PRO)

post_max_size 32M
max_input_vars 1000
memory_limit 128M

Live server

post_max_size 8M
max_input_vars 1000
memory_limit 196M

Should I be looking somewhere else?

Your first post mentioned

php_value post_max_size 10KB

Should that be 10MB or 10KB?

Thanks,
TroyD

Those look like they would be large enough. Can you add the field back that breaks the page and give me a URL to reproduce and FTP access? I can take a look.

Actually the math is easy to figure out.

Both servers have set:
max_input_vars 1000

You have 5 fields in a form that repeats 248 times... that is over 1000 variables.

Try upping that value to 2000 and it looks like it would work.

Ah, your correct on the math. I didn't catch that. I will do that and give it a try, then report back.
I'm away from my computer at the moment but I will try this when I return and let you know either way.

Thanks again Ray!

TroyD

Ray,

As always, you were correct. That's all I needed to do. I feel a little foolish that I didn't think of that. It would be nice if php gave me an error message when I exceed the max input or something.

In any event, I increased it on both my local and production servers to 2000 and everything is working again.

Thanks so much,
TroyD