Thank you for the explanation. The data which appears in the application/ld+json element should be pulling all the information in accordance with the settings in your store’s general settings. However, like a lot of data in WooCommerce, it can be manipulated by plugins as it is loaded.
We’ll need to establish if this is the case on your store. It would be great if you could do this on a staging site, as it means you can do it without disrupting regular customers.
First: is it consistent. Does the price of specific items always show in 4 decimal places, while the price of other specific items do not? Can you see a pattern – all variations, all on sale, all out-of-stock – something like that?
The best way to determine if the issue is being caused by a theme or plugin is to temporarily switch your theme to Storefront and disable all plugins except for WooCommerce . Then test to see if the issue is resolved. Are those consistent prices on the site that you discovered in the first step still displaying incorrectly?
To figure out which plugin is causing the problem – reactivate your other plugins one by one, testing after each, until you find the one causing conflict.
Meks Quick Plugin Disabler is a plugin you can install which will remember what plugins you currently have active so it’s easy to switch them back on. Link:
You can clone your site to a staging environment and perform tests without modifying your live site or impacting customers. Many hosts provide staging facilities, so it’s worth checking in with them. It’s also possible to do it using the free WP Staging plugin.
Let us know how this goes, and we’ll be able to take the next step in the troubleshooting process.
We currently have no plans to implement any further event tracking in this extension. There are some extensions which do this, such as WooCommerce Google Analytics Pro.
We continue to investigate the issue of the ability to save invalid settings which you have brought to our attention, and are discussing this with our developers.
Thank you for the details. The administration dashboard of a WordPress site often does place the infrastructure under strain, as the admin side of the site cannot be cached in the same way that the front-end of a website might be.
We would recommend that your database caching be considered; secondly, that you implement an object caching layer using Redis or a similar system.
Could you please elaborate on the type of errors you are seeing? Are they 502 or 503 gateway timeout errors? In WooCommerce > Status > logs, are you seeing any fatal errors? What nature of error is reported?
They can be accessed at WooCommerce > Status > Logs with the name fatal-errors-DATE-string as in the screen capture below:
Could you please send me a copy of your site’s System Status? You can find it via WooCommerce > Status. Select “Get system report” and then “Copy for support”. Once you’ve done that, you can paste it into a text file and attach it here.
Thank you for the report. We have some known issues with the translation of some strings in the Settings pages, such as this one.
A specific issue for RTL sites has been reported here, but we have not received any additional information from the reporter. Can you help us identify the issues? It seems that you have a good understanding, as you mention the $screen_id, JS and CSS styles.
This would help our developers understand the root causes of the problem. Could you provide screenshots, for example? It would be most helpful.
Thank you for that. I am seeing several different messages on your site, each related to the same problem.
Maximum simultaneous queues already in progress (1 queue). No additional queues
This is generated by Action Scheduler. Action Scheduler is designed to run only one set of scheduled actions at a time, to prevent background processes from pulling too many resources from the server at once. This prevents background updates from slowing your site down.
WP_CRON is disabled
If yourWP_CRON is disabled, then Action Scheduler will not run as often as it needs to. WordPress Cron is used to trigger the action scheduler every 60 seconds. If you are using an alternate Cron, and it is working okay, then you should be fine. Please ensure your Cron is working, and that it is triggering correctly.
Probably the easiest way to do this is to publish a scheduled post – and wait to see if it publishes on time.
Your action scheduler has 15 000 pending jobs due.
This is a fair number of jobs. It may be that a plugin has queued a lot of jobs to be run and your site is battling to make it through the list of jobs. Or it may be that your Action Scheduler has not been triggering correctly for some time, and jobs have been backing up.
Could you send a copy of your site’s System Status? You can find it via WooCommerce > Status. Select “Get system report” and then “Copy for support”. Once you’ve done that, you can paste it here. The system status report has information on the status of both your Cron and your Action Scheduler that can help us establish what the problem might be.
I’m sorry to hear the problem is still occurring. Like your hosting provider, we can see nothing in your log files to show us why this is occurring.
We have also tested, and cannot get this to occur on a test site.
Since I do not have an account, I cannot reach checkout on your store. However it was while trying to get checkout that I noticed that a login action pops up when I try to checkout. This page appears to be a specific page.
I am therefore curious to know if the email reset password is not sent at this stage, before checkout actually take place, or if it is sent after checkout takes place. In other words, if you wait on checkout, after logging in, without progressing through checkout, does the email still get sent?
At this stage, we’d also recommend a full conflict test. We need to know if the same thing occurs with only WooCommerce and Storefront, and a default gateway such as BACS, is running.
It’s best to do such a test on a staging site.
The best way to determine if the issue is being caused by a theme or plugin is to temporarily switch your theme to Storefront and disable all plugins except for WooCommerce . Then test to see if the issue is resolved.
To figure out which plugin is causing the problem – reactivate your other plugins one by one, testing after each, until you find the one causing conflict.
You can clone your site to a staging environment and perform tests without modifying your live site or impacting customers. Many hosts provide staging facilities, so it’s worth checking in with them. It’s also possible to do it using the free WP Staging plugin. Link: https://wordpress.org/plugins/wp-staging/
The view_list_item event is designed to register when an item is viewed in a list. You site fires this event for each item in the list of products on the page.
I’ve tested your code above on PHP 8.1.9 and it does, in fact, appear to work on a test installation running only WooCommerce 7.2.2 and Storefront theme. The coupon is included in the outgoing email
Note your code will only show the first coupon added, if more than one coupon is added, some will be lost. I’m sure you’re aware of this though.
We’ve also retested the developer document snippet at this link and can confirm that it is working for us on the Storefront theme with WooCommerce 7.2.2 and PHP 8.1.9. It does not interfere with the cart emptying.
We’re testing here with standard coupons and no other extras. Is it possible that something on your site is interfering with the woocommerce_thankyou action or the $order->get_used_coupons()? This may be caused by a conflict with the theme or another plugin.
This is a fairly complex development topic and outside the scope of our normal support. I’m going to leave it open for a bit to see if anyone is able to chime in to help you out.
You can also visit the WooCommerce Facebook group or the #developers channel of the WooCommerce Community Slack. We’re lucky to have a great community of open-source developers for WooCommerce, and many of our developers hang out there, as well.
will cause all transactions to fail if you are operating in a jurisdiction such as the UK, where 3DS is required.
It will also cause transactions to fail if a card issuer requires 3DS, because, essentially, what adding the code means is that your site does not support 3DS.
This reply was modified 3 years, 8 months ago by nicw.a11n.
If you’re not seeing the same problem after completing the conflict test, then you know the problem was with the plugins and/or theme you deactivated. To figure out which plugin is causing the problem, reactivate your other plugins one by one, testing after each, until you find the one causing conflict. You can find a more detailed explanation on how to do a conflict test here.
Thank you for opening the support ticket – we’ll need to exchange details in the support thread.
However, I can confirm you do not need an Apple Merchant ID. You do, however, need to have a domain verification file at https://[DOMAIN_NAME]/.well-known/apple-developer-merchantid-domain-association.
