jackpd

@mrclayton thanks for your reply. I’m just trying to better understand what could be the cause when it so clearly happens to a minority of orders with very specific traits. I shall submit a support ticket ASAP. I appreciate your attention and willingness to look into it regardless of the outcome.

@barnabas1 I have one other query for you if you don’t mind as we looked primarily at similarities with our plugins previously. I’m wondering now if maybe we’re using the same theme? We’re using Shoptimizer, is this the same for you? Or not the case?

@barnabas1 Surprisingly Redis was/is not the cause for us either.

We still are getting about 3-5 of these per day, always Apple Pay or PayPal payments. It has never affected a standard Stripe card payment order.

@mrclayton can you think of a reason why the only orders to be impacted by this would be Apple Pay / PayPal orders? Is the “order save” flow different for these orders as opposed to standard card payment orders?

It’s beyond just a trend now, we have enough data to say for sure it has zero impact on the credit/debit card orders, so figuring out how Apple Pay/PayPal differs seems like the next obvious place to investigate.

Thanks in advance

@barnabas1 Just one last clarification to make sure the problem we are seeing is identical.

When you view an affected order on WooCommerce, the incomplete/fragmented address shows in the billing address section only and the shipping address is empty/blank?

@barnabas1 if that’s the case then I’ve got a strong suspicion it’s something to do with Redis as both plugins are basically just a sort of WP interface for Redis and effectively do the same thing. We’re also on Nginx funnily enough but I’d like to rule out Redis first before looking into Nginx being a cause as in my opinion it’s less likely.

I will run some tests and if need be, I’ll disable Redis for a period of time to see if the issue goes away. I’ll be sure to let you know if I do get to the bottom of it as your input has been helpful.

On an unrelated side note: We used to use the same plugin as you but switched as it doesn’t fail gracefully like wp-redis does. Something to keep in mind if you ever see Redis errors in your logs.

• This reply was modified 9 months, 2 weeks ago by jackpd.

Thanks both for your replies.

@barnabas1 out of interest, do you use any sort of object caching? E.g. Redis, Memcache or similar?

@mrclayton okay, will do. WP-redis just enables an object cache via a redis instance. I might even try disabling it for a week and I can at least rule it out if the issue reoccurs.

If it is indeed stale order data, I’m just wondering where the partial/incomplete address data is coming from? In all cases, it’s been the city, country and half of the postcode I.e AB1 or CM12, it’s never complete.

e.g. a customer adds some items to the basket, goes to checkout and clicks pay with Apple Pay express checkout (before entering any address details at all) – at what point would WooCommerce get the customers city and half the postcode – which is later set against the order instead of the complete Stripe address details?

Many thanks,

Jack

Apologies for jumping in on someone else’s thread, but we’re having the same issue and thought replying would preferable than starting a new thread. If not, please let me know and I’ll start a new one.

We’re using both your Stripe plugin (with cards and apple pay active) and PayPal plugin. Approx 10 out of 1000 odd orders we’ve received since going live have incomplete address data. Shipping address completely empty with billing address partially complete against the order. As you stated above, it is the case that the complete address details can be found on the Stripe transaction.

The issue is very sporadic and so far 9 affected orders have been Apple Pay and 1 PayPal. There was also one instance where the same customer purchased with Apple pay about an hour apart, one order was fine, with the other affected as above.

You mention it will likely be another plugin causing the issue, we’re fairly light on plugins:

Active Plugins (15)

The SEO Framework: by The SEO Framework Team – 5.0.6
CommerceGurus CommerceKit: by CommerceGurus – 2.2.9
Contact Form 7: by Takayuki Miyoshi – 5.9.4
GTM Kit: by GTM Kit – 1.22.4
Index WP MySQL For Speed: by Oliver Jones
Rick James – 1.4.18

Kirki Customizer Framework: by Themeum – 5.1.0
Klaviyo: by Klaviyo
Inc. – 3.3.5

Payment Plugins for PayPal WooCommerce: by Payment Plugins
[email protected] – 1.0.47

Premmerce Permalink Manager for WooCommerce: by Premmerce – 2.3.11
Payment Plugins for Stripe WooCommerce: by Payment Plugins
[email protected] – 3.3.62

WooCommerce Brands: by WooCommerce – 1.6.66
WooCommerce Dynamic Pricing: by Element Stark – 3.2.6
WooCommerce Google Product Feed: by Ademti Software Ltd. – 10.12.5
WooCommerce: by Automattic – 8.7.0 (update to version 8.9.2 is available)
WP Redis: by Pantheon
Josh Koenig
Matthew Boynes
Daniel Bachhuber
Alley Interactive – 1.4.4

As far as I’m aware the only plugin which could be causing issues like this with stale data is wp-redis. Do you agree this is likely the culprit out of the above list?

And if so, I can exclude certain keys from redis. Is there a way to exclude keys related to this particular issue?

Thanks in advance,
Jack

Many thanks, it no longer shows.

I have to say as well, that was a crazy fast response time. I think that must be the fastest response I’ve ever hard to any support query!

Cheers,
Jack

To add some more context to this bug I’m seeing:

1. It’s not a caching issue or anything related to caching, with all caching plugins disabled, this issue still occurs
2. Disabling your plugin resolves the issue
3. Keeping your plugin enabled but disabling the tax display module completely, the problem still occurs

So it’s a strange one, and I don’t completely understand why with the tax display module disabled the tax display nonce is still being echoed above my WC-API response.

I did find one “fix”, but since it relies on me directly modifying your plugin source code, I don’t really class it as a fix.

Changing wcj_button_toggle_tax_display() in class-wcj-general-shortcodes.php to the following resolves the issue:

public function wcj_button_toggle_tax_display( $atts ) {
	/* CUSTOM */
	$urlParts = explode('/', $_SERVER['REQUEST_URI']);
	if ($urlParts[1] === 'wc-api' || $urlParts[1] === 'wp-json')
		return '';
	/* CUSTOM */
	
	$session_value = wcj_session_get( 'wcj_toggle_tax_display' );
	$current_value = ( ( '' === $session_value || null === $session_value ) ? wcj_get_option( 'woocommerce_tax_display_shop', 'excl' ) : $session_value );
	$current_value = '' === $current_value ? 'excl' : $current_value;
	$label         = $atts[ 'label_' . $current_value ];
	return '<form method="post" action="">' . wp_nonce_field( 'wcj_button_toggle_tax_display', 'wcj-button-toggle-tax-display-nonce' ) . '<input type="submit" name="wcj_button_toggle_tax_display"' .
	' class="' . $atts['class'] . '" style="' . $atts['style'] . '" value="' . $label . '"></form>';
}

So I will go with the above solution for now, but obviously as soon as I update your plugin, it’s going to resort back to the issue being present, so I would really appreciate one of your developers chiming in on this.

Many thanks,
Jack