Max_input_vars more than 1000 fields


#21

From what I’ve gathered in most cases for MySQL databases, usually, a php.ini file within the site directory has a line of code for “Max_input_vars” that can increase the limit from 1000 fields (initially) to whatever else you set it.

This error apparently shows once a table goes over 1000 fields (rows x columns). The means to fix it would be to set the Max_input_vars higher to accommodate. In some cases, that’s only accessible from the host’s dev team.


#22

DIdn’t receive this message before, when there were even more columns in my table. Host has changed that ini-file in the last 2 weeks or so?


#23

No developers haven’t changed anything and we won’t change anything, there must be a solution surely if it was working fine previous.


#24

Any ideas? Even unable to delete a row (I can if I use a query, but not by just clicking a button)…


#25

A solution is here. The setting max_input_vars cannot be set at run-time with ini_set, but you can reset it in an .htaccess file:

php_value max_input_vars 2000

I’ve just tested that, and it works on 000webhost.com. However, I would consider that a temporary fix - the warning means you are using more than 1000 fields on a form, which is an enormous number. If this is affecting phpMyAdmin, I wonder if it is using a large number of hidden <input> fields in the background - check the HTML source?


#26

More than 1000 fields on a HTML-form?! 2 hidden input fields, that’s it. The problem isn’t inserting with an html-form, the problem is in phpmyadmin. I have 47 columns in that one table, a few dates and int, a lot more varchars (50-100), and 1 mediumtext: is that so ‘abnormal’? Never had any trouble with it.
So actually you’re saying: make another table and store half of the data in that one and it will be solved?


#27

Yes, that is the cause of the error you are getting.

I don’t know phpMyAdmin well, especially not from a open-source development perspective. Perhaps some elements are created on a form submit or something? Without a reproducible test case in front of me, I can only speculate.

phpMyAdmin uses HTML forms and PHP, so it could conceivably be affected by this PHP issue. It isn’t related to inserting (in a database sense) anyway - it is to do with the how PHP creates variables in a POST operation (e.g. in a form submission).

Definitely not - a database structure should not be dictated by a bug in a development tool. The bug needs to be found and resolved, or the tool needs to be changed.

As I say, I will need a reproducible test case to help further. I suggest you create a database export that someone could load into their own database in order to examine the issue further. Please add detailed, step-by-step bug reproduction instructions also.

Update

Looks like several folks have had issues with phpMyAdmin with this setting.


#29

If I delete some columns the message disappears (unless I want to see 50 instead of 25 rows in phpmyadmin).
But even with fewer columns I still can not use ‘edit, copy, delete’ (the options at the left of every row in that specific table). Inserting a new row works, and using a sql-query to delete a row works as well.
Any ideas?


#31

Does it tell you there is no unique column? :slight_smile:


#32

No, the unique column is the autocrement one (unless I misunderstand you).
It only/still shows the second screenshot on top of this thread.