Title: Cloudflare Integration Deficiency
Last modified: June 4, 2026

---

# Cloudflare Integration Deficiency

 *  [kenlyle](https://wordpress.org/support/users/kenlyle/)
 * (@kenlyle)
 * [3 days, 16 hours ago](https://wordpress.org/support/topic/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:
 *     ```wp-block-code
       /src/cdn/cloudflare.cls.php → purge_all_private()
       ```
   
 * This method calls:
 *     ```wp-block-code
       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.

Viewing 1 replies (of 1 total)

 *  Plugin Support [qtwrk](https://wordpress.org/support/users/qtwrk/)
 * (@qtwrk)
 * [3 days, 9 hours ago](https://wordpress.org/support/topic/cloudflare-integration-deficiency/#post-18929227)
 * generally , we’d suggest to use CF as CDN for static resources , such as IMG ,
   CSS, JS …etc , but not to cache page itself , and there are certain function 
   from our plugin would have conflict with CF page cache

Viewing 1 replies (of 1 total)

You must be [logged in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Fcloudflare-integration-deficiency%2F%3Foutput_format%3Dmd&locale=en_US)
to reply to this topic.

 * ![](https://ps.w.org/litespeed-cache/assets/icon-256x256.png?rev=2554181)
 * [LiteSpeed Cache](https://wordpress.org/plugins/litespeed-cache/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/litespeed-cache/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/litespeed-cache/)
 * [Active Topics](https://wordpress.org/support/plugin/litespeed-cache/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/litespeed-cache/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/litespeed-cache/reviews/)

 * 1 reply
 * 2 participants
 * Last reply from: [qtwrk](https://wordpress.org/support/users/qtwrk/)
 * Last activity: [3 days, 9 hours ago](https://wordpress.org/support/topic/cloudflare-integration-deficiency/#post-18929227)
 * Status: not resolved