Big tables can exceed PHP input variables limit

Old issue I know, but...

My client is actually reporting this problem using quite a small CSV, although I can't replicate it myself. Any ideas why this would be happening for them but not me?

If you're having issues on one server but not another, check the setting for max_input_vars in php.ini, maybe you can just increase it.

I'm also having this issue and it seems kinda redundant for us to post that many values, our client is only using the CSV import function anyway. I'd vote for a rewrite of the backend storage to circumvent this issue and open up for different widgets.

Following. We seem to have multiple issues, this one included, since v 7.23. We don't seem able to import any csv data at all right now - which I presume can't be connected to this max_input_vars issue but thought I'd mention it just in case.

Q.

tagging

I submit a patch that solves the problem for CSV files.

For maintainers/developers:
After the CSV uploading, the parsed table gets stored to $form_state. During the final submission of the form, an extra validation function checks if the max_input_vars has been exceeded.
If so, the stored tablefield values from $form_state are retrieved, and get copied to $form_state['values']. The user gets a warning that if he changed any value on browser, after uploading the CSV, his changes will be lost, and he is advised to reupload the CSV with the correct values.
Also, if the too large table did not come from a CSV upload (which seems quite impossible, as the max_input_vars is by default set to 1.000 and it is unlikely that the user would type 800 table cells on keyboard!) he receives a drupal error, where he is adviced to store his table data through a CSV upload.

If you decide to commit the patch, this is a common work of me and esolitos (https://www.drupal.org/u/esolitos) so please don't forget to credit him too :)

After a reroll against the latest dev the attached example CSV is imported correctly however the node does not save and keeps stuck on the Edit page.

This is probably due to the provided validation function.

Getting these messages:

The dimensions of the table are too large to be processed on browser. You are advised to import your table through a CSV file, to prevent data loss. (at least it shows the validation is kicking in)
Status message Successfully imported р-_18.12.13_utf8.csv

In my testing I am seeing the node save correctly, and the validation messages are appearing on the node view page. I'm unable to reproduce the problem reported above:

the node does not save and keeps stuck on the Edit page.

I rerolled the patch again, made a few coding standards updates, and cleaned up the language in the error messaging. New patch for review.

One quick note... Though this patch does help the process of editing existing tables that exceed max_input_vars, it does not address what happens when you attempt to add a new row or column to an already-too-large table. I still get an ajax error;

The website encountered an unexpected error. Please try again later.    

ReadyState: ,

We should adapt the same error messaging for rebuilding the table in all cases, and let the user know that uploading a CSV file with the intended number of rows and/or columns is recommended.

We should adapt the same error messaging for rebuilding the table in all cases ..

I guess it need work then.

This is a reroll of the previous patch that applies cleanly (it does not incorporate new suggestions yet)