codebuddy

Great stuff, thanks for confirming!

Hi @doublezed2,

Thanks for your response, much appreciated.

We aren’t experiencing any issues at all. The date specified in the email from Braintree has been and gone. My understanding is that this is the official Braintree plugin to use for WooCommerce? Given that and the previously mentioned email, I was looking for an authoritative response on if this plugin matches the requirements detailed in the email? Are the 5 now mandatory 3DS fields passed by this plugin in the 3DS Authentication Request (AReq)?

Hi @tibetanitech – thanks for this, I’ve now raised a ticket over there.

Hi @kellymetal thank you very much for your response. Unfortunately the user didn’t come back to us on this one, however…we have had one more report of this. Again, lots of other sales going through without issue. I asked the user to refresh and this resolved the issue for them.

I’ve looked in our Braintree logs. Other than the successful transactions that are human readable there are just lots of request / response pairs that are base64 encoded. Given the log has users details in it I’m not able to share. Are these requests to load the initial form before payment?

Request
environment: production
uri: generate
data: Array
(
)

What should I be looking for in the responses after decoding them? Or will there be an explicit error line logged? or just a missing Response? If this is just a temporary timeout type issue, is there a way to configure the plugin to retry?

Thanks Jeff, I’ll give that a whirl!

Hi Jeff, thanks for taking a look at this.

Yes, it’s certainly useful for us. In our deployment, when users are checking out to pay for their products, we ask them to either login or create an account – when they do this we want them to return to the correct stage in the checkout, not the url configured (their account home page). Not doing so could lead to an increase in the number of abandoned carts etc.

Should also add, using Version 0.4 of Debug This, Cheers.

I did – I’m using WordPress 4.4.2 I get the following:

[14-Apr-2016 09:29:57 Europe/London] PHP Fatal error: Cannot use object of type WP_Error as array in /Users/foo/public_html/wp-content/plugins/debug-this/debug-this.php on line 195

Ah – just spotted the config option. For those that haven’t:

In wordpress admin:

Settings->ShareThis then click “View & Edit code:”

In the “Modify script tags” window click the https radio button, then click SAVE.

Awesome!

Proposed patch, what do you think Jeff? ??

File: theme-my-login/includes/class-theme-my-login.php around line 138.

} else {

						do_action( 'validate_password_reset', $this->errors, $user );

						if ( empty($this->errors->errors) && isset( $_POST['pass1'] ) && ! empty( $_POST['pass1'] ) ) {
						self::reset_password( $user, $_POST['pass1'] );

						$redirect_to = site_url( 'wp-login.php?resetpass=complete' );
						wp_safe_redirect( $redirect_to );
						exit;
						}

Just to be clear – If I disable TML the action is called as expected.