LovingBro (woo-hc)

Hi @jeffbeck, thanks for the detailed report and screenshots, I can see how concerning it is to have tax rates being dynamically created and QST values unexpectedly set to 0, especially when using automated taxes.

From what you’ve shared, this behavior isn’t expected when Automated Taxes is enabled. With WooCommerce Tax, rates should be calculated on the fly and not written into the standard tax table like this. The entries you’re seeing suggest that something is overriding or interfering with the automated tax flow.

Here are a few focused checks to help narrow this down:
First, please confirm that there are no manual tax rates configured that could conflict. When automated taxes are enabled, WooCommerce uses its own service and manual entries are typically not needed. You can review this here: https://woocommerce.com/document/woocommerce-tax/

Next, run a quick plugin conflict test. Temporarily disable all plugins except WooCommerce and WooCommerce Tax, then switch to a default theme like Storefront and test the checkout again. This helps identify if another plugin is programmatically inserting or modifying tax rates during calculation.

Also, check if any custom code or snippets are hooked into tax-related filters such as woocommerce_calc_tax or woocommerce_before_calculate_totals, as these can alter tax behavior or even insert rows.

Since the issue appears to trigger during checkout recalculations, it would be helpful to see if this still happens on a clean setup. If possible, test this on a staging site to avoid affecting live customers.

If the issue persists after the above, could you share your System Status Report via https://pastebin.com or https://gist.github.com? That will help us take a closer look at your setup.

We’ll keep digging with you on this, as this definitely isn’t the expected behavior.

Hi @jlkogut, thanks for the detailed update and for sticking through all the troubleshooting so far, it’s great to hear that the Site Health issues are now resolved, that’s a big step forward and very likely the root cause behind the earlier Action Scheduler behavior.

You’re absolutely on the right track with your assumption here. Pending actions are typically scheduled to run at a future date or are part of recurring tasks, so it’s normal for them to remain in the “pending” status until their scheduled time arrives. As long as they are not becoming “past-due” again and are executing when expected, this indicates things are now functioning properly.

A quick way to confirm everything is healthy:

• Monitor the Scheduled Actions queue for a bit and ensure pending actions transition to “complete” at their scheduled times
• Check that no new actions are getting stuck as “past-due”
• Optionally run a few pending actions manually to confirm they process and clear as expected

Regarding the canceled actions you mentioned earlier, there’s no need to retain them, they are safe to delete as they won’t be executed again and clearing them can help keep things tidy.

At this point, things look to be back on track, but feel free to keep an eye on it and let us know if anything unexpected comes up.

If this resolves your concern, kindly consider leaving a review for WooCommerce, it really helps other merchants who may run into similar situations: https://wordpress.org/support/plugin/woocommerce/reviews/#new-post

Hi @patrickhaond, thanks for reaching out, I can see how frustrating it is when the PayPal connection keeps looping back to the “Connect to PayPal” screen despite completing the steps, let’s work through this together.

This behavior is usually related to a failed authorization callback, often caused by caching, a conflict, or something interrupting the redirect back to your store.

Here are a few things to check:
First, clear any caching on your site and server, including any caching plugins or host level cache. Also try the connection in an incognito/private browser window to rule out browser related issues.

Next, please run a full conflict test. Temporarily deactivate all plugins except WooCommerce and switch to a default theme like Storefront, then try connecting PayPal again. If it works, you can reactivate everything one by one to identify the cause.

Also, confirm that your site URL matches exactly in both WordPress settings and your PayPal account, including http vs https and www vs non www, as mismatches can break the return flow.

It would also help to check for any errors in your browser console during the connection attempt, and any fatal errors in your site logs.

If the issue persists, please share your System Status Report via https://pastebin.com or https://gist.github.com so we can take a closer look. You can find it under WooCommerce, Status. For additional guidance, you can review this setup guide: https://woocommerce.com/document/woocommerce-paypal-payments/

Looking forward to your findings so we can get this sorted.

Hi @christie212,

Thanks for reaching out, I can see how concerning it is to be redirected to the setup wizard when you’re trying to access your existing WooCommerce settings, especially with a live store already in place, let’s get this sorted.

To better understand what’s happening, could you please share a screenshot of what you’re seeing on your end when this occurs? You can upload it via https://snipboard.io and paste the link here.

Kindly also share your System Status Report, this will help us check your site environment and configuration. You can find it via WooCommerce → Status → Get system report, then copy and paste it to https://pastebin.com or https://quickforget.com and share the link here.

Additionally, could you confirm when this started, was it after a recent update to WooCommerce, another plugin, or WordPress core?

Once we have these details, we’ll be in a better position to guide you on the next steps.

Hi @keeshub, thanks for reaching out, I can see how concerning it is when tracking codes and label printing options suddenly disappear from your WooCommerce orders even though your settings and API are correctly configured, let’s work through this together.

From what you’ve described, this is often related to either a recent update, a plugin conflict, or the PostNL plugin losing connection to certain hooks in WooCommerce.

To help narrow this down, could you please try the following:
First, confirm if this started after a recent update, either WooCommerce or the PostNL plugin. If so, it could point to a compatibility issue.

Next, run a quick plugin conflict test by temporarily disabling all plugins except WooCommerce and the PostNL plugin, then switch to a default theme like Storefront. After that, check if the tracking column and label options return. If they do, you can reactivate plugins one by one to identify the conflict.

Also, take a look at WooCommerce → Status → Logs to see if there are any recent errors related to PostNL. If you find anything, feel free to share it via https://pastebin.com or https://gist.github.com so we can take a closer look.

Finally, it may help to reconnect or re-save the PostNL API settings, as sometimes the connection can silently fail even if it appears configured correctly.

If the issue persists after these steps, sharing your System Status Report would be really helpful:
https://woocommerce.com/document/understanding-the-woocommerce-system-status-report/. You can paste it using one of the tools above.

Looking forward to your findings so we can get this fully sorted.

Hi @tonyzyc,

Thanks for giving that a try, I can see how confusing it is when the old attributes still show even after re-adding them and clearing cache.

At this point, it’s likely something is still holding onto the old product data. Let’s try a few quick checks:

Update the product again and make a small change like adding a space to the title, then save, this helps force a refresh.

Clear any server side or hosting cache as well, not just browser or Cloudflare.

Then do a quick conflict test by switching to a default theme like Storefront and disabling all plugins except WooCommerce, then check the product page again.

Also, if it’s a variable product, please confirm the variations themselves are using the updated attributes.

If it’s still the same, please share:
– Product URL
– Screenshot of Product data → Attributes
– System Status Report via https://pastebin.com or https://gist.github.com

Guide here: https://woocommerce.com/document/understanding-the-woocommerce-system-status-report/. That will help us take a closer look.

Hi @breadf,

Thanks for the detailed update and for taking the time to test and share your findings, this really helps narrow things down.

From what you’ve described, you’re absolutely on the right track. When an order shows as “Guest” in the Customer field, it means the order is not linked to a registered user account, even if the email matches an existing customer. In that case, the order will not appear under the My Account → Orders page for that user.

To answer your question directly, here are a few ways to tell if an order was placed by a guest:

• In WooCommerce → Orders → Edit Order, check the Customer field at the top
→ If it shows a name with a link, it’s tied to a user account
→ If it shows “Guest”, it was placed without being linked to a user

• You can also confirm this by checking if the order has a User ID associated with it, guest orders do not have one

What you’re seeing is expected behavior when guest checkout is enabled:
👉 Orders placed as guests are not automatically linked to user accounts
👉 Therefore, they won’t show in the customer’s account page unless manually linked

Since this is happening both before and after migration, it suggests:
• Some orders were placed as guests originally
• Others may have lost their user linkage during migration or WPML cleanup

For next steps, you have a couple of options:

• Continue manually linking important orders to users (as you tested)
• Disable guest checkout moving forward if you want all future orders tied to accounts
• Optionally use custom code or plugins to auto-link orders by email, though this falls outside core WooCommerce functionality

Here’s a guide on managing customer accounts and checkout behavior:
https://woocommerce.com/document/configuring-woocommerce-settings/#accounts-and-privacy

To help confirm everything is working as expected going forward, could you test placing a new order:
• While logged in
• And another as a guest

Then check how each appears in the frontend account page

Let me know what you find from that test, happy to continue digging into this with you 👍

Hi @hoseua,

Thanks for taking the time to share your findings with us, contributions like this are incredibly valuable and it is clear the effort you put into investigating the issue.

This will definitely help other WooCommerce users who might run into a similar situation, so we really appreciate you sharing it back with the community. Cheers!