wbrubaker.a11n

Thanks for that. Presumably, the vendor emails that you are referring to are generated by WooCommerce Multivendor Marketplace or, possibly by WooCommerce PDF Invoices & Packing Slips: door Ewout Fernhout. In either case, please do contact the appropriate plugin support team to ask that they add compatibility for the new checkout experience.

Thanks for that. I’m not seeing anything in that system status report that might explain the behavior. It may simply be abandoned transactions, but if you feel there is something else behind it, please do let us know what steps we can take to reproduce it.

If you were to provide the exact error message you are seeing on Facebook, that might help, but I believe that you are probably faced with this issue: https://github.com/woocommerce/facebook-for-woocommerce/issues/1777 which remains open and under investigation.

You should expect that the use of a CDN would not interfere with the conversion api sending data.

The WordPress customizer can be used for custom CSS snippets. https://codex.www.ads-software.com/CSS

get_shipping_method_class_names is used to generate those and it provides a filter named woocommerce_shipping_methods that you could hook into to change the id to suit your needs.

https://github.com/woocommerce/woocommerce/blob/5.9.0/includes/class-wc-shipping.php#L148

It’s certainly possible. I’d suggest you open an issue on the repo or better yet, submit a PR. https://github.com/woocommerce/woocommerce-gutenberg-products-block

Hi there,

To be clear, analytics tracking is disabled for admin users just in case that’s how you’re testing this, you’d want to test as either a guest user or a logged in customer.

I’ve done some testing on a site of mine and WooCommerce Google Analytics Integration works there as expected. I’ve also searched our issue tracker for other reports of this type of behavior: https://github.com/woocommerce/woocommerce-google-analytics-integration/issues and I wasn not able to find any. This leads me to believe that the problem you are experiencing is caused by something external to WooCommerce and WooCommerce Google Analytics Integration. My suggestion would be to test for software conflicts to try and isolate the cause of this. There’s some documentation about that here: https://woocommerce.com/document/how-to-test-for-conflicts

It is also possible to load a debug version of the JavaScript that google provides which will output debug information in the browser console. If you feel that may help you isolate the cause of this issue, you can find a copy of a plugin that will load that debug script here: https://github.com/WillBrubaker/hiro-ga-debug/blob/main/hiro-ga-debug.php

An unresponsive button is generally caused by a JavaScript error. If you’re familiar with your browser’s developer tools, you might have a look at the error console for clues.

Aside from that, this behavior is not reproducible in my testing and I am not able to find any reports of this type of behavior on our issue tracker here: https://github.com/woocommerce/google-listings-and-ads/issues

This leads me to believe that the problem is caused by something external to WooCommerce and Google Listings & Ads. I’d suggest conflict troubleshooting to try and isolate the cause. See: https://woocommerce.com/document/how-to-test-for-conflicts

There is no configuration option to achive that. It is likely possible via custom code. If you would like to pursue customization but are not comfortable doing it yourself, you may want to contact someone from our customizations page.

I send you the screen.

That doesn’t seem to have made it, unfortunately.

I found only “last_payment_error”: null, but the payment was successful, in fact on the dasboard stripe payment is ok.

What that’s telling you is that nothing is wrong with Stripe then and this failure is not directly related to Stripe. My guess is that a fatal error is happening after the payment is processed but before the order can be transitioned to a paid status. This is typically caused by PHP timeouts which have their root cause in a slow email server when sending the transactional emails. This also makes sense in the context that the problem seems to be intermittent. I’d suggest examing the server PHP error logs for clues and looking for any error messages around the same time that these orders were placed.

Hi there,

It’s a bit unclear if you are using one of the Additional Payment Methods that Stripe provides and that might make a difference. If this is in the context of one of those additional payment methods, the first thought I have is that there is a webhook problem and I would suggest you review your webhook settings. See: Webhooks

If not, then the most likely explanation is a fatal error during the payment process that is preventing the order from being marked as paid on WooCommerce even though the payment processed successfully. If that is the case I expect you could find evidence of that in the WooCommerce fatal error log. WooCommerce -> Status -> Logs and then in the dropdown selector, look for any logs where the name begins with fatal-errors, followed by a date/time, followed by random letters/numbers. That may be a good place to begin looking for clues.

Stripe also offers some debug logging functionality of its own and you can enable that to get more information about the request that is sent to Stripe and the response that comes back. Enabling logging can help you in the case of webhook problems as well. See *Log Debug Messages* under: https://docs.woocommerce.com/document/stripe/#setup-and-configuration

Kind regards

Howdy ??

That documentation is specific to the Stripe SDK which is not used by the WooCommerce Stripe payment gateway as we use the WordPress HTTP API to send and receive our requests rather than relying on the SDK.

I’m sure that you can use it, but you’d need to include the files before instantiating the class.

Hi, thanks for that. There’s nothing obvious in that system status report to explain this behavior.

I have done a bit of testing on a test site of mine using the debug version of the Google Analytics JavaScript which will provide debug messages in the JavaScript console of the browser. Doing that on a test site here: https://wctesting.tk/shop/clothing/accessories-clothing/sunglasses/ I can definitely see that the product name is sent with the add to cart event:

Link to image: https://d.pr/i/Nt7nto

An example of that debug code can be seen here: https://github.com/WillBrubaker/hiro-ga-debug/blob/main/hiro-ga-debug.php – you could install that as a plugin if you’d like to use it to debug on your own site. given that this is not reproducible in my testing nor are there any other reports of this on our issue tracker, I am left to believe that the behavior on your site is caused by something external to WooCommerce and WooCommerce Google Analytics Integration.

If you are able to reproduce this under the following conditions:

1. An unmodified, default WordPress theme such as Twenty Twenty or [Storefront](https://www.ads-software.com/themes/storefront/) active.
2. No other plugins except for WooCommerce and WooCommerce Google Analytics Integration active.

Please do let open an issue here: https://github.com/woocommerce/woocommerce-google-analytics-integration

I’ve reopened the issue here: https://github.com/Automattic/woocommerce-payments/issues/2805 — feel free to follow along there for updates.

The price that is sent to the Google Merchant Center is run through a filter named woocommerce_gla_product_attribute_value_price that you can see in code here: https://github.com/woocommerce/google-listings-and-ads/blob/1.4.2/src/Product/WCProductAdapter.php#L523

So, you could hook into that and your callback function could return the price – 10%. Something like this might work: https://gist.github.com/WillBrubaker/d7727179e7c083aed1bb78a63ec4adde