|
Rachel roberts
|
September 18, 2015 at 6:59 am
This is a sample page:
http://paintlv.com/event-registration/?ee=1919
When anybody submits a Registration (click submit button) it causes a 500 server error.
In error_logs it shows:
Premature end of script headers: index.php, referer: http://paintlv.com/event-registration/?ee=1942
in SSH, “top”, I’m seeing the mysql max out the CPU at 100%
I’m using the latest version of EE3, and all addons are up to date.
I’m on a dedicated server at Codero (pretty powerful), so there has to be some bug or the tables are just too large.
Please help! Users cannot register.
|
|
Josh
|
September 18, 2015 at 7:59 am
Hi Rachel,
Do you know if anything on the server has changed recently? The changes could be new plugins, updated plugins, changes to the server configuration?
One thing that you can do that may help is try installing a fresh copy of Event Espresso 3.1.37.5.p. This would help in cases where one or more of the files in the plugin was edited or removed.
|
|
Rachel roberts
|
September 18, 2015 at 2:04 pm
Hi Josh,
I did a deinstall, reinstall at the host (Codero) to fix a directory issue (directory not the same as domain name).
This is when the problems occurred.
I just tried a fresh reinstall and it did not fix it.
I need this looked at quickly, I’m purchasing a Support Token now.
Thanks
|
|
Josh
|
September 18, 2015 at 2:16 pm
Can you explain a bit more about the changes to the directories that led to the problem starting?
|
|
Rachel roberts
|
September 18, 2015 at 2:21 pm
Token purchased, and priority ticket submitted.
New symptom:
Users cannot be submitted from within dashboard either. When a worker clicks “Submit” inside the event form–> Add Attendee
The same issue occurs.
I understand you only work until Friday, but Please please pretty please look at this soon. We have signups 24/7 and we have no way of adding anybody in (frontend or backend)
|
|
Josh
|
September 18, 2015 at 2:25 pm
Can you answer the question I asked in the above reply?
Can you explain a bit more about the changes to the directories that led to the problem starting?
The more information you can share about the nature of the changes that were made before the errors started happening, the better.
|
|
Rachel roberts
|
September 18, 2015 at 2:25 pm
Okay so at Codero, the original folder name was named after our old original domain
/oldsite.com
However we had to switch our domain to paintlv.com. With the latest WP upgrade, this broke the tinymce editor b/c according to Codero, you can’t have a Plesk install with one domain and the directory be another name; it triggers a block of any files with variables at the end, hence why tinymce’s js was getting blocked.
We were advised to deinstall the entire subscription in Plesk, and then reinstall under the proper (new) domain paintlv.com
When we did this, the js issue was corrected, however, the mysql-service started maxing out anytime we tried to do any registration additions
|
|
Rachel roberts
|
September 18, 2015 at 2:27 pm
There was no change to the server, it’s still the same server. Just a deinstall & reinstall.
The only reason we did it was to set the Directory name the same as the Domain in Plesk.
To my knowledge nothing else changed.
|
|
Rachel roberts
|
September 18, 2015 at 2:32 pm
To ease the burden:
I deleted all Events up to January of this year, and although it sped up the load time, it did not correct the issue.
I also made optimizations to etc/my.conf to help the mysql service run better; this, again, enhanced mysql, but the maxing out still occured.
A Codero rep ran a view process thingamajig in SSH and he noted that an SQL command coming from EE was causing the mysql-CPU max out.
You can replicate this by monitoring the sql process in SSH, and then initiating a registration.
You have my permission to restart sql services in SSH to clear the SQL-hangup.
This was the only way I was able to stop the hangup in ‘top’
|
|
Josh
|
September 18, 2015 at 2:37 pm
The only reason we did it was to set the Directory name the same as the Domain in Plesk.
To my knowledge nothing else changed.
Can you check with the host and ask them if the directory permissions were updated when the name was changed?
|
|
Rachel roberts
|
September 18, 2015 at 2:46 pm
Wordpress was installed using Plesk’s -Wordpress install. So the permission would have been set automatically.
All I did was FTP copy over wp-config and the wp-content folder. I can check on that now with them
JUST AN FYI:
The only anomaly was that the original SQL export file from PHPMyAdmin would not import (broke the Plesk DB) b/c it was too large; so I started a new DB, and imported in multiple parts and got it working.
So right now, the wp-config is referencing the DB I manually setup (not the default Plesk-made one). But I’ve talked to Codero and they said this is legit. All else works on the website.
|
|
Josh
|
September 18, 2015 at 2:54 pm
This issue should be addressed:
/var/lib/php/session/ does not exist - contact your host to resolve the problem.
|
|
Rachel roberts
|
September 18, 2015 at 2:59 pm
I talked to Codero and they said, that theoretically b/c I used root to upload the wp-content & wp-config files (copying over existign Plesk wp install) it could cause file permission issues. This would be because the Plesk install user owns the files, but when I used root to FTP in it would set those uploaded files to be owned by root.
However the rep stated that if the the SQL command identified (while monitoring SSH) was causing the error, the problem would not reside with file permissions, but rather with the particular SQL command being called by EE.
But you’re the expert on this. I could go in and delete the wp-content & wp-config files, and then FTP in with the Plesk-user and reupload them.
What are your thoughts on this?
|
|
Rachel roberts
|
September 18, 2015 at 2:59 pm
just saw your last response, I will contact them now
|
|
Rachel roberts
|
September 18, 2015 at 3:02 pm
Where did you see this error, which log?
Codero is asking.
|
|
Rachel roberts
|
September 18, 2015 at 3:04 pm
Reponse from Codero:
var/lib/php/session (they ssh’d in)
They are seeing sessions for active users today (16 minutes ago), so they said sessions are working.
I’ll keep you posted (on phone with them right now)
|
|
Rachel roberts
|
September 18, 2015 at 3:11 pm
Codero changed the permissions for all files over to the Plesk user, so that has been sorted.
|
|
Rachel roberts
|
September 18, 2015 at 3:41 pm
Codero ran a mysql upgrade, as they noted several issues in the /var/log/mysqld.log file.
However, it did not correct the issue (just tested)
|
|
Josh
|
September 18, 2015 at 3:54 pm
Just so I can better understand what happened when, did the breakage start before or after this happened?
JUST AN FYI:
The only anomaly was that the original SQL export file from PHPMyAdmin would not import (broke the Plesk DB) b/c it was too large; so I started a new DB, and imported in multiple parts and got it working.
|
|
Rachel roberts
|
September 18, 2015 at 4:19 pm
The import occurred during initial setup (re-setup I should say).
The site was tested after the files were FTP’d in, and the DB imported.
So the issue occurred after all files/tables were ported in.
|
|
Rachel roberts
|
September 18, 2015 at 4:22 pm
To isolate, I can setup a 3rd DB, barebones, and then reinstall from scratch and test.
I will run it on a WP default theme to be safe.
I will need to momentarily change wp-config to test it out, so I’ll need your go ahead to try it.
|
|
Rachel roberts
|
September 18, 2015 at 4:23 pm
To be more clear, I will reactivate EE on the Test Server, just to see if the issue can be replicated on a barebones mysql instance.
|
|
Rachel roberts
|
September 18, 2015 at 4:55 pm
Hey Josh, I’m waiting on your go-ahead to do the barebones DB setup.
I don’t want to mess with what you are doing right now.
|
|
Josh
|
September 18, 2015 at 5:08 pm
I think you’ll find that things will work well on your barebones DB setup.
I’ve narrowed the issue down to an issue with the wp_events_attendee table on your site. I took a snapshot of all the tables that have _events_ in their name, then I copied them to a local server where WP was already installed. Then I tried a registration and it threw this error:
An error occurred. No Attendee was received.
I had seen this same error earlier today when I first checked your site this morning.
Then I looked in the DB, and I could see that all of the rows that were created today in the attendee table have an ID 0, including the test I did on the local server.
So then I deactivated Event Espresso, renamed the wp_events_attendee table, then reactivated Event Espresso. On re-activation, it made a new wp_events_attendee table. Then I tested a registration and boom, it worked.
So I suspect that something in the wp_events_attendee table is slightly borked from being exported/imported or it’s the sheer size of it and mysql is choking when it tries to insert more. Although if you take a look at the current table, it is inserting, just not incrementing the ID anymore.
As a quick, get things working fix, you could do what I did and deactivate, rename the wp_events_attendee table, then reactivate EE. That should restore registration functionality.
Then you could copy over the latest attendee data from the original into the new wp_events_attendee table so they’ll have all the attendee data for all the upcoming and active events.
Does that make sense?
|
|
Rachel roberts
|
September 18, 2015 at 5:22 pm
Hey Josh, I tried as you said, but upon reactivation no wp_event_attendee table is created.
I’m sure this is something that is supposed to happen on reactivation but it is not.
|
|
Rachel roberts
|
September 18, 2015 at 5:25 pm
I will attempt a manual copy and then drop most of the earlier attendees.
I know this is not ideal, but I can’t get it to create the table on reactivation.
|
|
Josh
|
September 18, 2015 at 5:29 pm
You can force it to check for tables on reactivation by doing a version number bump. First, you deactivate Event Espresso.
Then, the version bump is done by editing lines 9 and 34 of espresso.php. You bump the version by changing it from 3.1.37.5.P to 3.1.37.5.1.P. Then you reactivate.
|
|
Rachel roberts
|
September 18, 2015 at 5:30 pm
Josh new error after copyign Table Structure only (blank wp_events_attendee table)
I can add from the inside now
HOWEvER, from the outside like this:
http://paintlv.com/event-registration/?ee=1931
getting this after submit:
An error occurred. No Attendee was received.
Please advise.
|
|
Rachel roberts
|
September 18, 2015 at 5:33 pm
I suspect taht copying structure-only brought over the auto-increment error.
Looking in new table, and yep, it’s no incrementing the id.
Is there any way to force EE to create a new table from scratch? Reactivation is not working.
|
|
Josh
|
September 18, 2015 at 5:51 pm
You can force EE do create a new table from scratch by doing a version bump. I outlined how to a version bump in my last reply.
|
|
Josh
|
September 18, 2015 at 5:53 pm
Along with that, before you reactivate, you’ll need to make sure there isn’t already a table that’s named wp_events_attendee.
|
|
Rachel roberts
|
September 18, 2015 at 6:05 pm
so that is working now, now to test an import of the latest entries (I’m thinking the last 1000).
|
|
Rachel roberts
|
September 18, 2015 at 6:28 pm
I don’t want to get my hopes up too high, but think we might have a winner.
Please leave this ticket open, so I can test over the weekend.
Josh, thank you very much for your help. 🙂
|
