|
Jeff Long
|
January 4, 2017 at 5:12 pm
I’m getting this error
PHP Fatal error: Call to a member function enqueue_js() on a non-object in /nas/content/live/truefocusmedia/wp-content/plugins/event-espresso-core-reg/modules/single_page_checkout/EED_Single_Page_Checkout.module.php on line 1406, referer: https://domain.org/registration-checkout/?uts=1483567893#checkout
And Authorize returns: (13) The merchant login ID or password is invalid or the account is inactive.
I can’t figure out what’s going wrong?
|
|
Tony
|
January 4, 2017 at 5:25 pm
Hi Jeff,
For this error: PHP Fatal error: Call to a member function enqueue_js()
Visit the /registration-cancelled/ page on your site to clear your session, does it continue to throw the error after that?
For this: And Authorize returns: (13) The merchant login ID or password is invalid or the account is inactive.
Are you using Auth.net SIM or AIM?
Can you double check your credentials and confirm you have the correct details entered into the payment method you are using. The error is returned by auth.net and usually just means the credentials you have in the payment method are incorrect.
|
|
Jeff Long
|
January 5, 2017 at 6:38 am
Thanks. We’re working on doublechecking our API values.
Also, we do not appear to have a Return Relay URL set in Authorize.net. Should we have one? What would it be, if so?
|
|
Josh
|
January 5, 2017 at 7:00 am
You can leave the Return Relay URL field blank because EE4 will set that automatically. More info here:
https://eventespresso.com/wiki/authorize-net-sim-payment-gateway/
|
|
Jeff Long
|
January 5, 2017 at 7:32 am
We’re still getting
Authorize returns: (13) The merchant login ID or password is invalid or the account is inactive.
After resting the API key.
We did two things recently. We updated the website, AND we implemented SSL (HTTPS) on WPEngine.
Even though when we submit the Authorize credit card form we receive the error (and do not reach confirmation) the payment goes through.
We have a custom Authorize SIM payment coded that uses GravityForms. Those still function after updating and going to HTTPS.
Is there something in the WordPress database that would be holding onto an http that could be messing this up?
|
|
Josh
|
January 5, 2017 at 7:49 am
I’m not aware of anything in the database that would hold onto an http.
Can you double-check and make sure that you don’t have debug mode set to Yes in the Event Espresso > Payment Methods > Authnet SIM settings? If it’s set to yes, then it’s posting transaction requests to the Sandbox URL, and if you’re using a production API login, you’ll get that error.
The support document for the error you’re seeing says there are 3 possible things that will cause that error:
This error indicates you are either posting the incorrect API Login ID within your script, connecting to a server that does not recognize your account, or using an account that is inactive.
|
|
Jeff Long
|
January 5, 2017 at 9:57 am
Hello. After pecking and tinkering, we’re still unable to get past the issue we are facing.
We had updated from 4.8.31.p to the current version. At this juncture, we’re aiming to restore functionality by reverting to 4.8.31.p. without altering the database.
Can you tell me if updating from 4.8.31.p to the current version would have resulted in any alterations to the database structure that would make it incompatible with 4.8.31.p?
|
|
Josh
|
January 5, 2017 at 10:05 am
Yes it would. If you revert to 4.8.31.p, you’ll need to restore the database back to the point before you ran the update to the current version of EE4.
|
|
Jeff Long
|
January 5, 2017 at 10:15 am
Bummer.
We’re still getting the following error in our PHP log when we attempt transactions:
PHP Fatal error: Call to a member function enqueue_js() on a non-object in /filepath/wp-content/plugins/event-espresso-core-reg/modules/single_page_checkout/EED_Single_Page_Checkout.module.php on line 1406
we’ve attempted
– reuploading all EE files
– restting all API details
– visiting the /registration-cancelled/ page to clear our session
– verified that Sandbox/etc is not enabled
We’ll attempt a transaction with all non EE plugins disabled now.
Do you have any other suggestions?
|
|
Josh
|
January 5, 2017 at 11:17 am
Two things that may help:
1) Check with WPEngine to make sure that the no-cache rules set up for Event Espresso pages are still working (maybe they need to be updated since the change to https)
2) Check with WPEngine to make sure the Heartbeat API isn’t deactivated (they deactivate it, and that breaks the Event Espresso payment page because there are scripts on the Event Espresso payment that rely on the WordPress Heartbeat API).
|
|
Jeff Long
|
January 5, 2017 at 11:21 am
Okay. We’re running full steam again and it turns out that SSL was the source of the problem. …Which is completely stumping me.
Especially because I have another hand-coded feature on the website that uses Authorize.net SIM that worked this entire time – SSL or not.
So, that narrows the conflict down to:
(1) the latest version of Event Espresso & Plugins
(2) SSL active
(3) failure to confirm payment (can not return to website after successful submission of the Authorize.net payment form)
Returning Authorize.net error code 13 (even though the API keys are valid, sandbox is off, etc) and PHP error PHP Fatal error: Call to a member function enqueue_js() on a non-object in /filepath/wp-content/plugins/event-espresso-core-reg/modules/single_page_checkout/EED_Single_Page_Checkout.module.php on line 1406
With those specifics – do you have any thoughts about where to stab my poker?
|
|
Josh
|
January 5, 2017 at 11:31 am
So none of those errors happen if the site isn’t using SSL?
|
|
Jeff Long
|
January 5, 2017 at 12:17 pm
That’s correct.
|
|
Josh
|
January 5, 2017 at 12:27 pm
It sounds like that may be an incorrect set up of SSL, but did you check to see if the no-cache rules and enabling the Heartbeat API both work as expected when SSL is activated?
|
