Cloudflare Integration Deficiency

Submitted via: LiteSpeed support ticket / Hostinger escalation channel
Date: 2026-06-04
Plugin version: LiteSpeed Cache 7.8.1
WordPress version: (current)
Hosting: Hostinger Cloud Starter (LiteSpeed Web Server, PHP 8.3) Summary

LiteSpeed Cache’s Cloudflare integration does not purge Cloudflare’s edge cache when individual WordPress pages or posts are updated. The integration exists in the plugin UI, accepts credentials, and gives no indication that it is not functioning. The only documented behavior — a zone-wide “purge everything” triggered only on LiteSpeed’s own “Purge All” action — is not disclosed, and is not what any reasonable operator would expect from a “Cloudflare integration.”

The practical result for end users: after publishing or updating a post in WordPress, visitors continue seeing the previous version of that content for the duration of Cloudflare’s edge cache TTL (in our case, 2 hours). The LiteSpeed cache is purged correctly. Cloudflare is not notified. There is no error, no warning, and no log entry. The plugin silently fails to do what its UI implies it will do. Technical Detail

LiteSpeed Cache’s Cloudflare purge logic is contained in a single method:

/src/cdn/cloudflare.cls.php → purge_all_private()

This method calls:

DELETE /zones/{zone_id}/purge_cache
{"purge_everything": true}

It is invoked only from _purge_all() in purge.cls.php, and only when the option litespeed.conf.cdn-cloudflare_clear is explicitly enabled — a secondary setting that is not enabled by default and is not prominently surfaced in the setup flow.

There is no per-URL purge. There is no hook into WordPress’s save_post, publish_post, or any post-lifecycle event that would trigger a targeted Cloudflare cache invalidation when content changes. The Cloudflare API supports per-URL purging natively ({"files": ["https://example.com/post-slug/"]}), and this capability is simply unimplemented.

The consequence in a standard LiteSpeed + Cloudflare configuration:

1. Visitor requests a page → CF edge cache miss → LiteSpeed serves it → CF caches the response
2. Editor updates the post → LiteSpeed purges its server cache for that URL → no Cloudflare notification
3. Next visitor requests the same page → CF serves stale cached content → LiteSpeed is never consulted
4. Stale content persists until the CF TTL expires

This is not a configuration error. It is a missing feature presented as a working integration. Impact

This issue affects any site using LiteSpeed Cache with Cloudflare where:

• Cloudflare caches HTML responses (which it will, given LiteSpeed’s public, max-age headers)
• Content is updated with any frequency

Hostinger bundles LiteSpeed Cache by default and actively recommends Cloudflare to its customers. This means the combination that produces the deficiency is precisely the combination Hostinger’s onboarding guides lead customers into. What Was Required to Resolve It

A custom WordPress mu-plugin was written to intercept save_post and call the Cloudflare API directly, purging the post URL, homepage, and blog archive on each publish/update event. The plugin reads its credentials from LiteSpeed’s own database options to avoid duplication.

This is functionality that belongs in the plugin itself — not in every site owner’s custom code. Requested Actions

1. Implement per-URL Cloudflare cache purging triggered on save_post / publish_post, using the same credentials already stored in LiteSpeed’s options. The Cloudflare API endpoint is DELETE /zones/{zone}/purge_cache with a files array.
2. Enable cdn-cloudflare_clear by default when Cloudflare credentials are saved, or at minimum surface it prominently in the setup flow with a clear explanation of what “Purge All” does and does not cover.
3. Add documentation clarifying the scope of the current integration — specifically, that it does not purge Cloudflare on individual post updates. Sites where content accuracy matters deserve to know this before they ship.