There is no hard coded limit. When you submit the edit, do you get any error messages? Can you link to the page should the issue so I can debug it (although I'm afraid it will be Tuesday before I can as I'm travelling atm, and phone screens don't lend themselves to debugging!).
Also it would be worth looking in the browsers network tools to make sure the full data set is being submitted.
Sorry for the delay. No I did not see any error messages. I looked at the JSON post/response data and it only returns 12 rows while it POSTs all of the rows so I suspect it has something to do with server side processing. Here is a link to the page you can debug it on: [retracted]
Let me know if you would like to see the javascript used to create this page or the server side processing script.
Thanks for the link - I can indeed see the issue. However I'm afraid I'm not immediately sure what is causing it!
Could you show me your server-side code (i.e. table.mains3.php)?
Also, could you try adding:
formOptions: {
main: {
submit: 'allIfChanged'
}
}
to your Editor initialisation. That will cause it to submit only the changed data. I'm wondering if the server is truncating the input data (although that would be an odd thing to do - its only 90K that is being sent).
I tried adding that option to my initialization. Unfortunately, it did not seem to resolve the issue. Here is the server side code: http://pastebin.com/U8fzBJVq
Also, would you mind deleting the link to the page I posted once you are done? I cannot edit that post anymore.
The formOptions object should actually go in the Editor initialisation rather than DataTables (its currently in the DataTables init, but commented out). Could you move it there and see if that helps?
I've just tried setting 50 rows in a single edit in this example (you need to run $('#example').DataTable().page.len(50).draw() on the console to show 50 rows since that example doesn't have a page length control), and it appears to work without any problem. I'm also not aware of any options to limit the number of queries that PDO can run.
If you take a look in your server's error logs (and MySQL logs, if you have MySQL logging enabled), does do they show anything?
I tried moving it there and unfortunately it still didn't work. I did find something interesting that was dumped in the apache log the last time I tried to edit more than 12 rows.
[Thu Jun 16 12:20:39.591528 2016] [:error] [pid 17525] [client 69.204.66.36:51346] PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0, referer: http://{retracted}/pricetool.html
After reading up on this error it appears that it truncates an extra data past the limit which matches my situation perfectly. I upped the max_input_vars to 10000 and it appears to work perfectly.
Rather than increase the number of max_input_vars in the php.ini, beyond the default 1000, is it possible for the client javascript to send a single json with all the editor form field parameters? Rather than one for each row being edited. Then the receiving php script could decode this json.
Replies
There is no hard coded limit. When you submit the edit, do you get any error messages? Can you link to the page should the issue so I can debug it (although I'm afraid it will be Tuesday before I can as I'm travelling atm, and phone screens don't lend themselves to debugging!).
Also it would be worth looking in the browsers network tools to make sure the full data set is being submitted.
Regards,
Allan
Sorry for the delay. No I did not see any error messages. I looked at the JSON post/response data and it only returns 12 rows while it POSTs all of the rows so I suspect it has something to do with server side processing. Here is a link to the page you can debug it on: [retracted]
Let me know if you would like to see the javascript used to create this page or the server side processing script.
Thanks
The link requires a login.
Server-side processing means that only the rows currently displayed will be sent by the server.
Allan
I removed the login. You should be able to access it now.
Sorry I'm obviously not 100% on the terminology for datatables. Regardless, the edit request is responding with less rows than it is POSTing.
Thanks
Thanks for the link - I can indeed see the issue. However I'm afraid I'm not immediately sure what is causing it!
Could you show me your server-side code (i.e.
table.mains3.php)?Also, could you try adding:
to your Editor initialisation. That will cause it to submit only the changed data. I'm wondering if the server is truncating the input data (although that would be an odd thing to do - its only 90K that is being sent).
Allan
I tried adding that option to my initialization. Unfortunately, it did not seem to resolve the issue. Here is the server side code:
http://pastebin.com/U8fzBJVq
Also, would you mind deleting the link to the page I posted once you are done? I cannot edit that post anymore.
Thanks for the reply.
The
formOptionsobject should actually go in the Editor initialisation rather than DataTables (its currently in the DataTables init, but commented out). Could you move it there and see if that helps?I've just tried setting 50 rows in a single edit in this example (you need to run
$('#example').DataTable().page.len(50).draw()on the console to show 50 rows since that example doesn't have a page length control), and it appears to work without any problem. I'm also not aware of any options to limit the number of queries that PDO can run.If you take a look in your server's error logs (and MySQL logs, if you have MySQL logging enabled), does do they show anything?
Regards,
Allan
I tried moving it there and unfortunately it still didn't work. I did find something interesting that was dumped in the apache log the last time I tried to edit more than 12 rows.
[Thu Jun 16 12:20:39.591528 2016] [:error] [pid 17525] [client 69.204.66.36:51346] PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0, referer: http://{retracted}/pricetool.htmlAfter reading up on this error it appears that it truncates an extra data past the limit which matches my situation perfectly. I upped the max_input_vars to 10000 and it appears to work perfectly.
Thanks
What would do it! Fantastic. Thanks for letting me know about this and great to hear you've got it working now!
Regards,
Allan
I messed up and forgot to remove the IP from my last post... Would you mind removing it one more time?
Thanks
Sure - its done now.
Rather than increase the number of max_input_vars in the php.ini, beyond the default 1000, is it possible for the client javascript to send a single json with all the editor form field parameters? Rather than one for each row being edited. Then the receiving php script could decode this json.
Yes. The last example in the
ajax.datapage shows how that can be done.If you are using the PHP libraries you could then
json_decodethat into an array and pass that into theprocess()method rather than$_POST.Nice idea - thanks for posting that!
Allan