[case CPANEL-12822,case CPANEL-13105] phpMyAdmin max_input_vars error
I am getting this error message when I try to export a database in phpMyAdmin:
>Warning: a form on this page has more than 1000 fields. On submission, some of the fields might be ignored, due to PHP's max_input_vars configuration.
System info:
cPanel & WHM 64.0 (build 13)
phpMyAdmin Version information: 4.6.6
EasyApache 4
CloudLinux release 7.3
In WHM 62.0 (build 21) phpMyAdmin 4.0.10.18 this was working ok.
I tried changing max_input_vars in various php.ini but I get the same error.
Any ideas?
-
Hello, The php.ini for phpmyadmin should be this one: /usr/local/cpanel/3rdparty/etc/phpmyadmin/php.ini Do you still receive the same error if you modify that one? Thanks! 0 -
I changed max_input_vars to 10000 in /usr/local/cpanel/3rdparty/etc/phpmyadmin/php.ini: [LIST] - Is working as expected if I open it from WHM->SQL Services->phpMyAdmin: I get no errors.
- If I open phpMyAdmin from a cPanel user account I get the same error: max_input_vars is 1000. Thanks.
0 -
I tested this out on my test server and found that raising the max_input_vars in this file resolves the error when exporting a database that has more than 1000 tables. /usr/local/cpanel/3rdparty/etc/php.ini Does changing it there solve the issue for you as well? Thanks! 0 -
I tried changing it in /usr/local/cpanel/3rdparty/etc/php.ini: same problem. Maybe a compatibility issue with cagefs/php-selector? 0 -
If you are using Cloudlinux and cagefs, you may also need to update cagefs to load the new value with this command. cagefsctl --force-update If that doesn't work, you may need to rebuild the cagefs with this command. cagefsctl --reinit thanks! 0 -
Tryied with "cagefsctl --force-update" and "cagefsctl --reinit". Still the same. I made a "ps aux | grep user6517" while loading phpMyAdmin and I got this: user6517 665209 7.0 0.0 241536 19292 ? S 09:46 0:00 /usr/local/cpanel/3rdparty/php/56/bin/php-cgi /usr/local/cpanel/base/3rdparty/phpMyAdmin/navigation.php Is php-cgi using this php.inis? 0 -
Hi All ! Here my process: nano /usr/local/cpanel/3rdparty/etc/php.ini ---EDIT-- max_input_vars = 10000 ---- /usr/local/cpanel/bin/install_php_inis /scripts/restartsrv_cpanel_php_fpm Best regards! 0 -
Hi All ! Here my process: nano /usr/local/cpanel/3rdparty/etc/php.ini ---EDIT-- max_input_vars = 10000 ---- /usr/local/cpanel/bin/install_php_inis /scripts/restartsrv_cpanel_php_fpm Best regards!
This workerd for me too. Thanks QuentinC! Is this php.ini change persistent in cPanel updates?0 -
In a internal cPanel ticket I got this: Changes to /usr/local/cpanel/3rdparty/etc/php.ini will persist but will always need the following run afterward. /usr/local/cpanel/bin/install_php_inis 0 -
Hello, To update, internal case CPANEL-12822 is open to determine how to best address the issue where databases with more than 1000 tables can't be exported in phpMyAdmin because the default max_input_vars setting is too low. I'll update this thread with more information on the status of this case as it becomes available. In the meantime, the workaround is to manually increase the value in the /usr/local/cpanel/3rdparty/etc/php.ini file, and then run the following commands: /usr/local/cpanel/bin/install_php_inis /scripts/restartsrv_cpanel_php_fpm
Thank you.0 -
This workerd for me too. Thanks QuentinC! Is this php.ini change persistent in cPanel updates?
Changes there don't persist. Cpanel updated yesterday and wiped out the edits I made to usr/local/cpanel/3rdparty/etc/php.ini (which is a symlink to /usr/local/cpanel/3rdparty/php/56/etc/php.ini). This happened on 3 different servers.0 -
Changes there don't persist. Cpanel updated yesterday and wiped out the edits I made to usr/local/cpanel/3rdparty/etc/php.ini (which is a symlink to /usr/local/cpanel/3rdparty/php/56/etc/php.ini). This happened on 3 different servers.
Hello, As a temporary workaround, you could setup a custom bash script that replaces the max_input_vars value and then setup a hook to automatically run that custom bash script after each cPanel update. EX:mkdir -p /root/custom/ touch /root/custom/postupcp.sh chmod 0755 /root/custom/postupcp.sh vi /root/custom/postupcp.sh
When editing this file, add a line such as this:replace "; max_input_vars = 1000" "max_input_vars = 2000" -- /usr/local/cpanel/3rdparty/etc/php.ini ; /usr/local/cpanel/bin/install_php_inis ; /scripts/restartsrv_cpanel_php_fpm
Replace "2000" with the new value you'd like to set. Then, to have this script execute automatically after each cPanel update, run this command:/usr/local/cpanel/bin/manage_hooks add script /root/custom/postupcp.sh --manual --category System --event upcp --stage post
This will ensure the custom value is preserved through cPanel updates. Note: Ensure to remove this custom script using the following commands once we publish a resolution for this issue:rm /root/custom/postupcp.sh /usr/local/cpanel/bin/manage_hooks delete script /root/custom/postupcp.sh --manual --category System --event upcp --stage post
Thank you.0 -
Thanks Michael. In case folks don't wanna set up scripts, hooks, and crons, here is a function you can run from root for an on-demand fix. In this example 6000 is the value of max_input_vars written to ini's: # whm-max-input 6000
To enable it, put this in /root/.bashrc and run command ". /root/.bashrc" to load into session:whm-max-input() { if [ -z "$1" ]; then vars="2000" else vars=$1 fi sed -in --follow-symlinks "s/[\; ]?max_input_vars = [0-9].*/max_input_vars = ${vars}/" /usr/local/cpanel/3rdparty/etc/php.ini /usr/local/cpanel/bin/install_php_inis /scripts/restartsrv_cpanel_php_fpm php -v }
Enjoy0 -
Yikes, not sure why but lots of PMA fails now for a certain DB that didnt seem to get much larger. I cant edit the post above, so to extend upon that max-whm function to include some other boosts as well as a way to revert it back to default: gist.github.com/dhaupin/1f7ac8c7369bc60f385430e449a611eb 0 -
I just can't understand why stuff like this can not be fixed asap (few days) by cPanel. This issue probably creates thousands of tickets for providers and the fix of default php.ini setting should take about a 30 seconds for a cPanel developer. Just setting max_input_vars to 10000 by default, would have solved all the problems. Can someone explain this logic to me please? 0 -
Hello, In my case, I had some additional steps, as the user was still getting the error. What I did was: Modified values in: /usr/local/cpanel/3rdparty/php/56/etc/php.ini cagefsctl --force-update service cpanel restart Remove user's cpanel cache folder: rm -rf /home/$user/.cpanel After that, run scripts /usr/local/cpanel/bin/install_php_inis /scripts/restartsrv_cpanel_php_fpm Relog into user's cPanel. I'm running: Cloudlinux 7 (CageFS and all) cPanel 11.64.0.21 EasyApache 4 Regards. 0 -
Waiting for a fix to be incorporated by default. 0 -
Hello, To update, the following resolutions are included with cPanel version 64.0.24: [LIST] - Fixed case CPANEL-12822: Bump max_input_vars to 10000 for phpMyAdmin.
- Fixed case CPANEL-13105: Ensure phpMyAdmin uses the correct ini files. The full change log is available at: 64 Change Log - Change Logs - cPanel Documentation Thanks!
0 -
Hello, I just have a couple of questions, as this is still not solved for me. Which php.ini has the cPanel update modified? All I see is the 1000 value for max_input_vars instead of 10000: [root@server1 php]# pwd /usr/local/cpanel/3rdparty/php [root@server1 php]# grep -ir "max_input_vars" . ./56/etc/php.ini.dist:; max_input_vars = 1000 ./56/etc/php.ini,v:; max_input_vars = 1000 ./56/etc/php.ini.bak:; max_input_vars = 1000 ./56/etc/roundcube/php.ini:; max_input_vars = 1000 ./56/etc/phpmyadmin/php.ini:; max_input_vars = 1000 ./56/etc/phppgadmin/php.ini:; max_input_vars = 1000 ./56/etc/horde/php.ini:; max_input_vars = 1000 ./56/etc/php.ini:; max_input_vars = 1000
Should I look somewhere else? Do I need to update manually again or should it work by default? Thank you.0 -
I just have a couple of questions, as this is still not solved for me. Which php.ini has the cPanel update modified? All I see is the 1000 value for max_input_vars instead of 10000:
You should see the following output after updating to cPanel 64.0.24 or newer:# grep max_input_vars /usr/local/cpanel/3rdparty/php/56/etc/phpmyadmin/php.ini max_input_vars = 10000
If not, check to verify you disabled any custom workarounds you implemented when you first encountered the issue. Thank you.0 -
You should see the following output after updating to cPanel 64.0.24 or newer:
# grep max_input_vars /usr/local/cpanel/3rdparty/php/56/etc/phpmyadmin/php.ini max_input_vars = 10000
If not, check to verify you disabled any custom workarounds you implemented when you first encountered the issue. Thank you.
I was wondering if/when cPanel 64.0.24 is/will be pushed to the Stable tier? I've had the max_input_vars error as well but the hosting company I'm with has control over updates. They said cPanel should automatically update when it's pushed to the stable tier. Thanks!0 -
I was wondering if/when cPanel 64.0.24 is/will be pushed to the Stable tier? I've had the max_input_vars error as well but the hosting company I'm with has control over updates. They said cPanel should automatically update when it's pushed to the stable tier. Thanks!
Hello @bj3782, 64.0.24 was published to the STABLE build tier today. Automatic updates occur when the "upcp" cron job runs on the server, so the server should update to this version within 24 hours if your hosting provider has enabled automatic updates. Thanks!0 -
Hello, I still get this error when I go to PHPMyAdmin -> Designer. I'm attaching a screenshot. My cPanel version is : [root@server1 zapatoro4]# cat /usr/local/cpanel/version 11.64.0.24
The max_input_vars value is indeed 10000:[root@server1 php]# grep max_input_vars /usr/local/cpanel/3rdparty/php/56/etc/phpmyadmin/php.ini max_input_vars = 10000
What I modified to solve this error was to edit this file: /usr/local/cpanel/3rdparty/php/56/etc/php.ini and not this one: /usr/local/cpanel/3rdparty/php/56/etc/phpmyadmin/php.ini Will this fix be incorporated into cPanel or should I just modify it every time I need it? Furthermore, will cPanel overwrite all of my modifications? Thank you.0 -
Hello @Havri, The issue should have been addressed with the resolution included in cPanel 64.0.24. Could you open a support ticket using the link in my signature so we can take a closer look at your system? Thank you. 0 -
Hello, I opened a ticket. The ticket # is 8555805. Thank you. 0 -
Hello, There is another bug related to this. The issue ID is CPANEL-13518. The reason was: "the issue appears when I enable the "PHP-FPM Service for cPanel Daemons" in "WHM >> Service Configuration >> Service Manager." This causes phpMyAdmin to use the /usr/local/cpanel/3rdparty/php/56/etc/php.ini file instead of the one specific for it. I only identified this when noticing it was disabled on my test server but enabled on yours." Thank you. 0 -
Hello, There is another bug related to this. The issue ID is CPANEL-13518. The reason was: "the issue appears when I enable the "PHP-FPM Service for cPanel Daemons" in "WHM >> Service Configuration >> Service Manager." This causes phpMyAdmin to use the /usr/local/cpanel/3rdparty/php/56/etc/php.ini file instead of the one specific for it. I only identified this when noticing it was disabled on my test server but enabled on yours." Thank you.
I'll monitor this case and update this thread once we publish a resolution. Thank you.0 -
I am having the same issue. I updated /usr/local/cpanel/3rdparty/etc/php.ini but after cpanel update it was changed. 0 -
Hello, Yes, well the bug fix will probably solve this problem. PHPMyAdmin should read /usr/local/cpanel/3rdparty/php/56/etc/phpmyadmin/php.ini and not this one /usr/local/cpanel/3rdparty/php/56/etc/php.ini when having the "PHP-FPM Service for cPanel Daemons" enabled. 0 -
Same issue here. PHPMyAdmin with PHP-FPM is using /usr/local/cpanel/3rdparty/php/56/etc/php.ini instead of /usr/local/cpanel/3rdparty/php/56/etc/phpmyadmin/php.ini I will apply the workaround again. 0
Please sign in to leave a comment.
Comments
32 comments