A PHP error naming a SiteGround helper function is different from a page that loads successfully but stays stale. Capture the exact symptom before changing cache lifespan, disabling optimization or repeatedly purging the whole site. Each action addresses a different part of the delivery path.
Match the function and its caller
WP Rocket's compatibility change in pull request 9048 restores deprecated wrappers for four SiteGround helpers: rocket_get_sg_optimizer_version, rocket_is_supercacher_active, rocket_clean_supercacher and rocket_sg_clear_cache. The wrappers delegate to the newer integration and are conditional on the SG Optimizer plugin being active. Their absence on a site without that integration is not itself a broken installation.
The WP Rocket changelog places the related SiteGround work in 3.24. Confirm the installed vendor package and the private error's caller path. A custom plugin that assumes a hosting helper always exists needs its own compatibility review. Do not paste replacement function definitions into production or activate an unrelated hosting plugin merely to suppress a fatal error.
Preserve a redacted stack trace, the active plugin versions and the operation that triggered the error. If the administration screen cannot load, use the host's supported recovery procedure to isolate the named caller while accounting for its other responsibilities. A cache purge is not a repair for a PHP declaration or undefined-function failure.
Inventory the cache owners
WP Rocket's Speed Optimizer guidance explains the hosting integration and cache-clearing synchronization. Review it against the actual installed configuration. Keep one row each for page HTML, optimized CSS and JavaScript, object caching and any CDN. Record which product creates each artifact and which supported control invalidates it.
Do not assume a familiar plugin button owns every layer. Equally, two installed performance plugins do not prove every feature is duplicated. Compare the enabled functions. Test overlapping script or style transformations separately from HTML caching, because a minified asset problem can survive an otherwise successful page-cache purge.
Follow content from WordPress through the host and edge caches; a successful button click does not prove every layer is fresh. Explanatory diagram.
Use a harmless freshness marker
On staging, place a unique, non-sensitive marker in an ordinary public page. Record its original value, then change it through the normal editor. Check the direct page as a signed-out visitor and record the returned marker and response headers. Use the host's documented cache diagnostic controls when available rather than guessing header meanings.
If the public page is stale, apply one documented purge and recheck. Keep the same URL and browser conditions so the comparison has meaning. Record whether the WordPress response, host cache or edge delivery first differs from the approved marker. Do not put credentials into query strings to bypass a cache, and do not bypass the site's access controls.
Then perform the test in the other supported purge direction if your integration promises synchronization. A successful message in the dashboard proves that a control ran, not that every visitor now receives the new HTML. Inspect the response itself. Keep a separate test for changed CSS or JavaScript, which may use a different URL and lifetime.
Distinguish freshness from rebuild load
| Observation |
Investigate next |
| Undefined helper in a PHP fatal |
Caller assumptions, active integration and supported package |
| Page returns successfully with an old marker |
Specific HTML cache layer and purge propagation |
| New content but broken styling |
Asset generation and overlapping optimization |
| Fresh content with repeating CPU spikes |
Purge frequency and rebuild workload |
For the last case, use the existing WP Rocket cache lifespan and CPU-cycle guide. Shortening lifespan is not a universal freshness fix and can increase regeneration work. For a queue that never advances, follow preload troubleshooting instead of bulk-deleting queued work.
Close with a bounded result
Acceptance requires a fresh representative page, the expected assets, no new matching PHP error and an ordinary interactive workflow that still succeeds. Repeat after a normal content edit, not only immediately after manually clearing everything. Keep the original configuration available for rollback.
HandL WP can diagnose the hosting integration from the sanitized caller trace, cache-owner inventory and marker results. The useful conclusion names the failing layer and verified behavior. It does not simply say that caching was turned off and the symptom disappeared.
Sources reviewed November 2, 2026. Examples and diagrams are diagnostic aids, not customer test results.