|
texashauntersgroup
|
January 28, 2019 at 11:02 pm
I am running into an issue while setting up a new event that goes live very soon.
I am getting this error below while working with an event.
The maximum 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.
There are 1032 inputs and the maximum amount currently allowed by your server is 1000.
At times the options under “Event Tickets & Datetimes” for the events do not even paint. This is making it impossible to work on the event.
My site https://www.texashauntersconvention.com is hosted on Dreampress and is running PHP 7.1.22.
I updated their file “phprc” to include “max_input_vars = 3000” per the instructions on thier site. I then refreshed the services.
I created a phpinfo page here which shows both the Local Value and Master Value are now “3000”: **REMOVED**
I loaded the two plugins below:
https://wordpress.org/plugins/debug-bar/
https://wordpress.org/plugins/debug-bar-console/
When I ran the “echo ini_get(‘max_input_vars’);” command in the console it responded with “3000”.
I deactivated my “WP Super Cache” plugin.
From what I can tell everything is set to “3000” but it is still reporting it is set to “1000”.
Please help! Thank you.
-
This topic was modified 5 years, 3 months ago by
 Tony. Reason: Remove phpinfo
|
|
Tony
|
January 29, 2019 at 2:29 am
Hi there,
At times the options under “Event Tickets & Datetimes” for the events do not even paint. This is making it impossible to work on the event.
I’m not sure I follow, can you add more details?
The limit is not set within EE, it is just read from the server and the notice displayed, so if settings aren’t saving theres a bigger problem but we can check on that after we’ve fixed the notice.
So that we don’t keep hitting the server to read the value, we cache it within EE’s config and with the above it sounds like the server was updated but the config hasn’t refreshed, you can force this to happen by navigating to:
Event Espresso -> General Settings -> You Organization.
You need to make a change on that page and save.
What I recommend doing is adding something to your Organization name (just a single character on the end will do), save, remove it again and save.
That’ll rebuild the config, pull the max_input_vars value from the server and cache it again, so after you’ve done that, does the notice no longer appear on the event editor?
|
|
Tony
|
January 29, 2019 at 2:31 am
Also, I recommend you remove the phpinfo file from your site or at least requiring basic auth to view it as you don’t want the information within that file to be publicly available.
(I’ve removed the link to if from your post above)
|
|
texashauntersgroup
|
January 29, 2019 at 8:26 am
Greetings Tony,
I removed the phpinfo file. My goal was to only have it there long enough for you to see the variable was set. I do appreciate your security concern. 🙂
In reference to the below:
At times the options under “Event Tickets & Datetimes” for the events do not even paint. This is making it impossible to work on the event.
I meant that you will see that header line in the UI but then no event datetime or tickets or any other sections render in the UI below that text. This may not be related to the main issue I just noticed it when I was running into the popup message. I had to hard refresh the page several times to get all of the EE elements to show in the console.
I will rebuild the config as you suggested and give it a try. I will report back my findings later today.
Thank you!
|
|
texashauntersgroup
|
January 29, 2019 at 11:12 pm
Greetings Tony,
I think the config refresh you recommended resolved the issue and it is seeing the updated values as I am no longer seeing the error displayed in the UI.
After that, I had to resolve a memory issue also which is now taken care of:
PHP Fatal error: Allowed memory size of 94371840 bytes exhausted (tried to allocate 20480 bytes)
The other issue I mentioned around the screen not painting looks like it may be a hosting issue with DreamHost since I am on a shared server. They have a bot that kills memory or processor intensive tasks since I am on a shared server. I think I may be running into this. I opened a case with them to confirm as I am seeing lines such as the below:
[Tue Jan 29 22:01:45 2019] [error] [client X.X.X.X] Premature end of script headers: php71.cgi, referer: https://www.texashauntersconvention.com/wp-admin/admin.php?page=espresso_events
It happens intermittently so I am hoping it is this bot that is causing it.
Let me know if you have any questions. Thank you!
|
|
Tony
|
January 30, 2019 at 3:35 am
How many datetimes and tickets do you have in these events?
From the above, it does look like the script is being killed and if thats the case, you’ll likely need to move to either a different package with DreamHost (away from shared hosting) or another hosting provider as that it only going to happen more as you add more datetimes/tickets to your events.
|
|
texashauntersgroup
|
January 30, 2019 at 9:03 pm
So far it is 9 Event Dateimes and 15 Available Tickets…and growing. Part of this is because of the single layer shopping card limitation we hope will eventually be overcome in future releases.
I am working with DreamHost on a different hosting package. Hopefully, I do not need to switch providers as I picked them based on your companies recommendation on hosting providers needed to handle this software.
They are saying my Divi theme is a big culprit for the resource usage issues.
Thank you for all your help.
|
|
Tony
|
January 31, 2019 at 2:40 am
So far it is 9 Event Dateimes and 15 Available Tickets…and growing. Part of this is because of the single layer shopping card limitation we hope will eventually be overcome in future releases.
Yeah, that’s not a huge amount, but each one does start to stack up the queries a little more.
I am working with DreamHost on a different hosting package. Hopefully, I do not need to switch providers as I picked them based on your companies recommendation on hosting providers needed to handle this software.
Most hosts will have a package that will suit, it all depends on the event setup, traffic, plugins, themes etc of each site so whilst we make a recommendation on hosts that we have had good experiences with, the package used with that host and the resources required for each individual site will b different per site/user.
They are saying my Divi theme is a big culprit for the resource usage issues.
Any page builder try theme will also likely have the same problem as they all use more resources, it’s the tradeoff for the types of features those themes include.
Please do let me know how you get on with this.
|
|
texashauntersgroup
|
January 31, 2019 at 8:24 pm
I have transferred over to a VPS server with DreamHost. It has a dedicated 1 GB of memory I can use. I set the needed files to allow WordPress and PHP to take 256MB to start with. I will keep an eye on the logs and work on building out the rest of the event. Hopefully, I am over the issues now.
|
|
texashauntersgroup
|
February 1, 2019 at 6:37 pm
Just to update on this… After moving to the VPS server from DreamHost as opposed to their shared solution the issue of resource constraint has gone away.
One thing to note from the move. The cron jobs did not move properly over. Luckily I found another forum post where someone had the same issue and mentioned disabling EE and enabling it again would fix the issue and it did.
I would suggest that perhaps on your “Critical Pages” tab that you list a detection to show the cron jobs health and perhaps a remedy option.
I am all good. Thank you! You can close this thread out.
|
|
Tony
|
February 4, 2019 at 5:01 am
One thing to note from the move. The cron jobs did not move properly over. Luckily I found another forum post where someone had the same issue and mentioned disabling EE and enabling it again would fix the issue and it did.
The cron jobs are stored with all of your WP Crons as an option in wp_options, if those didn’t move over it could show an issue with the migration itself.
Have you confirmed the default crons all show up correctly?
I would suggest that perhaps on your “Critical Pages” tab that you list a detection to show the cron jobs health and perhaps a remedy option.
Its unlikely something we could add to the Critical pages tab as the crons aren’t anything to do with those pages, but we may be able to add a check in the system information tab (Event Espresso -> Maintenance -> System information).
However, even then the remedy would very likely still remain the same and have the admin de/re-activate EE. The reason being is EE runs through multiple checks on activation, if Crons are broken it’s a good idea to run through those checks again.
|
|
texashauntersgroup
|
February 4, 2019 at 6:51 pm
Greetings Tony,
I think all the jobs are back and working. Emails are flowing through the cron which was the main thing that was not working.
Status pages are always nice to know if things are working especially on a migration even if the fix is as you said disabling and then enabling again.
Thanks for all your help!
|
|
Tony
|
February 5, 2019 at 4:28 am
You’re most welcome, I’m glad your back up and running.
|
