|
admin@pesgb.org.uk
|
July 5, 2016 at 3:53 am
Hi,
I’ve been having some trouble setting up the Sage Pay payment method on my website, despite following all the required steps described in the Event Espresso 4 documentation.
The Sage Pay account is live, I’ve added the website’s IP to the list of valid IPs within my Sage Pay account, I added the Vendor Name to the plugin’s Sage Pay activation page, and I still receive an error message when testing the payment method, simply saying that payment could not be processed.
Can you please advise me what I can do to resolve this issue? Thank you!
|
|
Tony
|
July 5, 2016 at 2:28 pm
Hi there,
Does it show any kind of Error code when displaying this message?
If you look within the Transaction for the Registrations you are testing (Event Espresso -> Registrations -> {your registration} -> View Transaction) what does it show for the ‘Gateway response’ field, for example this is an PayPal payment that was approved – http://take.ms/fmt4h
Your gateway response should show an error number that should help find the cause of the problem.
Also can you link me to the event so I can run a test registration?
|
|
Seth Shoultes
|
July 6, 2016 at 10:08 am
@Tony this is their registration page:
http://www.petex.info/events/petex-2016/
When I tried to make a payment, I received this error about the IP address:
http://www.screencast.com/t/jp22DhjVd
Sounds to me like they should follow up with SagePay to see if they are receiving the transmission.
|
|
Josh
|
July 6, 2016 at 10:30 am
There are a number of stack exchange answers like this one that may help:
http://stackoverflow.com/a/17674850
As well as:
http://www.sagepay.co.uk/support/error-codes/4020-invalid-information-received-invalid-ip-address
|
|
admin@pesgb.org.uk
|
July 7, 2016 at 5:43 am
Hi guys,
So, I tried adding a different IP address and it seems this is the correct one, because now the attempted transaction appears in my Sage Pay account, so they have received the transmission.
However, the transaction still failed. After clicking on Finalize Payment on the event page, it buffered for a short while and then said that the step could not be processed; please refresh browser. On the Sage Pay account, it shows that the transaction has been abandoned due to inactivity.
Is this a problem with Sage Pay or EE? Thanks.
|
|
admin@pesgb.org.uk
|
July 7, 2016 at 6:05 am
I found an older thread with the same issue, so I disabled my 3D secure and the transaction was approved.
Weird message showing up on the screen afterwards though…
We’re sorry…
This is a system page for displaying transaction information after a purchase.
You are most likely seeing this notice because you have navigated to this page
through some means other than completing a transaction.
Sorry for the disappointment, but you will most likely find nothing of interest here.
What is this?
|
|
admin@pesgb.org.uk
|
July 7, 2016 at 6:09 am
Just to make that clearer, the transaction appears to be approved on my Sage Pay account, I received an email with the registration notification, but, the transaction and the registration details do not appear in EE too…
|
|
Tony
|
July 7, 2016 at 6:09 am
It looks like an error being thrown on the server.
If you look within the servers error logs can you see any errors from EE?
Or if you enable WP_DEBUG we can run a test registration and see if we can catch the error.
|
|
admin@pesgb.org.uk
|
July 7, 2016 at 8:52 am
Hi Tony,
I’m not sure how to enable WP_DEBUG, but I have tested the registration once again and it works fine now.
How can I avoid small bugs like these in the future? Thanks!
|
|
Tony
|
July 7, 2016 at 8:58 am
Without knowing what the error was we can’t say.
This could have been an issue with the server (memory exhausted maybe?), an unexpected response from SagePay or a number of other issues.
How much memory do you have assigned to the site?
You can check within Event Espresso -> Maintenance -> System information.
Search for ‘wp_memory’ and ‘memory_limit’, what values are set for both of those?
|
|
admin@pesgb.org.uk
|
July 8, 2016 at 2:35 am
Hi Tony,
The memory_limit is:
[memory_limit] => Array
(
[global_value] => 128M
[local_value] => 256M
[access] => 7
)
And wp_memory says
[wp_memory] => <mark class=”error”>40M – We recommend setting memory to at least 64MB. See: Increasing memory allocated to PHP “</mark>
)
|
|
Tony
|
July 8, 2016 at 3:52 am
So your site should have at least 128MB available and should not cause problems.
Unfortunately without an error we can’t say what the cause was, if you check within the error loads and find any errors from Event Espresso we can investigate this. Do you have access to the error logs?
|
|
admin@pesgb.org.uk
|
July 8, 2016 at 7:39 am
I checked for error logs via FTP and I only have an empty espresso_log.txt in the logs folder.
I’ll try to enable WP_debug today which will hopefully allow you to check for issues?
|
|
admin@pesgb.org.uk
|
July 8, 2016 at 8:09 am
Hi Tony,
I enabled Wp_debug. Could you have a look please? Thanks
|
|
Tony
|
July 8, 2016 at 10:07 am
Ok, there are notices being thrown on every request (not a major problem but means we can’t test registrations properly) where you have this:
define( 'WP_DEBUG', true ); // Or false
Change it to use this:
define( 'WP_DEBUG', true ); // Or false
if ( WP_DEBUG ) {
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
}
That will stop the errors/notices being thrown by your theme/plugins from being displayed on your site but will log them within a debug.log file on your server.
Then we can run a test registration and see if any errors are being logged.
|
|
admin@pesgb.org.uk
|
July 11, 2016 at 2:54 am
Hi Tony,
Thank you!
I’ve changed the php file with the shortcode you gave me. You should be able to test registration now.
Thanks!
|
|
admin@pesgb.org.uk
|
July 13, 2016 at 5:35 am
Hi Tony,
Have you got any updates for me?
Thanks
|
|
Tony
|
July 14, 2016 at 4:00 am
I’ve ran a couple of test registrations on the site at different times, some worked and other have not.
It looks like there is a fatal error being thrown on some requests but not others, however no errors (related to this issue) are being caught in the debug.log file which likely means the error is being thrown earlier than the debug code is so the only way to find out what is happening is to view the servers error logs.
You should have an error.log error_log or similar file within your root directory that usually contains all of the errors being thrown by your site. If not can you contact your host and ask them where you can view the error log?
|
|
admin@pesgb.org.uk
|
July 19, 2016 at 8:08 am
Hi Tony,
I’ve been in contact with our host and they’ve told me the following:
I have checked the error logs for the domain petex.info from the 15th of July and I have found the following errors:
2016-07-15T09:38:05+01:00 httpd[]: [error] [client] SystemException in API_Linux.cpp:172: setuid() failed: Resource temporarily unavailable, referer: http://www.petex.info/
2016-07-15T09:38:05+01:00 httpd[]: [error] [client] Premature end of script headers: index.php, referer: http://www.petex.info/
2016-07-15T09:38:05+01:00 httpd[]: [error] [client] SystemException in API_Linux.cpp:172: setuid() failed: Resource temporarily unavailable, referer: http://www.petex.info/
2016-07-15T09:38:05+01:00 httpd[]: [error] [client] Premature end of script headers: index.php, referer: http://www.petex.info/
2016-07-15T13:16:53+01:00 httpd[]: [error] [client] SystemException in API_Linux.cpp:172: setuid() failed: Resource temporarily unavailable, referer: http://www.petex.info/
2016-07-15T13:16:53+01:00 httpd[]: [error] [client] Premature end of script headers: index.php, referer: http://www.petex.info/
2016-07-15T13:16:53+01:00 httpd[]: [error] [client] SystemException in API_Linux.cpp:172: setuid() failed: Resource temporarily unavailable, referer: http://www.petex.info/
2016-07-15T13:16:53+01:00 httpd[]: [error] [client] Premature end of script headers: index.php, referer: http://www.petex.info/
2016-07-15T14:46:52+01:00 httpd[]: [error] [client] SystemException in API_Linux.cpp:172: setuid() failed: Resource temporarily unavailable, referer: http://www.petex.info/
2016-07-15T14:46:52+01:00 httpd[]: [error] [client] Premature end of script headers: index.php, referer: http://www.petex.info/
2016-07-15T14:46:52+01:00 httpd[]: [error] [client] SystemException in API_Linux.cpp:172: setuid() failed: Resource temporarily unavailable, referer: http://www.petex.info/
2016-07-15T14:46:52+01:00 httpd[]: [error] [client] Premature end of script headers: index.php, referer: http://www.petex.info/
2016-07-15T17:09:46+01:00 httpd[]: [error] [client] SystemException in API_Linux.cpp:172: setuid() failed: Resource temporarily unavailable, referer: http://www.petex.info/
2016-07-15T17:09:46+01:00 httpd[]: [error] [client] Premature end of script headers: index.php, referer: http://www.petex.info/
2016-07-15T19:41:50+01:00 httpd[]: [error] [client] SystemException in API_Linux.cpp:172: setuid() failed: Resource temporarily unavailable, referer: http://www.petex.info/
2016-07-15T19:41:50+01:00 httpd[]: [error] [client] Premature end of script headers: index.php, referer: http://www.petex.info/
2016-07-15T19:41:50+01:00 httpd[]: [error] [client] SystemException in API_Linux.cpp:172: setuid() failed: Resource temporarily unavailable, referer: http://www.petex.info/
2016-07-15T19:41:50+01:00 httpd[]: [error] [client] Premature end of script headers: index.php, referer: http://www.petex.info/
The errors above are indicating that your website is hitting certain limits set on shared-hosting packages.
In order to reduce its number of appearances, you can try to optimize the website better, in order to reduce its loading time.
Using the speed test made with https://gtmetrix.com/reports/petex.info/WgOX0gBb I can see that gzip compression and browser caching are not added to the website, therefore please add the following lines of code in your .htaccess file:
# compress text, HTML, JavaScript, CSS, and XML AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
# remove browser bugs
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html Header append Vary User-Agent
## EXPIRES CACHING ##
ExpiresActive On ExpiresByType image/jpg “access plus 1 year” ExpiresByType image/jpeg “access plus 1 year” ExpiresByType image/gif “access plus 1 year” ExpiresByType image/png “access plus 1 year”
ExpiresByType text/css “access plus 1 month”
ExpiresByType application/pdf “access plus 1 month”
ExpiresByType text/x-javascript “access plus 1 month”
ExpiresByType application/x-shockwave-flash “access plus 1 month”
ExpiresByType image/x-icon “access plus 1 year”
ExpiresDefault “access plus 2 days”
## EXPIRES CACHING ##
I’ll do this, but is there anything here that would explain the EE bugs? Thanks
|
|
Tony
|
July 19, 2016 at 8:29 am
I’ll do this, but is there anything here that would explain the EE bugs?
I’m not sure what makes you think these are EE bugs?
The problem is from the limitations set by your hosting provider:
The errors above are indicating that your website is hitting certain limits set on shared-hosting packages.
The code your hosting provider has given you is basically caching, its to try and reduce the load your site puts on the server. WordPress and e-Commerce (which is basically the type of plugin EE is although not at the same time) require more resources, it seems the shared hosting package you have with your current host is not suitable for the type of site you are running.
You will either need to work with the host to provide you with more resources, maybe change your hosting package to something they can provide more resources with or move to a host without these limitations.
We have multiple users running Event Espresso on shared hosting without any problems (likely with less restrictive limitations) although the more resources available the better your site will run.
|
|
admin@pesgb.org.uk
|
July 19, 2016 at 9:31 am
Hi Tony,
Thank you! I’m sorry if you misunderstood me. I wasn’t implying that those were EE bugs, I was wondering if those could have caused the EE bugs, which actually does sound plausible if the package is limited.
|
|
Tony
|
July 20, 2016 at 2:53 am
Ah ok, I understand now.
Yes if you are hitting limitations on the server you will run into some odd an unexpected behavior as various bits of code can not run properly when the limit is hit.
Did you discuss the above with your hosting provider?
|
|
admin@pesgb.org.uk
|
July 20, 2016 at 9:26 am
Not yet…
I added those lines and will test registration again in the following days to see how it works. If I run into errors again, I’ll see what more to do about it.
|
|
Tony
|
July 20, 2016 at 1:36 pm
Ok great.
Please do keep us updated 🙂
|
|
admin@pesgb.org.uk
|
July 27, 2016 at 3:22 am
Hi Tony,
Well so far so good. We officially opened registration and haven’t noticed any more errors occurring so I will update this topic as resolved. Thanks for your help
|
