|
hoffman
|
September 5, 2019 at 8:48 am
Hi Josh (and a caution to others in the thread above)
Out of the blue, in the past half an hour, every page on our website (even no-event pages) started displaying an EE error message in a red box saying: ‘There were errors creating the Event Espresso database tables and Event Espresso has been deactivated. To view the errors, please enable WP_DEBUG in your wp-config.php file’
All of the event links disappeared from sidebars of the site. Event pages were not accessible. This has happened before, and I’ve fixed it by deactivating and reactivating the plugin. So I tried doing that. And now the entire site has gone down and is returning a timeout error.
Please, please help!
|
|
Josh
|
September 5, 2019 at 8:55 am
Hi,
I’ve split your reply from the Sage Pay topic into its own topic, because the errors on your site have nothing to do with the Sage Pay gateway.
First, you’ll need to deactivate Event Espresso by FTPing into the files of your site, then renaming the Event Espresso folder within wp-content/plugins. This will automatically deactivate the plugin. Then it would be wise to take a backup of the database. Then, restore the database to a recent backup. If you do not have a recent database backup to restore to, you can contact your web host as they may have one.
|
|
hoffman
|
September 5, 2019 at 9:14 am
Thanks for the speedy reply Josh. I have renamed the Event Espresso folder and it has made no difference. The site is still down.
|
|
Josh
|
September 5, 2019 at 9:20 am
That’s an indication that the site being down is caused by something other than Event Espresso. You could contact your web host as there may be something broken at the server end, at a lower level from WordPress and plugins. For example if the database server has crashed it will need to be restarted.
|
|
hoffman
|
September 5, 2019 at 9:24 am
That makes sense, Josh, thanks. Have contacted our host and we can reinstate the last back up. Please can we keep this case open in the meantime?
|
|
hoffman
|
September 5, 2019 at 10:02 am
Update: Just received this. Does it help shed any light..?
—
Howdy!
Since WordPress 5.2 there is a built-in feature that detects when a plugin or theme causes a fatal error on your site, and notifies you with this automated email.
In this case, WordPress caught an error with one of your plugins, Event Espresso.
First, visit your website (http://www.hoffmaninstitute.co.uk/) and check for any visible issues. Next, visit the page where the error was caught (http://www.hoffmaninstitute.co.uk/wp-admin/admin.php?page=espresso_events) and check for any visible issues.
Please contact your host for assistance with investigating this issue further.
If your site appears broken and you can’t access your dashboard normally, WordPress now has a special “recovery mode”. This lets you safely login to your dashboard and investigate further.
** removed recovery link **
To keep your site safe, this link will expire in 1 day. Don’t worry about that, though: a new link will be emailed to you if the error occurs again after it expires.
Error Details
=============
An error of type E_COMPILE_ERROR was caused in line 89 of the file /var/www/vhosts/hoffmaninstitute.co.uk/httpdocs/wp-content/plugins/event-espresso-core-reg/core/helpers/EEH_Autoloader.helper.php. Error message: require_once(): Failed opening required ‘/var/www/vhosts/hoffmaninstitute.co.uk/httpdocs/wp-content/plugins/event-espresso-core-reg/core/db_classes/EE_Event.class.php’ (include_path=’.:/opt/plesk/php/7.1/share/pear’)
-
This reply was modified 5 years, 2 months ago by
 Josh. Reason: removed recovery link
|
|
hoffman
|
September 5, 2019 at 10:11 am
Enabling recovery mode with EE turned off has now got the site back up and running…
|
|
Josh
|
September 5, 2019 at 10:14 am
Hi,
I’ve removed the recovery link as that’s a link that should never be posted publicly.
The error message is basically saying: “There’s at least one missing file from the Event Espresso plugin”. So you’ll need to reinstall Event Espresso from a fresh copy.
You’ll FTP in and delete the event-espresso-core-reg folder from the wp-content/plugins/ directory.
Then, you’ll be able to log back into the WordPress dashboard and follow these steps to re-install:
1) Download the EE4 core plugin from your account page
2) Save the zip file to your computer
3) Upload the new plugin zip file to your site via Dashboard -> Plugins -> Add New.
4) Activate the plugin.
|
|
hoffman
|
September 5, 2019 at 10:33 am
Hi Josh, thanks for removing the link. Appreciated.
We have a LOT of events live on our site at the moment (like 100 or so), so am nervous of a fresh install, and can see from the FTP logs that nothing has changed in the core folder today. Renaming the EE core folder back to its original via FTP and activating in the WP dashboard has reinstated the events. Everything is working fine at this point.
What I now need to do is reinstall the SagePay plugin, because there are no active payment methods. Humour me(!), but I would like to use the version that we’ve been using so far and not the update released today… Is that possible?
|
|
Josh
|
September 5, 2019 at 11:07 am
Hi,
If you choose not to reinstall, but continue to get the “An error of type E_COMPILE_ERROR was caused in line 89 of the file /var/www/vhosts/hoffmaninstitute.co.uk/httpdocs/wp-content/plugins/event-espresso-core-reg/core/helpers/EEH_Autoloader.helper.php”, you’ll need to contact your host.
With regards to the Sage Pay Plugin, you can go to your site’s WordPress > Plugins page, and reactivate the Event Espresso Sage Pay add-on that you’ve already installed.
|
|
hoffman
|
September 9, 2019 at 3:36 am
Hi Josh
Still having issues with the 3D secure integration, sorry.
I’ve upgraded the EE/Sagepay plugin to the latest version and everything is stable. Am able to take payments using the Sage Pay form integration gateway as I always could.
When I enable the new integration and 3D secure options in my Sagepay account, it will let me take a purchase as far as authentication, actually does perform the authentication and then I get:
Error processing transaction
Server error 5006 Unable to redirect to Vendor’s web site. The Vendor failed to provide a redirection URL.
HTTP error 500 The request was unsuccessful due to an unexpected condition encountered by the server.
Screenshot: https://hoffmaninstitute.co.uk/images/PastedGraphic-1.png
Help, please?
Debbie
|
|
hoffman
|
September 9, 2019 at 4:08 am
Sage Pay have sent me this, if helpful:
The following is a list of steps that can be used to troubleshoot a 5006 error:
The vendor must acknowledge receipt of the transaction response with a Status of either OK, INVALID or ERROR,
The vendor can acknowledge receipt of the transaction response with a Status of either OK, INVALID or ERROR.
Clear the response buffer to remove any header code, comments or HTML.
Before writing the three fields above to the Response object of the POST, clear the response buffer to remove any header code, comments or HTML. The Sage Pay Server is expecting “Status=” to be the first characters in the response.
The NotificationURL should ONLY respond with a Status field, a RedirectURL field and optionally a StatusDetail field.
The NotificationURL should ONLY respond with a Status field, a RedirectURL field and optionally a StatusDetail field. No other HTML, headers, comments or text should be included either before or after these fields.
The RedirectURL must be valid.
Regardless of status, the RedirectURL must be sent that contains a valid, Fully Qualified URL (i.e. an address starting http:// or https://).
Encoding in the response must be as Name=Value fields separated by carriage-return-linefeeds (CRLF).
Encoding in response must be as Name=Value fields separated by carriage-return-linefeeds (CRLF).
The notification page on the vendor’s server can handle correctly all the message sent by Sage Pay (OK, ABORT, NOTAUTHED, REJECTED, PENDING and ERROR).
The notification page on the vendor’s server can handle correctly all the message sent by Sage Pay (OK, ABORT, NOTAUTHED, REJECTED, PENDING and ERROR).
A status of OK should be sent in all circumstances where no errors occur in validating the Notification POST.
A status of OK should be sent in all circumstances where no errors occur in validating the Notification POST, even if a status of ABORT or NOTAUTHED is received, a reply with an OK and a RedirectURL is expected.
Are the Sage Pay IP addresses being blocked a firewall?
Please ensure that all of the following IP addresses are allowed within the Server or Firewall:
For outbound traffic:
195.170.169.9 – live.sagepay.com
195.170.169.8 – test.sagepay.com
The IPs from which we call back are:
195.170.169.14
195.170.169.18
195.170.169.15
The Subnet mask used by Sage Pay is 255.255.255.000
Please ensure that firewalls allow outbound Port 443 (HTTPS only!) and inbound Ports 443 (and optionally 80 HTTP) access in order to communicate with our servers (on Simulator/Test/Live).
There is however always scope for this to change depending on how we a utilising our data centres servers. Sage Pay own the entire 195.170.169.0/255 range (256 IP’s). Allowing this range then this automatically accommodates any future changes.
Is the NotificationURL correct?
The notificationURL should be the page used by their server to send and receive status notification POSTs.
|
|
Tony
|
September 9, 2019 at 4:21 am
Hi Debbie,
Do you mind if I take a look over the logs on your site?
The SagePay add-on already handles the RedirectURL value for the above so I’d like to see if anything strange shows up in the logs.
If so you can send temp login details using this form:
https://eventespresso.com/send-login-details/
The second reply you posted has the next troubleshooting steps we would recommend but first I’d like to see if anything else is amiss.
|
|
hoffman
|
September 9, 2019 at 4:28 am
Thanks Tony. Have done.
|
|
Tony
|
September 9, 2019 at 5:42 am
Thank you, I’ve had a look over your logs and need to explain a little how the payment method works, otherwise, you’ll have no idea what I’m referring to (assuming you don’t know any this already 🙂 )
So, when you open up the Sagepay payment method, add the details requested and click through to be directed to Sapepay we send over a ‘NotificationURL’ to them as required by Sagepay.
That shows up correctly in your logs, you can view that in Event Espresso -> Payment methods -> Logs. Take a look at log entry 10558 (click on the ID on the left to open it), notice the ‘NotificationURL’ value is set there.
What happens is Sagepay use that value when they process your card and they send a POST request to it with the ID of your payment. Which basically means SagePay send details to your site, EE (well actually the SagePay payment method) does some processing and sends a ‘Status’ and ‘RedirectURL’ value back to SagePay. We’ll call this step the ‘Payment confirmation request’, it’s technically not, but it’s a little easier to use than ‘the request Sagepay sends back to your site to redirect the user from the response’.
SagePay then uses the RedirectURL value from payment confirmation request to direct the user back to your site after payment.
All make sense so far?
The error you are getting means SagePay don’t have a ‘RedirectURL’ value to use.
It’s not that are getting an invalid response from EE, or something is hooking in an adding something to the response before it’s sent as looking through the logs I can see the payment confirmation request isn’t happening at all, or at least it isn’t hitting your site.
So the first thing I would do is open up a ticket with your host and have them confirm that something on the server is not blocking the request, the SagePay docs above give you the IP’s your host should whitelist should they need to:
Are the Sage Pay IP addresses being blocked a firewall?
Please ensure that all of the following IP addresses are allowed within the Server or Firewall:
For outbound traffic:
195.170.169.9 – live.sagepay.com
195.170.169.8 – test.sagepay.com
The IPs from which we call back are:
195.170.169.14
195.170.169.18
195.170.169.15
The Subnet mask used by Sage Pay is 255.255.255.000
Please ensure that firewalls allow outbound Port 443 (HTTPS only!) and inbound Ports 443 (and optionally 80 HTTP) access in order to communicate with our servers (on Simulator/Test/Live).
There is however always scope for this to change depending on how we a utilising our data centres servers. Sage Pay own the entire 195.170.169.0/255 range (256 IP’s). Allowing this range then this automatically accommodates any future changes.
|
|
Tony
|
September 9, 2019 at 5:58 am
Actually I think I can see the problem on your site.
Your site is set up to use HTTP, then you redirect everything to use HTTPS. Unfortunately, you can’t do that with POST requests.
In Dashboard -> Settings -> General
Change both WordPress Address (URL) and Site Address (URL) to use https:// rather than http:// and save.
Now test another payment, does it work then?
|
|
hoffman
|
September 9, 2019 at 6:14 am
Tony, you’re a genius. How did we not spot that at this end?!
Thank you so much. All now appears to be working fine. Huge relief all round 🙂
|
|
Tony
|
September 9, 2019 at 6:42 am
Great, I’m glad it’s working for you.
I had a quick check over the new log entries just to confirm everything looked correct and it does so I’ve now deleted your credentials.
Don’t forget to remove that temp user account from the site as we’ll no longer use it 🙂
|
