LovingBro (woo-hc)

Hi @csdshop,

I can see how disruptive this has been for your workflow, especially with the editor repeatedly losing connection and saving being blocked for long periods while you are working on products. That is understandably frustrating.

From the screenshot you shared, those continuous admin-ajax.php requests tied to imgo_x_check_optimization_data strongly point to the Web Image Optimization X plugin making repeated background calls while you are editing, rather than only during image upload. This kind of behavior can overwhelm the editor and lead to the “Connection lost” message you are seeing.

To move forward, I would recommend a few focused checks:

1. Plugin conflict test
   Temporarily disable the image optimization plugin and try editing a product again. If the issue stops immediately, that confirms the plugin is the source.
   You can follow this guide for a safe test:
   https://woocommerce.com/document/how-to-test-for-conflicts/
2. Check for updates
   Make sure both WooCommerce and the plugin are fully up to date, as this could be a known issue already addressed by the developer.
3. Alternative plugins
   If the issue is confirmed to come from that plugin, you may want to switch to a more stable and widely used option such as:

• Smush
• EWWW Image Optimizer
• Optimole

These handle compression and WebP conversion without aggressively polling the editor in most setups.

4. System Status Report
   If you would like us to take a closer look, please share your System Status Report via https://pastebin.com or https://gist.github.com and include the link here.

Given the behavior you are seeing, it would also be a good idea to reach out to the plugin developers, since this looks like an optimization routine running when it should not.

Let me know what you find after disabling the plugin, and we can take it from there.

Hi @tyresesamples,

Great question, and it’s good you’re thinking about this early as it can really impact how clean and scalable your store setup is.

In most cases, using one variable product for items that share the same base product but differ by options like size and color is the recommended approach. This keeps your catalog organized, improves the shopping experience, and avoids duplicate listings for essentially the same item.

Separate simple products are usually better only when the items are truly different products, for example different designs, materials, or when they need unique descriptions, pricing logic, or SEO focus.

For your use case, a variable product is likely the best fit. You can learn more about setting this up here: https://woocommerce.com/document/variable-product/

If you run into anything while setting it up, feel free to share details and we’ll be happy to guide you further 🙂

Hi @jeffbeck,

Thanks for the detailed update and for sharing the logs and screenshots, this really helps clarify what is happening. I can see that even with automated taxes connected, the system is still writing QST as 0% and creating standard rate entries during checkout, while manual taxes behave correctly, which is a very useful finding.

From the logs you shared, it does look like the tax flow is falling back to manual handling during calculation, even though the service is being requested. The repeated entries and the _legacy: true context further support that WooCommerce is not consistently relying on the automated tax response at checkout.

At this stage, you have done all the right troubleshooting steps already, including isolating plugins, testing on staging, and validating with manual taxes. The fact that manual taxes work without creating entries confirms the issue is specific to the automated tax service flow rather than general tax configuration.

Please feel free to take your time to review things further with your developer, especially around any server level factors such as API requests, firewall rules, or anything that might affect outbound connections to WooCommerce tax services.

As an additional check, you could also try temporarily rolling back the WooCommerce Tax plugin to a previous version, ideally one that was in use before April 11 when the issue started, and then test again. This can help confirm if the behavior is related to a recent update.

In the meantime, using manual tax rates as a temporary workaround is a solid approach to ensure correct tax collection for your customers.

Whenever you have an update from your developer or additional logs to share, feel free to post them here via https://pastebin.com or https://gist.github.com and we will continue working through this with you.

Hi @hansnielsen,

Thanks for the follow-up, I can see you’re trying to clarify how the current WooCommerce flow handles cancellations, especially for customers without accounts, and how that fits into the upcoming requirement.

By default, WooCommerce does not provide a built-in option for customers to cancel orders themselves from the frontend, whether they have an account or checked out as a guest. Order management actions like cancelling or refunding are typically handled by the store admin from the dashboard.

For logged-in customers, you can customize the My Account → Orders page to add a cancellation request or button using custom code or a plugin, but this is not available out of the box.

For guest customers, there is no native way for them to access or cancel their order after checkout since they do not have an account area. In such cases, stores usually handle cancellations via a contact form, email request, or a custom-built solution that allows order lookup and actions.

If you’re looking to align with the upcoming EU directive, you’ll likely need a plugin or custom implementation that introduces a visible cancellation/withdrawal button and handles both logged-in and guest scenarios. You can explore extending order actions here: https://woocommerce.com/document/introduction-to-hooks-actions-and-filters/.

And if you’d like to see this supported natively in WooCommerce, adding your use case to the feature request board can help: https://woocommerce.com/feature-requests/woocommerce/.

Let me know if you’d like guidance on plugin options or a possible approach to implement this.

Hi @cshinkin,

Thanks for reaching out, I can see how concerning it is to suddenly lose the connection with Royal Mail Click & Drop, especially if it was working fine before. Let’s work through this together to get things back on track.

To start narrowing this down, could you confirm a couple of things:

• Has anything recently changed on your site, such as updates to WooCommerce, plugins, or WordPress core?
• Are you using a specific plugin or integration for Royal Mail Click & Drop, and if so, which one?

A few initial checks that can help:

• Ensure your API credentials or integration settings with Royal Mail are still valid and have not expired
• Double check if the integration plugin is up to date
• Review any error logs under WooCommerce > Status > Logs for clues related to the integration

If possible, please share your System Status Report so we can take a closer look:
https://woocommerce.com/document/understanding-the-woocommerce-system-status-report/

You can paste it via https://pastebin.com or https://gist.github.com and share the link here.

Once we have that, we’ll be in a much better position to guide you further.

Hi @jeffbeck,

Thanks for the detailed follow-up and the additional screenshots, this really helps clarify what is happening. I can see the pattern now where each checkout recalculation is creating new standard rate entries and incorrectly setting QST to 0%, which is definitely not expected behavior.

At this stage, the first step I would recommend is to go ahead and delete all the auto-generated tax rate entries you’re currently seeing under WooCommerce → Settings → Tax → Standard rates. Once cleared, please run a few checkout tests again using Quebec and non-Quebec addresses and monitor closely to see if those entries get recreated automatically.

Based on your screenshots and testing so far, here are a few additional focused checks:

• Since Automated Taxes is enabled, the Standard rates table should ideally remain empty. The fact that it’s being populated suggests something is forcing WooCommerce to fall back to manual tax handling.
• Double check that “Enable automated taxes” is still active and properly connected under WooCommerce → Settings → General. If the connection to WooCommerce Tax drops, WooCommerce may revert to standard tax tables.
• Try temporarily switching the shipping address to a different Quebec postal code and confirm if the same behavior occurs, this helps rule out any postcode-specific anomaly.
• Clear any caching layers in place, including server cache or plugins if applicable, as stale tax data can sometimes persist across requests.
• If possible, test this on a staging site with the same setup. Since you’ve already done a conflict test, this will help confirm if it’s environment-related or tied to the live setup.

If after deleting the entries they continue to regenerate, the next step would be to take a closer look at logs and your setup. Please share your System Status Report via: https://pastebin.com or https://gist.github.com

We’ll continue digging into this with you, as this behavior is not expected with WooCommerce Tax. Looking forward to your findings after clearing the entries.

Hi @raunharmantech,

Thanks for your follow-up here, I can see you’re trying to share the CSV export so we can take a closer look and guide you properly.

Since CSV files aren’t well suited for Pastebin, you can upload the file to a file sharing service like Google Drive or Dropbox, then share the public link here. That way we can access the file and review the price formatting directly.

If possible, please ensure the link is set to “anyone with the link can view” so we can open it without restrictions. Once you’ve shared the link, I’ll be happy to take a look and help you clean up the pricing values.

Hi @javimetal,

Thanks for highlighting this, I can see how confusing it is when “Payment methods” shows in English at checkout and creates friction for customers, especially when the rest of the store is translated.

What you’re seeing comes from the newer Stripe checkout experience, and that label is not the old “Stripe” gateway name but a generic string coming from the payment methods UI, which is often handled via JavaScript. Because of that, it may not appear in standard translation scans.

Here are a few things you can try:

1. Update translations
   Go to Dashboard → Updates → Translations and refresh them to ensure you have the latest language files.
2. Translate via Loco Translate (JS strings)
   When using Loco Translate, make sure you are editing translations for: WooCommerce Stripe Payment Gateway. Also enable the option to include JavaScript strings when scanning. Guide: https://localise.biz/wordpress/plugin/manual
3. Check if you’re using Checkout Blocks
   If your checkout is using blocks instead of the shortcode, some strings are handled differently and may rely on translations from WordPress language packs instead of plugin strings.

If the string still does not appear for translation after this, it may require adding a custom translation filter or waiting for it to be included in the official language files.

Let me know how it goes after trying the above, happy to dig deeper with you if needed.