Support

February 23, 2016 at 3:38 am

Hi Christine,

We’ve seen it before were the sites theme added over 12,000 inputs into the page (yes really!) so can you first go to the event editor where this error is being thrown, open up Chrome dev tools and search for ‘input’ in the elements tab – http://take.ms/hpFM6

How many instances do you find?

February 23, 2016 at 5:09 am

Thank you.

So EE pulls the max input vars directly from your server using ini_get( 'max_input_vars' ); which means that whatever PHP is told the max_input_vars setting is, EE should also have.

Can you go to Event Espresso -> Maintenance -> System Information.

Search for max_input_vars and check the value shown, what does it say?

On the event that shows the notice, if you save, then add 1 additional ticket and save again, does the ticket stay or is it removed?

February 23, 2016 at 6:25 am

Event Espresso -> Maintenance -> System Information = 1000
Should I change to 2000?

In your initial reply you mentioned you’d changed this to 6000, are the changes within user.ini not being applied?

You’ll want at least 3000 to give yourself some extra vars just in case.

So max_input_vars right now is 1000 and the vars on the page are working, so likely your theme (or another plugin) is adding a lot of inputs later on within the editor. The tickets etc are still working as they are loading before the options.

If the changes within user.ini are being applied you may need to contact your host and have them up the limit for you. You can chang the value through php.ini, user.ini (if the host allows) or though .htaccess, so you could use something like:

php_value max_input_vars 3000
php_value suhosin.get.max_vars 3000
php_value suhosin.post.max_vars 3000
php_value suhosin.request.max_vars 3000

to the .htaccess file within the WordPress root directory and see if that works.

The above should work, however as mentioned you may be better contacting your host and see what they recommend as it does depend on server setup.

February 24, 2016 at 2:58 am

There is no internal caching that would effect this, its not that EE is not recognizing the change, the information within:

Event Espresso -> Maintenance -> System information

Which shows your current max_input_vars settings is actually the output from the function phpinfo() and is direct from your server, not EE.

The notice that shows up on the editor uses ini_get() to get the value from your current PHP runtime environment so again is direct from your server.

So this means that the user.ini changes are not taking effect. Its not that you need to wait for any caching to clear (there is none) but that the changes simply have not been applied. Your host may need to restart apache for the changes to take effect, or possibly the changes from user.ini are only taking effect within the directory that file is within (which is odd but we’ve seen happen previously)

Did you try adding the code above to the .htaccess file?

One way to test this is to create a test.php file which contains:

<?php
phpinfo();

and placing that within /wp-content/plugins/ and navigating to that file to view the output (make sure you delete the file when finished), check there for max_input_vars. It is likely it will still show 1000 which again means the changes have not actually been applied.

Either way I would recommend contacting your host once again and have them check if the changes actually applied (they can use the method above).