Hi @and4zej, Robey here. I’m the product manager for WP-Optimize. Thanks for taking the time to write this up. A couple of your points describe behaviour we’d treat as critical if reproduced, and the rest I think we can clear up. Let me take them one at a time.
WP-Optimize fails to fully de-register its components even when caching is toggled off in the UI. Its hooks and filters remain active on every page load […] Crucially, the “disable” toggle only stops the generation of new cache files; it doesn’t cease the plugin’s interference with WooCommerce internals.
You’re partly right, and it’s worth being precise about what’s happening. When page caching is disabled via the toggle, WP-Optimize stops serving and writing cached pages, but some hooks do remain registered. Specifically, the ones that manage:
- Purge triggers (so the plugin knows when to clear cache on content changes)
- Exclusion rules and conditional tags
- The admin UI and settings screens
That’s by design, and it’s the same pattern every major cache plugin uses, because those hooks need to be present for the plugin to respond to settings changes and purge events. What those remaining hooks should not be doing is modifying the wc-ajax=get_refreshed_fragments response. If you’re seeing evidence that they are, that’s a bug I want to see fixed, not defended.
This results in critical UI failures, such as customers seeing incorrect cart contents or random items.
This is the claim I’m taking most seriously. A cache serving one customer’s cart to another is a critical issue, and it’s not something we’ve been able to reproduce in-house or seen reported through our support channels. To investigate properly I need more than I can get from a review thread.
If you’re willing, please open a support topic at wordpress.org/support/plugin/wp-optimize and include:
- Your WP-Optimize version
- Your WooCommerce version
- Any other caching or optimization plugins active, including at the server or CDN level
- Your active theme
- The steps that produced the incorrect cart contents, ideally with a timeline
If there’s a genuine session-bleed bug here I want my team to take a look ASAP.
The “broken site” symptoms post-update are a direct result of 24-hour stale cache being served, where outdated CSS/JS assets no longer align with the updated plugin output.
Here I’d push back gently. The 24-hour figure is the default cache lifespan, which is configurable under Cache > Page cache > Cache options. More importantly, WP-Optimize purges its own page cache and minify cache automatically when the plugin updates, so visitors shouldn’t be served stale assets from us after an update completes.
If you’re seeing stale CSS or JS after an update, the usual culprits are one of the following:
- A separate minify cache from another plugin
- A CDN that wasn’t purged as part of the update
- Browser cache on the tester’s own machine
Happy to help diagnose which, if you can share a specific example.
The public support forum is the right place to take this forward, and it’s where our team actively triages reports from our users. Open a topic with the details above and we’ll pick it up from there. I’d genuinely like to get to the bottom of what you saw.
Robey
Product Manager, WP-Optimize