LovingBro (woo-hc)

Hi @foykwalla,

Thank you for sharing the final update, and it is great to hear that the password reset functionality is now working correctly again on the live site.

You also did an excellent job methodically troubleshooting this across both the live and staging environments. The additional detail you shared about the temporary database/environment issue is very valuable and will likely help other merchants facing similar behavior in the future.

I am glad things are now functioning properly again across desktop, mobile devices, private browsing, and different browsers.

Since the issue appears resolved, I’ll go ahead and consider this topic closed. If the issue ever comes up again or if you need help with anything else in the future, please feel free to open a new topic and we’ll be happy to assist further.

Also, as your experience and troubleshooting process will help other merchants, could you please consider leaving a review for WooCommerce here: https://wordpress.org/support/plugin/woocommerce/reviews/#new-post

Thank you again for your patience and for working through the investigation so thoroughly.

Hi @foykwalla,

Thank you for the detailed follow up and for continuing to test this so thoroughly. The additional staging results are very helpful here.

Since the staging clone continues to work correctly even after restoring the plugins and WoodMart theme, while the live site alone still returns the invalid reset key message, this points much more strongly toward something environment specific on the live installation itself rather than a WooCommerce core issue.

One thing that stands out is that the staging site is using the same database content but a different URL/environment, and the reset flow works there. That can sometimes indicate:

• Object or page caching persisting stale reset keys on the live site
• A server level optimization affecting live sessions only
• A database inconsistency specific to the live environment
• Or a plugin/service behaving differently between live and staging despite matching configurations

At this stage, I would recommend checking the following next:

• Temporarily disable all caching layers directly from the hosting panel if possible, including any server side caching or Object Cache/Redis setup
• Check whether the live site has any active MU plugins, server optimization layers, or security rules that are not copied into staging
• Compare the following between live and staging:
  • siteurl and homeurl values
  • Active plugins list
  • WooCommerce account endpoint settings
  • WordPress salts/keys in wp-config.php
• Try resetting the affected user’s user_activation_key manually in the wp_users table and test again with a newly generated reset request
• Temporarily enable WordPress debugging to see whether any warnings, redirects, or errors occur during the reset validation request: https://wordpress.org/documentation/article/debugging-in-wordpress/

You may also want to temporarily disable LiteSpeed entirely on the live site for one test, since caching/session persistence can sometimes affect password reset validation unexpectedly even when exclusions are configured.

Based on all the testing completed so far, this does not appear reproducible as a general WooCommerce core issue, especially since the exact same cloned site works correctly in staging.

Please let us know what you find from the above checks.

Hi @0108daniel,

I can see how important this is for your store visibility on Google, especially since pricing information helps customers make quicker purchase decisions.

I checked the screenshots you shared, and I can confirm that none of the products from your site, https://model-kits.nl, are showing prices in the Google search results, while other stores are. Since you already confirmed that the Merchant Center feed and XML feed both contain the correct pricing and shipping information, this points more toward how Google is processing the structured product data on the site itself.

Could you please share:

1. The URL of one affected product
2. A screenshot from Google’s Rich Results Test for that product:
   https://search.google.com/test/rich-results
3. The result from testing the same product URL here:
   https://validator.schema.org/

Also, are you using any SEO or schema-related plugin besides WooCommerce? Sometimes multiple plugins outputting product schema can confuse Google and prevent price snippets from appearing correctly.

Once we have the product URL and schema test results, we can better narrow down what Google may be missing.

Hi @namespending,

I appreciate the update and the additional testing you carried out. It looks like you attempted to attach an image in your last reply, however the image does not appear to have come through correctly on the forum.

Could you please upload the screenshot using Snipboard and share the link here so we can take a closer look?

Since the reviews section is showing correctly when using the Storefront theme, that does indicate the issue is coming from how the Newsmatic theme handles the WooCommerce product tabs/review section, rather than from WooCommerce itself.

At this stage, I’d recommend reaching out to the Newsmatic theme support team so they can check why the Reviews tab is not being displayed properly with WooCommerce product pages.

Hi @slservice33,

Glad to hear you were able to find a workable solution for restoring the affected orders and notes.

As regards the spam messages from developers, the WordPress.org forums are public forums and while the forum moderators do try to keep the forums clean and reduce unsolicited contact, this can still occasionally happen when site details are publicly visible in support topics.

We appreciate you sharing the outcome here as it may also help other merchants who run into something similar in future.

If you have a moment, we’d also really appreciate it if you could share your experience using WooCommerce to help other merchants in deciding whether to use it: Leave a WooCommerce review.

Hi @equipet,

I can see how frustrating this would be, especially after already confirming that your catalog prices include the 15% VAT and WooCommerce is still adding tax again at checkout.

From what you described, this is usually caused by either the tax display settings, customer location settings, or a conflict from the theme/customizations overriding the expected tax behavior.

Please check these settings carefully:

1. Go to WooCommerce → Settings → Tax Make sure: , “Prices entered with tax” is set to Yes, I will enter prices inclusive of tax , “Display prices in the shop” is set to Including tax , “Display prices during cart and checkout” is also set to Including tax
2. Then go to WooCommerce → Settings → General Under Default customer location, try temporarily changing it to: , Shop country/region
3. After that, edit one affected product and confirm there is no extra custom tax class assigned accidentally.
4. Since your theme currently shows:

WooCommerce Support: Not declared

there is also a chance the active theme or another plugin is affecting price calculations. Please test temporarily using the Storefront theme: Storefront. If the issue disappears with Storefront active, then the problem is likely theme related.

You can also perform a full conflict test by temporarily disabling all plugins except WooCommerce and checking if the taxes calculate correctly: Conflict testing guide

If the issue continues afterward, please share:
– A screenshot of your WooCommerce tax settings
– A screenshot showing the product price before checkout and then the incorrect tax added in cart/checkout
– A screen recording if possible via https://snipboard.io or loom.com

That will help us narrow this down further.

Hi @giorgi1992,

I can see how frustrating this has been for you, especially having to repeatedly refresh and re sync products just to keep them active in Google Merchant Center. I’ll do my best to point you in the right direction here.

Since the products are being automatically removed from Google Merchant Center, this is often related to either product data requirements, sync interruptions, scheduled actions not running correctly, or Merchant Center policy/account level checks.

To help narrow this down further, could you please share the following:

1. Your WooCommerce System Status Report, you can find it via WooCommerce > Status > Get system report, then copy it to https://pastebin.com or https://quickforget.com and share the link here.
2. A screenshot of the Google for WooCommerce plugin status page under Marketing > Google Listings & Ads > Status, uploaded via https://snipboard.io
3. Please also check WooCommerce > Status > Scheduled Actions and see if there are any failed or pending actions related to:
   • google
   • gla
   • merchant
   • batch processing

If you find failed actions there, please share a screenshot as well.

Additionally, please make sure:

• Your products remain published and in stock in WooCommerce
• WP Cron is functioning correctly on the site
• No caching or optimization plugin is blocking REST API requests
• You are running the latest versions of WooCommerce and Google for WooCommerce

You can also review this guide regarding scheduled actions: https://woocommerce.com/document/understanding-the-woocommerce-system-status-report/scheduled-actions/

Once you share the requested details, we can continue troubleshooting further.

Hi @binaryfabric,

I can understand where you are coming from here, especially from an accounting and store management perspective where having clean, sequential customer facing order numbers feels more natural and expected.

At the moment, WooCommerce uses the WordPress post ID system for order IDs internally, which is why gaps can happen. These gaps are usually caused by failed checkouts, draft orders, temporary checkout states, deleted orders, and other background processes. The visible order number is therefore tied to the underlying order ID by design.

That said, you are correct that many merchants prefer having a separate sequential reference number for customer facing and accounting purposes, which is why there are extensions built specifically for this workflow.

As far as WooCommerce core goes, there is currently no native feature for separate sequential order numbers, but feature requests and discussions around this have come up over time. If you would like to formally suggest or support this as a core enhancement, you can submit it here: https://woocommerce.com/feature-requests/

Thanks again for taking the time to share your thoughts and detailed feedback around this.