Phpmyadmin: 4.7.7: PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini.

[thelounge-zz]

4.7.7 is broken

just dispaly a table with 25 out of 98 records and 14 columns and click edit on a random record - other than 4.7.5/4.7.6 you don't get the form part but the error message below in the error_log

[23-Dec-2017 16:37:04 Europe/Vienna] PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0
[23-Dec-2017 16:37:49 Europe/Vienna] PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0
[23-Dec-2017 16:38:09 Europe/Vienna] PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0
[23-Dec-2017 16:38:38 Europe/Vienna] PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0

[jeff-kilbride]

Same here. I am getting the following warning popup on every screen when I set Number of rows greater than 25. With Number of rows equal to 25, there is no warning.

I'm running on AWS Elastic Beanstalk with PHP 7.0.25.

[thelounge-zz]

sounds like terrible inefficient ajax stuff where i don't get what the hell is going on here when you just edit a single record based on it's primary key - i wantr back the times as PMA worked completly without ajax at all

[OlafvdSpek]

@thelounge-zz https://www.adminer.org/ ? ;)

[thelounge-zz]

@OlafvdSpek dumb trolling - when i switch everytime abug occurs in some software chnage the software i would be 365 days busy with only that

[jeff-kilbride]

@thelounge-zz I'm having another issue with 4.7.7. (#13907) Just wondering if you are also seeing this problem.

I have reverted to 4.7.6 for now.

[thelounge-zz]

i revert after the first problem in basic tasks like edit a single record, so 4.7.7 was only there for 2 minutes

[HLeithner]

anything new on this problem? even increasing the php limit to 2000 doesn't change anything on a 100*10 fields list.

[nijel]

The problem is caused by using POST for all these links now what leads to massive form nesting. This has been already addressed in master and probably needs to be backported to 4.7 branch. Related commit is 3b9fb2b664632557866feb083b59743ed60d1e22

[thelounge-zz]

don't get me wrong but what needs any form nesting when you just edit a single record?
it's a design error when you pipe the whole table around for a single record with 10, 20 or 50 fields

do you developers have only test-tables with 5 records or how can it be that it took me 3 clicks with 4.7.7 to qualify it unusable (datebase -> tablename -> edit on the first record -> boom)

[nijel]

This is side effect of fixing PMASA-2017-9 and apparently the embargoed patch didn't get tested on this setup.

[thelounge-zz]

in reality this is a side-effect of massive AJAX stuff for trivial operations - you don't need anything else than the primary key and a token to display the edit form for a record on the next screen

[HLeithner]

ok thx, any timeframe for 4.7.8? because pr is not really compatible with 4.7.7.

[nijel]

It's unrelated to AJAX - it's caused by fact that we're now using POST for any action containing SQL query (for privacy reasons), what for example are sort links on the browse page or edit links for rows. As this is done already inside <form> element, it's get transformed in extremely ineffective way including all forms. However it didn't matter so far as it was used just in few places, but it's way more visible after 4.7.7. As the code handling this was quite complex and causing problems, I've rewritten it some time ago for 4.8 (in 3b9fb2b664632557866feb083b59743ed60d1e22), but that was not included in the 4.7 branch as it's quite massive change which can lead to other problems as well.

In the end the 4.7 branch is supposed to be maintenance only, however fixing security issues sometimes forces us to do bigger changes and this is always risky...

The 4.7.8 is currently scheduled on January 22.

[thelounge-zz]

i still don't see a reason to post that massive amount of data around

just generate the form with only the needed data on demand and you should be done or wrap a form around every row which get submitted onclick

"however fixing security issues sometimes forces us to do bigger changes" - well, but not completly untested when it breaks even on a table with 25 records and a handful of fields

[nijel]

The problem is that this all is done in single form, it just contains elements for all nested forms as subform[N]. I know this is bad idea, but the code is there for quite some time and was not causing problems so far. It's not just being used much more...

https://github.com/phpmyadmin/phpmyadmin/blob/2ceb2419a3ede3f803790245efa70b76baae6561/libraries/Util.php#L1866-L1871

Yes, I've apparently messed up testing of the security fix. It was touching pretty much all pages and I didn't test scenario which you believe is obvious, but didn't came to my mind. You are more than welcome to contribute testcase which would cover this.

We certainly could use more manpower so that such things get better tested. With current manpower I was happy that patch got at least reviewed by one peer. It can easily happen that mistakes are going through unnoticed.

[ibennetch]

I'll chime in here to add that I also missed this during the embargoed security testing phase. I did some testing, but wasn't thorough enough to catch this. We'll get it fixed for 4.7.8.

[CyberCr33p]

Any news about this issue?

[shucon]

I did some research about it , but couldn't find a way to fix it without editing php.ini . Any suggestions about how to get started?

[thelounge-zz]

downgrade to previous release, make sure you ahve some http-basic auth in front of phpMyAdmin or when possible ip-restrictions - edit php.ini because of some broken release of a random software won't happen here, especially not security relevant server settings - max_input_vars has a good reason

[shucon]

@thelounge-zz thanks for your suggestion , but I'm seeking help to fix the bug in the code itself.

[thelounge-zz]

congratulations - 4.7.8 is still broken - well done for point releases

Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0
phpMyAdmin - Error

Error during session start; please check your PHP and/or webserver log file and configure your PHP installation properly. Also ensure that cookies are enabled in your browser.

[HLeithner]

Awesome the second security release I can't use because phpmyadmin doesn't work anymore.

[cjchagnon]

I want to comment with something productive, but can't think of much to say other than to echo the concern that this was moved back from 4.7.8 to 4.7.9;

This bug has made the tool very difficult to work with on tables that have lots of attributes, or lots of rows.

My current workaround for my end-users is to have them use pagination, but, with this issue, table search / filtering also becomes unusable. So a quick turnaround on this would be much appreciated.

[skyale]

I see that 4.7.9 is in "No due date" status, while 4.8.0 is "Due by March 21, 2018". So we'll don't see 4.7.9, and will jump directly to 4.8.0?

Thank you for your work, we really appreciate it.

[jebsolutions]

Mentally insert some rants about 99% useless POST data. :)

Here's a fun experiment:

• In firefox...launch phpmyadmin
• Browse a table that fails on edit
• Right-click on a row in the table and select "Inspect Element". It will open the dev tools.
• Find the parent for this row of data....right click and delete node.
• Go nuts and delete all the tr's in the table showing the database rows except one.

So now you have a browse screen with only one row of data. What happens when you click edit?

Magically it all works. So all that data isn't needed.

The proper fix was already mentioned...split into sub-forms and/or build a proper POST with just the needed data.

However...consider this as a possible easy hack:

Before you post the "form" have the javascript delete all the rows in the table above and below the one row of data that was actually clicked (like our manual node delete experiment). This will remove the useless data that isn't needed anyway.

Jquery details left to those who enjoy that stuff.

[boomsya]

in phpMyAdmin-4.8+snapshot all OK. Thanks.
Waiting stable version

[nijel]

Should be fixed in QA_4_7 as well thanks to #14036.

[skyale]

Hi everyone, do you test 4.7.9?

Is it resolved error message: "Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini" ?

[HLeithner]

yes seams to work now.

[jebsolutions]

Thank you! :)

So far 4.7.9 looks good! 👍

[skyale]

Great! Everything works!

[llamafilm]

Now that this is fixed, how many input variables are there — would it be equal to the number of rows? Or because of the grid edit, would it be rows * columns? I'm just trying to figure out how large max_input_vars really needs to be.