Editor 'truncation sanity check' doesn't work with JSON - possible fix to max_input_vars issues?

ilowe

Hello!

I've seen multiple posts of users running into issues trying to import, delete, or edit many records at once using PHP, and the posted solution is always to increase max_input_vars in the php.ini or .htaccess file.

Using the network inspector in chrome dev tools, I observed that editor sends each cell as an individual POST parameter in the form of data[row][column]: value, so if you try to multirow edit, import, or delete n number of rows, your POST request will have (n * # of columns) input variables. This quickly adds up, as you would reach the default of max_input_vars of 1000 trying to edit/delete 100 rows with 10 columns at once.

So my workaround to this is to stringify the data and then decode it on the server side, as max_input_vars only applies to $_POST, $_GET, and $_COOKIE, right? (this is an assumption of mine from what I've read...this max doesn't apply to every function in a php program?) Doing this reduces the input vars from rows * columns to 2.

"data": function(d) {
  return  { 
    data: JSON.stringify(d.data),
    action: d.action, 
  }
}

So once I decode it on the server side back to the format that editor expects, ->process() takes in the array with all of the cell values, looks for the edit/remove/create action, and processes accordingly.

The problem is this line of code here in Editor.php

// Sanity check that data isn't getting truncated as that can lead to data corruption
if ( $data && count($data, COUNT_RECURSIVE) >= ini_get('max_input_vars') ) {
  $this->_out['error'] = 'Too many rows edited at the same time (tech info: max_input_vars exceeded).';
}

With these lines removed, and my data sent to the server how I did, I can import/edit/delete rows to my hearts content all while having max_input_vars set to 1000. Is this okay to do?

Without having these lines removed, Editor is unaware of the fact that the data was sent as one instead of many parameters, and it checks it against max_input_vars anyway, producing an error.

allan

Yes, this is a really good solution to the issue - thanks for sharing your suggestion. The one key thing to remember is that there is still a limit - the make POST data size. But usually that isn't going to be a problem unless you are editing many thousands of rows!

With these lines removed [...] Is this okay to do?

Yes absolutely. I'm wondering if we should provide this ability built into Editor (an option on the client-side and automatic on the server-side). I've added a feature request for this to Editor 2.1 and will look into how we might do this. In the mean time, your workaround will do the job nicely.

Allan

hapi

May thanks for this! I'm importing a list of IDs with more than 6500 entries with no problems!