|
Scott Gillard
|
February 4, 2015 at 8:03 am
I’m getting this error:
“The number of inputs on this page has been exceeded. You cannot add anymore items (i.e. tickets, datetimes, custom fields) on this page because of your servers PHP “max_input_vars” setting.”
It hasn’t happened before. I have asked my host, they indicated I could modify it in the .htaccess file. I added the following:
“php_value max_input_vars 30000” to the file.
I also updated EE to 4.6.0 this morning but the error was occurring before that and continues.
I have an event that goes on sale tomorrow with a main ticket price that I can not add.
event page: http://boomboxoffice.ca/events/duchess-malfi/
How can I fix this? Any help is much appreciated as always.
|
|
Josh
|
February 4, 2015 at 8:16 am
Hi Scott,
The error you are seeing is due to the number of ticket types for the one event. Each ticket type multiples the number of input_vars, and since your server is hitting its max_inputs_vars limit, it will not allow you to add more ticket types.
Since it doesn’t appear to be working to change the limit in the .htaccess file, perhaps your host can change it in the php.ini file?
Alternatively, you can also break out some of the tickets into separate events, which will reduce the number of input_vars per event.
|
|
Scott Gillard
|
February 4, 2015 at 9:25 am
I asked my host to make the change and the error still pops up. Thoughts?
S
|
|
Tony
|
February 4, 2015 at 9:35 am
Hi Scott,
Can you go to Event Espresso -> Maintenance -> System Information tab.
Then search for max_input_vars and see what the value is there. If it is still 1000 then the change your host made is not set to be applied recursively through subdirectories. In other words they have altered the .htaccess file within the root directory, and that root directory now has a limit of 3000, sub directories within root, still use the global setting:
/root/ = 3000
/root/subdirectory/ = 1000 (PHP’s default setting)
If that is the case your host needs to setup the .htaccess rules to apply recursively through subdirectories.
|
|
Scott Gillard
|
February 4, 2015 at 11:08 am
Thanks for the quick replies. So very much appreciated.
The host has been notified and has indicated that the issue is not related to .htaccess failing to affect the sub folders. I’m awaiting word on what they did (whether they modified the php.ini file or .htaccess)
I’m way out of my comfort zone here and I just lost my Coder. :/
|
|
Josh
|
February 4, 2015 at 11:32 am
Hi Scott,
Did you happen to check for the max_input_vars value that’s reported in Event Espresso -> Maintenance -> System Information ?
|
|
Scott Gillard
|
February 4, 2015 at 11:49 am
I did, it does 1000. He is still looking into it. I can provide access (I think I did previously) if there’s any value in having a look.
S
|
|
Lorenzo Orlando Caum
|
February 4, 2015 at 1:01 pm
Hi Scott, did your host make that change via a PHP.ini file in the WordPress root?
If so, they may need to restart the services on the server for it to take effect.
—
Lorenzo
|
|
Josh
|
February 4, 2015 at 1:03 pm
Okay that’s good to know. Since it’s showing that it’s still using the default (1000), this means they need to update the max_input_vars setting to allow for the number of ticket options you want to add to this event.
|
|
Scott Gillard
|
February 4, 2015 at 3:56 pm
So, he said he changed it in the php.ini file. I checked again and it says max_input_vars 1000 still.
Perhaps it’s a matter of restarting the service as Lorenzo indicated. Fingers crossed. Thanks again to all for the help.
|
|
Scott Gillard
|
February 4, 2015 at 5:51 pm
Hi guys,
Thanks for all this help. I really appreciate it.
I can again add tickets. It seems the issue has been somewhat resolved.
I am now getting the following error, I am unsure where this should land in terms of support so I’m sharing it with you and the host.
“Warning: Invalid argument supplied for foreach() in /var/www/vhosts/ourhousingcoop.ca/httpdocs/boombox_v3/wp-content/plugins/event-espresso-core-reg/core/helpers/EEH_Autoloader.helper.php on line 183”
|
|
Tony
|
February 5, 2015 at 5:26 am
Hi Scott,
We have had a few reports of that error and are investigating the cause.
|
|
Scott Gillard
|
February 5, 2015 at 5:36 am
I’ve had to shut down the site, any known workarounds? The error is a visible front end error.
S.
|
|
Tony
|
February 5, 2015 at 6:32 am
Do you have WP_Debug enabled?
The error should not be visible on the front-end unless WP_Debug is enabled or your server has error_reporting set to true.
|
|
Josh
|
February 5, 2015 at 7:04 am
Hi Scott,
A fix is in progress for the autoloader error.
In the meantime, you can turn off WP_DEBUG and ensure that error display is turned off. You can turn off error display by editing your wp-config file. The “For developers” section of the wp-config file should look like this:
define( 'WP_DEBUG', false );
@ini_set( 'display_errors', 0 );
|
|
Scott Gillard
|
February 5, 2015 at 8:17 am
That worked perfectly. How can I buy y’all a beer?
Also, is it possible this error is related to using 4.6.0p with WP 4.0 instead of 4.1?
I have not yet upgraded WP to 4.1 and I have completed an upgrade of EE 4.6.0p. I will complete the upgrade and then let you know if the error persists.
Regards and a million thank yous,
S.
|
|
Dean
|
February 5, 2015 at 8:50 am
Hi,
Support staff do link to their Amazon Wish lists here if you are feeling particularly generous: https://eventespresso.com/about/
The max_input_vars is a PHP /Server setup thing more than WordPress, so upgrading shouldn’t be an issue. As always do a site back up before updating!
|
|
Scott Gillard
|
February 5, 2015 at 9:39 am
I was thinking the older version of WordPress was causing this error:
“Warning: Invalid argument supplied for foreach() in /var/www/vhosts/ourhousingcoop.ca/httpdocs/boombox_v3/wp-content/plugins/event-espresso-core-reg/core/helpers/EEH_Autoloader.helper.php on line 183?
|
|
Tony
|
February 5, 2015 at 10:03 am
No this is also not an issue with WordPress 4.0
We have found that certain server set ups are causing an issue with the autoloader file paths which causes the error above.
We are working on a fix currently, once tested and confirm we will include it within the next update.
|
|
Scott Gillard
|
February 5, 2015 at 12:29 pm
Thanks as always folks. 🙂
I’m not sure what’s up now but the error is no longer visible front or back end.
S.
|
|
Tony
|
February 5, 2015 at 12:33 pm
Disabling WP_Debug will stop your server displaying errors, both front and back, so that’s a good thing.
You don’t really want to leave WP_Debug enabled on a live, its great for troubleshooting as we can then see the errors, but not so great to leave enabled.
|
