|
Dustin White
|
May 29, 2014 at 3:26 pm
Hopefully you guys have an answer, we’ve had several people digging into this for a few hours now and the best we can figure is that its limited to Event Espresso in some way (Authorize.net payments work on the same site with WooCommerce very quickly).
So here’s the issue: When we complete a credit card payment through authorize.net and click to submit the payment, the page stalls. The payment goes through quite quickly, as we get confirmation emails of the payment almost right away, but the page just keeps loading and waiting. Somewhere around 2-3 minutes later usually the page finally comes up and has the correct information on whether or not the transaction was successful. Lowering our server’s max script execution time does not affect this.
We’ve tried many things, we have verified that the API calls aren’t getting blocked by our security plugin nor by the server’s firewall. We have verified that this is a problem exclusive to event registration, our woocommerce store using the same Authorize.net payment method does not have the issue.
We are using an older version of event espresso that we can no longer update due to some customizations that had to be done (at the advice of event espresso support).
Event Espresso Version: 3.1.34.P
Wordpress Version: 3.7.3
We are hesitant to update either of these because this is a live site and we cannot risk having anything break.
I also noticed this similar issue (albeit with a shorter load time) a few days ago. The issue is nearly identical so I’m not convinced this is an isolated problem. https://eventespresso.com/topic/very-slow-complete-purchase-process/page/2/
Any information on what could potentially be a cause here would be greatly appreciated.
Thank you.
|
|
Dustin White
|
May 29, 2014 at 3:37 pm
Forgot to link the site:
http://createvalue.org/event-registration/?ee=83
If you want to do test transactions, let me know and I can enable test mode through authorize.net
|
|
Lorenzo Orlando Caum
|
May 29, 2014 at 5:48 pm
Hello,
Are you seeing anything if you turn on WP debugging?
define('WP_DEBUG', true);
if (WP_DEBUG) {
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', true);
@ini_set('display_errors', 0);
}
Also, who is your webhost?
—
Lorenzo
|
|
Dustin White
|
May 30, 2014 at 8:52 am
Notice: Undefined index: HTTP_MOD_REWRITE in /home/createva/public_html/wp-content/plugins/event-espresso-requirements-check/espresso_requirements_check.php on line 144
This notice pops up all over the place. The other notices don’t seem relevant.
As far as hosting goes, we manage our own servers.
|
|
Sidney Harrell
|
May 30, 2014 at 10:43 am
Do you have the espresso requirements plugin activated? It’s really only supposed to be activated, checked, and then deactivated.
Is anything showing up in the php or apache logs? You should have transaction entries in the uploads/espresso/logs/espresso_log.txt file. You may also want to go into the General Settings and enable “Full Logging”. That will add a lot more data to the espresso_log.txt file.
|
|
Dustin White
|
May 30, 2014 at 11:03 am
I’ve deactivated that plugin now, the apache error log doesn’t contain anything interesting.
PHP Error log has this (these two lines for each transaction):
http://pastebin.com/cd9SH6rd
Espresso’s log file has this (I didn’t know which parts to keep so I put the whole thing in there.. its long I know)
http://pastebin.com/raw.php?i=Jk0TJK8p
Any ideas?
|
|
Sidney Harrell
|
May 30, 2014 at 11:23 am
The line 77 is the session_start() call in EE, but it shouldn’t have already sent headers at that point. It indicates some unexpected output. If you deactivate all of the non-EE plugins and switch to the 2014 theme, are you still getting the same error?
|
|
Dustin White
|
May 30, 2014 at 1:57 pm
Is there any other way to find out where other headers might be originating from? Disabling the theme/plugins isn’t really an option as this isn’t a development site, this site has been live and working fine for several months.
|
|
Dustin White
|
May 30, 2014 at 2:31 pm
Furthermore, according the logs this error has been happening for several months, while the issue with the payment processing has only started very recently.
|
|
Dustin White
|
June 2, 2014 at 11:26 am
Any ideas here?
|
|
Sidney Harrell
|
June 2, 2014 at 3:23 pm
The only payment that occurred after you turned on the full logging was for Oldenburg, Sam. The request comes in at 54:41 and it goes to the template file by 54:42. Do you have any more log entries for payment page loads since then? Search for “Payment for:” and look for entries after 2014-05-30. It would help to be able to see where in the entry the delay is coming from.
|
|
Dustin White
|
June 2, 2014 at 4:13 pm
All payments that have been made after error logging should have been from Sam now. All payments now in the log say the same thing, and that the payment_overview.php file is loaded within a second or two of submitting the payment.
I did another short test by timing when I exactly clicked the submit payment button, and the error log claims that the payment_overview.php file was loaded only 10 seconds later, however my page kept loading for an additional 3.5 minutes.
|
|
Sidney Harrell
|
June 2, 2014 at 6:07 pm
I wonder if the additional time is coming before or after the event espresso log entries. I would try having a second tab open on the event registration page, and use a submission there as a marker in the log. As soon as it’s page loads, switch to the tab with the payment page ready to submit, submit it, and when it finally goes through, switch back to the other tab and resubmit it. That way in the log, you’ll have the payment page entry sandwitched between the two registration form submissions.<br>
The curl interaction between EE and authnet takes place in the function call in the log right before the “Payment for:” entry, so it doesn’t looks like that is where the delay is coming from.
|
|
Dustin White
|
June 2, 2014 at 6:57 pm
Its pretty much garaunteed to be coming after the event espresso log entries.
My test earlier today was exactly as follows:
Submitted Payment Details at exactly 17:05:00
Espresso Logs show that the payment was processed and the confirmation page was successfully oppened at 17:05:10
The page finally loaded at 17:08:30 (give or take a few seconds here)
I did your test as suggested anyway and here are the relevant lines in the espresso log file:
http://pastebin.com/F3Raqndu
|
|
Sidney Harrell
|
June 3, 2014 at 9:40 am
Can you mirror the site onto a development server? You’re going to need to try different things like switching the theme to the default theme, deactivating other plugins, using a minimalist page template on the thank-you page, etc, in order to narrow down the problem. The only other thing I can suggest is to add some espresso logging to a function and adding that function to all the WP hooks in the page load after the shortcode execution to try to see where it is hanging up.
|
|
Dustin White
|
June 3, 2014 at 4:14 pm
Bah, was hoping to avoid having to do that. Either way, after several hours of copying things over I have a working test environment that we can do whatever we want with without compromising the live site.
http://test.createvalue.org/
I can send admin login details if you would like, (I believe you guys have a secure way of handling that).
I tried again without changing the theme and that also was hanging for a very long time
Changing the theme to twenty-thirteen didn’t help either.
The template for the thank-you page is as bare-bones as it gets. Just some confirmation text is all that gets output, not even styled actually. (http://puu.sh/9dRoV/548984aab4.png)
How should I proceed? Sky’s the limit now for what I can test, though I would still like to leave updating event espresso as a last resort.
|
|
Dustin White
|
June 3, 2014 at 4:21 pm
I just tried updating WordPress to 3.9.1 with no results.
|
|
Josh
|
June 3, 2014 at 8:51 pm
We recommend running the current version of Event Espresso, why is updating a last resort?
|
|
Dustin White
|
June 4, 2014 at 7:45 am
Another developer on our team made some changes to some core files a long time ago (well before any of these issues started occuring). I’ll check with him to see how we can update.
|
|
Josh
|
June 4, 2014 at 10:21 am
Since you have this running on a test site, you could try switching out the modified version of Event Espresso core with the current version and run tests on that one.
|
