Poonam Namdev

Hi @temovision,

Great, let us know if you still face any issues.

Hi @temovision,

Thanks for the screenshot! The “Background Tasks: Overdue” warning means that some scheduled background jobs (like cache preloading or cleanup) have been queued but haven’t run in over an hour. This is separate from cache writes — so your cache is still being updated, but these background tasks are sitting idle.

This is almost always a WordPress Cron issue. Here’s how to fix it:

1. Check if WP-Cron is disabled – Open your wp-config.php and look for:

define('DISABLE_WP_CRON', true);

If this line exists, WP-Cron is disabled and you’ll need a real server cron to replace it.

2. Set up a server-side cron job – Replace the unreliable WP-Cron with a true server-level cron. You can ask your hosting provider to set up a real cron.

3. If you don’t have server cron access – Remove or comment out DISABLE_WP_CRON from wp-config.php to re-enable the default WP-Cron behavior.

After making the change, the warning should clear on the next dashboard load once the pending jobs run. If it persists, you can go to Tools → Scheduled Actions in your WordPress admin to see exactly which jobs are stuck.

Let us know if you have other questions.

Hi @mktekboss,

Thank you for reporting this issue. We’ve forwarded it to our development team for further investigation.

Could you please let us know the plugin you are using for Wholesale Prices integration? It will help us in debugging the issue.

• This reply was modified 2 days, 9 hours ago by Poonam Namdev.

Hi @momo-fr,

Thank you so much for the kind words! We’re really glad to hear the conditional display options are helping and we truly appreciate your support.

Hi @glonojake,

Could you please go to Super Page Cache → Settings → Advanced Settings and look for this option: Automatically purge Cloudflare’s cache when something changes on the website

If the Purge whole cache option is enabled, that’s likely the culprit. When this setting is turned on, publishing any post triggers a full cache purge meaning every page on the site, including older posts from 2001, gets cleared from the cache at once.

Please disable this option and enable Purge cache for related pages only instead.

If this option is already disabled and you are still facing this issue then please let us know so we can debug further.

Hi @nickabela,

Thanks for the detailed write-up. To be upfront: this specific stack (PPOM + WooCommerce Subscriptions + a third-party Discount Rule plugin) isn’t a combination we’ve formally tested, so I can’t promise a perfect outcome but I can point you in the right direction.

PPOM doesn’t currently expose a dedicated “skip this product ID” toggle or filter, and it isn’t subscription-aware out of the box, which is the root of what you’re seeing: at the cart stage PPOM reads the product’s current price (already modified by your Discount Rule plugin) and writes it back as the line total, which clashes with how Subscriptions splits sign-up fee vs. recurring price.

PPOM provides a filter hook called ppom_cart_line_total specifically designed for this kind of scenario. It is the last point in PPOM’s pricing pipeline before the final price is written, making it the correct and safest place to intervene.

Using this filter, a developer can:

• Identify the specific subscription product(s) by their Product ID
• Instruct PPOM to skip its price override for those products
• Allow WooCommerce Subscriptions to retain full control over the recurring price display

This requires a small custom code snippet added via your theme’s functions.php or a site-specific plugin. We recommend involving a developer to implement this, as the exact logic will depend on your specific product IDs and setup.

​Let us know if we can help with anything else.

Hi @rrose1311,

The 403 Forbidden error from the Facebook Sharing Debugger means Facebook’s crawler is being blocked at the server level when it tries to fetch your page — this is unrelated to the Revive Social plugin itself.

A few common causes to check:

1. Security plugin blocking Facebook’s crawler — Plugins like Wordfence, or Sucuri may be rate-limiting or blocking external bots. Check your firewall/bot protection rules and whitelist Facebook’s user agent (facebookexternalhit).

2. Hotlink protection — If your host has hotlink protection enabled (via .htaccess or cPanel), it can block external services from fetching your images. Add an exception for Facebook’s crawler.

3. CDN or Cloudflare rules — If you’re behind Cloudflare or another CDN, a firewall rule or security mode may be blocking the scrape. Try temporarily pausing the CDN and running the Sharing Debugger again to see if that’s the cause.

4. robots.txt — Make sure your robots.txt isn’t accidentally disallowing Facebook’s crawler.

To confirm the issue is server-side: go to https://developers.facebook.com/tools/debug/, paste your URL, and click “Scrape Again.” If you still get a 403, it’s definitely a hosting/server configuration issue rather than the plugin.

Let us know what you find and we can help further!

Hi @luislu,

Thanks for reaching out! This is a great use case. Currently, Super Page Cache does not automatically purge the Cloudflare cache when an image is deleted or re-uploaded with the same filename. Cache purging is primarily triggered by post/page updates rather than media library changes.

As a workaround in the meantime, you can manually purge the specific image URL from your Cloudflare dashboard, or use the plugin’s “Clear All Cache” option after replacing an image.

That said, this is a worthwhile feature request — automatically detecting media deletions/replacements and purging the corresponding CF cache URLs would be very helpful for teams managing frequently updated assets. I’ve forwarded this for consideration in a future update.

​Let us know if we can help with anything else.