//Web Panel

Master LSCache: Custom WebAdmin Rules for Any CMS

Set up LiteSpeed WebAdmin rules to cache custom CMSs. Learn to define TTL, exclude dynamic URLs, and automate purges for optimal speed.

5 min read
Master LSCache: Custom WebAdmin Rules for Any CMS

LiteSpeed Cache (LSCache) is a server‑level caching solution that works out of the box with popular CMS platforms such as WordPress and Joomla. For custom or less‑common CMSs that lack a native LSCache plugin, you can still obtain the same performance gains by creating custom WebAdmin rules. These rules tell LiteSpeed exactly how to cache, purge, and serve your pages.

Why Use WebAdmin Rules for Non‑Standard CMSs?

WebAdmin rules give you fine‑grained control over LiteSpeed’s caching behavior without requiring a dedicated plugin. They let you:

  • Define which URLs should be cached or excluded.
  • Set a cache TTL (time‑to‑live) based on content type.
  • Automatically purge the cache when content changes via API calls or webhook scripts.
  • Handle cookies, query strings, and request methods that your custom CMS relies on.

All configuration is done in the LiteSpeed WebAdmin console, so the rules are applied at the web‑server level and work for any PHP, Node.js, Python, or static‑site generator you may be using.

Prerequisites

Before writing rules, ensure you have:

  1. A running LiteSpeed Enterprise or OpenLiteSpeed server with LSCache enabled.
  2. Administrative access to the LiteSpeed WebAdmin UI (default URL: https://your-server-ip:7080).
  3. Root or sudo privileges on the server to edit configuration files if needed.
  4. Basic knowledge of your CMS’s URL structure, cache‑able endpoints, and how it invalidates content (e.g., via a webhook or CLI command).

Step 1 – Identify Cache‑able and Dynamic URLs

Map the routes your CMS serves. Typical patterns include:

  • Static assets: /assets/*, /images/*
  • Public pages: /blog/*, /products/*
  • Admin or API endpoints that must stay dynamic: /admin/*, /api/*

Record these patterns; you’ll reference them when creating Cache Rules and Purge Rules in the WebAdmin UI.

Step 2 – Create a Basic Cache Rule

Log in to the WebAdmin console and navigate to Cache → Cache Rules. Click Add and fill in the fields as shown.

Rule Settings

  • Name: CustomCMS_PublicPages
  • URI Pattern: /blog/* (replace with your own pattern)
  • Cache TTL: 3600 seconds (1 hour – adjust as needed)
  • Ignore Cookies: 0 (set to 1 if your pages set non‑essential cookies)
  • Vary By Query String: 0 (enable if query parameters affect output)

Save the rule. LiteSpeed will now cache any request matching /blog/* for one hour.

Step 3 – Exclude Sensitive or Dynamic Content

Not everything should be cached. Create an Exclude Rule for admin panels, login pages, or API calls.

Example Exclude Rule

  • Name: CustomCMS_Admin
  • URI Pattern: /admin/*
  • Cache Control: no-cache

This tells LiteSpeed to bypass the cache for any URL under /admin/, ensuring authenticated users always see fresh content.

Step 4 – Set Up Automatic Purge Triggers

When content changes, the cached copy must be invalidated. LSCache supports purge via HTTP requests, which you can trigger from your CMS after a publish, update, or delete operation.

Creating a Purge Rule

In the WebAdmin UI, go to Cache → Purge Rules and add a new rule:

  • Name: CustomCMS_PurgeBlog
  • URI Pattern: /blog/*
  • Purge Method: GET (or POST if you prefer)

From your CMS, issue an HTTP request to the built‑in purge endpoint whenever a blog post is modified. The request format is:

curl -X GET "https://your-domain.com/purge?tag=CustomCMS_PurgeBlog"

If your CMS runs on the same server, you can use a local script. Below are example scripts for Debian/Ubuntu (apt) and AlmaLinux/Rocky/RHEL (dnf). Place the script in /usr/local/bin/lscache-purge.sh and make it executable.

Debian / Ubuntu (apt) Script

# Ensure curl is installed
sudo apt update
sudo apt install -y curl

# Purge function
purge_blog() {
    local url="https://localhost/purge?tag=CustomCMS_PurgeBlog"
    curl -k -s "$url"
}

# Execute the function (your CMS can call this script)
purge_blog

AlmaLinux / Rocky / RHEL (dnf) Script

# Ensure curl is installed
sudo dnf install -y curl

# Purge function
purge_blog() {
    local url="https://localhost/purge?tag=CustomCMS_PurgeBlog"
    curl -k -s "$url"
}

# Execute the function (your CMS can call this script)
purge_blog

Explanation of commands

  • sudo apt update / sudo dnf install -y curl – installs the curl utility needed for HTTP requests.
  • curl -k -s "$url" – sends a silent HTTPS GET request to the purge endpoint, ignoring self‑signed certificates (-k) and suppressing progress output (-s).

Step 5 – Test and Verify Your Rules

After configuring cache, exclude, and purge rules, run a quick test to confirm the expected behavior.

Testing a Cache Hit

# First request – should be a cache miss
curl -I https://your-domain.com/blog/sample-article

# Subsequent request – should show "X-LiteSpeed-Cache: hit"
curl -I https://your-domain.com/blog/sample-article

Look for the header X-LiteSpeed-Cache: hit on the second request. If you see miss, double‑check the URI pattern and TTL.

Testing a Purge

# Trigger purge (simulate a CMS publish)
curl -X GET "https://your-domain.com/purge?tag=CustomCMS_PurgeBlog"

# Request the page again – should be a miss after purge
curl -I https://your-domain.com/blog/sample-article

The header should revert to miss, indicating the cached copy was cleared.

Advanced Tips for Complex CMS Setups

Non‑standard CMSs often have nuanced caching needs. Consider these enhancements:

  • Vary By Cookie: If your site personalizes content based on a specific cookie (e.g., language or theme), enable Vary By Cookie and list the cookie name.
  • Cache By Query String: For pages that change based on query parameters (e.g., /search?q=term), enable Vary By Query String and specify the allowed parameters.
  • Edge Side Includes (ESI): Use ESI tags in your HTML to cache the bulk of a page while keeping small dynamic fragments (such as a logged‑in user’s name) uncached.
  • Conditional Purge via API: If your CMS provides a webhook, configure it to call the LiteSpeed purge endpoint directly, eliminating the need for a local script.

All of these options are available under Cache → Advanced Settings in the WebAdmin UI.

Conclusion

Even without a native LSCache plugin, you can achieve fast, reliable caching for any custom or lesser‑known CMS by leveraging LiteSpeed’s WebAdmin rules. Identify URLs that are safe to cache, explicitly exclude dynamic routes, and automate purges whenever content changes. By following the steps above—and adapting the patterns to your site’s structure—you’ll unlock the performance benefits of server‑level caching while keeping your custom application fully functional.

litespeed cachewebadmin rulescustom cms cachinglscache configurationcache purgeweb server performanceopenlitespeedurl caching

Try it on your own server

Follow along on a Cloud VPS with full root access, or read the step-by-step knowledge base guides.

Guides: VPS for WordPress · Node.js hosting · VPS or dedicated server · Paying by UPI