LovingBro (woo-hc)

Hi @pederb6, thanks for reaching out, I can see how confusing it is when the order edit page loads blank while still showing the sidebar and allowing some input there, let’s work through this together.

I checked your message, and it looks like the screenshot of the error didn’t come through on my end. Could you please try sharing it again so I can take a closer look?

You can upload the screenshot using https://snipboard.io and paste the link here. That will help me better understand what’s happening on your site and guide you more accurately.

Hi @jlkogut, thanks for reaching out, I can see how concerning it is to have past-due Action Scheduler tasks increasing over time, especially when everything else appears to be set up correctly, let’s work through this together.

From the report you shared, I can see that WP-Cron is enabled and running, and Action Scheduler itself is active and up to date, which is a good starting point. However, the presence of past-due and pending actions usually indicates that some scheduled tasks are either getting delayed, stuck, or blocked from completing.

Here are a few steps you can take to narrow this down and resolve it:

First, please check the scheduled actions directly by navigating to: Tools → Scheduled Actions or WooCommerce > Status > Scheduled Actions. Look at the “past-due” and “failed” actions, click into a few of them, and check the logs for any recurring errors. This can help identify if a specific plugin or task is causing the backlog.

Next, try running pending actions manually using the “Run” button at the top of the Scheduled Actions page. If they execute successfully, that suggests WP-Cron may not be triggering frequently enough.

Since WP-Cron is dependent on site traffic, you may want to set up a real server cron job to trigger it more reliably. This guide walks through how to do that: https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-scheduler/

Additionally, I can see a few plugins that rely heavily on scheduled actions, such as Cart Abandonment Recovery and PDF Invoices. It would be helpful to perform a plugin conflict test to rule out any interference:

• Temporarily deactivate all plugins except WooCommerce
• Switch to a default theme like Storefront
• Check if new actions are still becoming past-due

You can follow this guide for steps: https://woocommerce.com/document/how-to-test-for-conflicts/. If the issue stops, reactivate plugins one by one to identify the culprit.

Also, clearing out old failed actions can sometimes help improve performance. There is a guide here:
https://actionscheduler.org/admin/

If after these steps the issue persists, please share a few example logs from the failed or past-due actions. You can use https://pastebin.com or https://gist.github.com to share them.

Once we identify what’s holding those tasks up, we’ll be in a much better position to resolve it fully.

Hi @pacman94, thanks for sharing the system report, I can see you’ve got a fairly complex setup with quite a number of active plugins and customizations, so you’re definitely on the right track isolating this.

Given that the Klarna widget isn’t rendering even on the standard checkout and the payment intent is being created, this strongly points to something on the frontend blocking the Stripe element from mounting, most commonly a plugin or theme conflict. Looking through your setup, there are quite a few plugins that can interact with checkout behavior or scripts, such as FunnelKit, Elementor, checkout field editors, caching, and optimization tools

At this stage, the most important next step is to run a full plugin conflict test to narrow this down:

• Temporarily switch to a default theme like Storefront or Twenty Twenty-Four
• Deactivate all plugins except WooCommerce and WooCommerce Stripe Gateway
• Test the checkout with Klarna enabled

If Klarna works in this minimal setup, then:

• Reactivate plugins one by one, testing each time
• This will help identify the exact plugin causing the conflict

If the issue still persists even with only WooCommerce and Stripe active, let me know, as that would point us in a different direction. You can follow this guide for a safe conflict test, ideally on staging:
https://woocommerce.com/document/how-to-test-for-conflicts/

Also, since you’re running caching and optimization tools like WP Rocket and Redis, it would be good to clear all caches after each change, or temporarily disable them during testing to avoid stale scripts interfering. Once you’ve had a chance to run this test, share your findings and we’ll take the next step together.

Hi @adalov,

Thanks for sharing these details, I can see how important this is, especially with the Checkout event affecting your verified merchant status, and it is great that you were able to restore the other events after reconnecting the account.

Since the Checkout event is still not firing, even after reconnection and confirming settings, this usually points to something interrupting the event trigger during the checkout flow rather than a configuration issue.

A few things to check next:

1. Confirm checkout completion flow
   The Pinterest “Checkout” event is typically triggered on the order received or thank you page. Please confirm that customers are reaching the order confirmation page successfully after payment.
2. Plugin or theme conflict test
   There may be a conflict preventing the event from firing. Kindly run a full conflict test:

• Temporarily switch to a default theme like Storefront
• Disable all plugins except WooCommerce and Pinterest for WooCommerce
• Place a test order and check if the Checkout event fires

You can follow this guide:
https://woocommerce.com/document/how-to-test-for-conflicts/

3. Caching or optimization layers
   If your site uses caching, CDN, or optimization plugins, they can sometimes prevent scripts from firing correctly on the checkout or thank you page. Try clearing all caches and, if possible, temporarily disabling optimization features for testing.
4. Check for duplicate or missing tags
   If there are any additional Pinterest tags added manually or via another plugin, they could interfere with the default tracking. Ensure only the Pinterest for WooCommerce integration is handling the events.
5. Logs and system details
   To take a closer look, please share your System Status Report via https://pastebin.com or https://gist.github.com so we can review your setup further.

If after the conflict test the Checkout event starts working, that will help pinpoint the exact cause and we can guide you further from there.

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

Hi @jethrohazelhurst,

Please share the URL of one moisturiser product that shows the warning, and a screenshot of that product’s data details in WooCommerce, including the Google for WooCommerce section. Once I see how the data is stored on your site, I will advise the exact place to add the unit pricing measure and base measure.

Hi @raunharmantech,

Thanks for clearly outlining what’s happening here, I can see how the extra trailing zeros in prices like x.00000 would incorrectly flag products as “On Sale”, especially when there’s no actual sale price set. That can definitely cause confusion across your catalog, so let’s work through a scalable way to fix this.

From what you’ve described, this is likely happening because WooCommerce treats even slight differences between regular price and sale price values as a valid sale condition. So entries like 100 vs 100.00000 can unintentionally trigger the “On Sale” status.

Since you have many products and are using WPML, the best approach would be to correct this in bulk rather than manually editing each product. Here are a few options you can consider:

1. Bulk edit via CSV export and import
   You can export your products, clean up the price formatting, and re-import:
   • Go to Products → Export
   • Open the CSV file and normalize the Regular price and Sale price columns by removing unnecessary decimal zeros
   • Re-import via Products → Import
   Guide here: https://woocommerce.com/document/product-csv-importer-exporter/
2. Database-level update (advanced option)
   If you’re comfortable working with the database or have developer support, you can run a query to normalize price meta values in bulk. This is faster but should be done with a backup in place.
3. WPML consideration
   Since you’re using WPML, ensure that:
   • Price fields are synchronized across translations
   • After cleanup, run WPML troubleshooting tools to sync product data across languages
   WPML guide: https://wpml.org/documentation/getting-started-guide/
4. Double-check for hidden sale prices
   Some products might still have a sale_price meta value stored even if not visible in the UI. Bulk cleanup should ensure both regular and sale prices match correctly or remove unintended sale values.

If you’d like, you can share a sample of your product export via https://pastebin.com or https://gist.github.com, and I can help review the formatting before re-importing.

Once this cleanup is done, your “On Sale” products list should reflect only the intended discounted items. Let me know how it goes or if you’d like help with any of the steps above.

Hi @merome,

Thanks for sharing the update and the log, I can see you’ve already done solid troubleshooting using Health Check and clearing cache, that really helps narrow things down.

Looking through the log you shared , the key thing that stands out is that your site is generating a large number of PHP deprecated notices, mostly coming from plugins like The Events Calendar, Event Tickets, and a few others. These are typically related to PHP versions issues.

While these notices are not fatal errors, they can interfere with AJAX requests and API responses, which is exactly what the WooCommerce dashboard inbox relies on. This can explain why the Inbox is not loading.

Here are the next steps I recommend:

1. Update all plugins and your theme
   Make sure everything is fully up to date, especially:
   • The Events Calendar
   • Event Tickets
   • Flexible Shipping
   • Any other plugin mentioned in the log
2. Temporarily disable The Events Calendar and related plugins
   Even though you tested with plugins disabled, try specifically:
   • Disable only those plugins showing in the log
   • Then reload the WooCommerce dashboard
     This helps confirm if one of them is breaking the inbox requests
3. Check your PHP version
   If you’re running PHP 8.2, try switching to PHP 8.3 or 8.4 temporarily to see if the issue resolves, as some plugins are still catching up with full compatibility
4. Enable WP_DEBUG_LOG (without display)
   This helps capture cleaner logs without breaking responses:
   https://wordpress.org/documentation/article/debugging-in-wordpress/
5. Re-test WooCommerce Admin after cleanup
   Once deprecated notices are reduced or removed, the dashboard inbox should start working again

If the issue persists after these steps, feel free to let us know. Looking forward to your findings 👍

Hi @2chicks,

Really appreciate you sharing this update, and it’s great to hear you were able to track this down to a conflict with the WooCommerce Anti Fraud plugin. That’s a solid find, and reaching out to their support team is definitely the right next step to get that behavior addressed at the source.

Since the conflicting plugin has now been identified, I’ll go ahead and mark this thread as resolved. That said, you’re always welcome to return here if anything comes up related to this, or feel free to open a new topic if you run into a different issue, we’ll be happy to help.

Your feedback helps other merchants better understand what to expect and can make a big difference for those deciding to use the plugin, we’d really appreciate it if you could take a moment to leave a review for the WooCommerce Stripe Payment Gateway: https://wordpress.org/support/plugin/woocommerce-gateway-stripe/reviews/#new-post

Thanks again for working through this with us 🙌