{"banners":{"high":"https://res.cloudinary.com/demo/image/upload/c_fill,w_1544,h_500/sample.jpg","low":"https://res.cloudinary.com/demo/image/upload/c_fill,w_722,h_250/sample.jpg"},"requires_php":"7.0","version":"1.5.7","last_updated":"2026-10-18 18:51:50","slug":"404-litespeed-fallback","sections":{"installation":"Click the activate button to install.","changelog":"1.5.7 — 18 October 2026
\n\t\t\n\t\t - Update offers now appear even when the site cannot reach WordPress.org.
\n\t\t
\n\n\t\t1.5.6 — 18 October 2026
\n\t\t\n\t\t - Purge-on-404 now honours the JS/CSS fallback toggles. The missing-bundle handler used to mark the response uncacheable and run the configured purges (including LiteSpeed Purge All) before checking the toggles, so with both fallbacks off any request for a missing
/litespeed/ bundle still purged the whole cache and then returned a normal 404. The marking and purges now run only when a fallback is actually served for that asset type, matching the inline catcher and the 1.5.1 design (server-side purge happens via the 307 route). With the relevant toggle on, behaviour is unchanged. The CSS-disabled 410 stays uncacheable but no longer purges. \n\t\t wp ls404fb health no longer reports the inline catcher as OK when LiteSpeed Cache is inactive: it now shows idle (LiteSpeed Cache inactive) as INFO, leaving the existing LiteSpeed Cache ERROR row to set the exit code.
\n\n\t\t1.5.5 — 18 October 2026
\n\t\t\n\t\t - Background auto-updates now work (WP-cron, WP-CLI and Easy Updates Manager), plus updater robustness fixes.
\n\t\t
\n\n\t\t1.5.4 — 18 September 2026
\n\t\t\n\t\t - The missing-bundle handler now runs at
template_redirect priority 0 instead of the default 10. Multilingual plugins (TranslatePress, WPML, Polylang) hook the same action at 10 but from an earlier init, so they were answering first: a missing bundle is not a file on disk, so they treated the URL as a page and 301’d it to the language-prefixed form, costing a second full WordPress boot before the fallback could respond. On one measured site that was 3.4 s for the stylesheet route and ~4.8 s of “Loading…” on screen before the reloader fired — the visitor-visible grey-screen-then-redirect. The handler now answers on the first boot; the route is one boot plus a static file. \n\t\t - The 307 (and the CSS-disabled 410) are now explicitly uncacheable. They were leaving with the page-cache plugins’ normal headers (
s-maxage=345600 from Super Page Cache; public,max-age=3600 tagged HTTP.404 from LiteSpeed Cache), so a cached redirect became the edge’s answer for that bundle URL even after the bundle was regenerated. The handler now sends Cache-Control: no-store, no-cache, must-revalidate, max-age=0 and X-LiteSpeed-Cache-Control: no-cache, calls litespeed_control_set_nocache, and re-asserts both headers at send_headers / wp_headers priority PHP_INT_MAX, and — the part that actually closes the window — now exits after sending the redirect. Previously it fell through to WordPress’s normal shutdown, which is where a later callback could replace the Location and where the page-cache plugins stamped their headers. Verified on the wire against a TranslatePress-style redirect using WordPress’s real hook engine: 1.5.3 left with s-maxage=345600, 1.5.4 leaves with no-store. LiteSpeed Cache’s X-LiteSpeed-Tag: HTTP.404 is set before the handler runs and still appears; it is inert once X-LiteSpeed-Cache-Control: no-cache is present. \n\t\t - Documented which healing path actually fires: where the
.htaccess routing block is present every hop returns 200, so the inline catcher’s resource-error listener never fires and the 307 route is the whole story; the catcher only acts where a bundle 404s outright at the server. Both reloader stubs now publish window.ls404fb (asset, route, start time) as their first statement, so timing and available fields are identical whichever route delivered them. \n\t\t - Confirmed, no change needed: since 1.5.3 the Cloudflare-bypass check reads only
cf_fallback_cache_excluded_urls on Super Page Cache ≥ 5.1 and only cf_excluded_urls on ≤ 5.0. \n\t\t
\n\n\t\t1.5.3 — 17 September 2026
\n\t\t\n\t\t - Cloudflare-bypass detection is now version-aware. Super Page Cache’s rule builder reads
Constants::SETTING_EXCLUDED_URLS, and that constant changed value in 5.1.0: on ≤ 5.0.12 it is cf_excluded_urls (a separate cf_fallback_cache_excluded_urls exists there but only governs the local disk cache), on ≥ 5.1.0 the two lists were merged into cf_fallback_cache_excluded_urls. 1.4.4 read the latter unconditionally, which on ≤ 5.0 reported “ok” when only the disk-cache list held *LSCWP_CTRL=NOCACHE* while Cloudflare still cached the reload. The health check, the two notices and the settings deep link now all key off the same version test and can no longer disagree. The blob-wide sweep and guessed option names from earlier releases are removed, since on old SPC they re-create the false positive. \n\t\t - Heads-up from the investigation: SPC ships no migration for this rename, so a bypass configured on ≤ 5.0 silently stops being honoured after upgrading to 5.1+ until
*LSCWP_CTRL=NOCACHE* is re-added in the new field. The notices will flag exactly that. \n\t\t
\n\n\t\t1.5.2 — 17 September 2026
\n\t\t\n\t\t - Fixed the Cloudflare-bypass notices’ deep link on Super Page Cache 5.1 and later, where it produced WordPress’s “Sorry, you are not allowed to access this page.” SPC 5.1.0 moved its settings from a Settings submenu (
wp-cloudflare-super-page-cache-index) to a top-level menu (super-page-cache-settings) and reworded the exclude-list field from “Prevent the following URIs to be cached” to “…from being cached”. Both notices now ask WordPress which page is actually registered (falling back to the SWCFPC_VERSION constant, which first appeared in 5.1.0), link to the right one — with #general on 5.1+ so it lands on the tab holding the field — and quote the field label the admin will actually see. Verified against the wp.org source for 4.7.13 through 5.3.5. The legacy link is byte-identical to before. \n\t\t - The dashboard-wide notice now uses the same compact one-link sentence as the settings-page banner, and both drop the “loop-guard” jargon in favour of plain wording.
\n\t\t
\n\n\t\t1.5.1 — 4 September 2026
\n\t\t\n\t\t - Inline catcher is now a detector only. Instead of carrying its own copy of the reload logic, the inline trigger (≈1.2 KB, most of it the two absolute asset URLs) hot-loads the plugin’s canonical reloader (
public/js/critical-fallback.js, or critical-fallback-force-styles.js when CSS fallback + “wait for CSS” are on — the same variant selection the 307 route uses, now shared via ls404fb_fallback_js_url()). One reloader implementation, the force-styles behaviour is preserved, no reload logic lives in cached HTML, and reloader fixes take effect on the next incident without waiting for edge-cached HTML to expire. If the reloader itself fails to load, the trigger performs a bare loop-guarded cache-bypass reload so the page is never stranded. \n\t\t - Removed the beacon telemetry and the
/wp-json/ls404fb/v1/dead-bundle REST endpoint introduced in 1.5.0. The plugin now sends nothing anywhere; server-side purge-on-catch happens only via the worker.php 307 route (best-effort on LiteSpeed Cache 7.9+). \n\t\t - Hardened both reloader stubs for running before
<body> exists (the dead bundle tag in <head>): they now target <html> until <body> is parsed, and their last-resort fallback keeps the visitor on the same path + hash instead of bouncing to the homepage. This latent bug also affected the existing 307 path on sites that don’t defer JS. \n\t\t - The force-styles stub no longer hard-codes a version for its CSS URL (it had been stuck at
?ver=1.1.7): the trigger passes a versioned URL, and on the 307 path it derives the URL from the dead bundle’s own ?ver=. It also injects whatever CSS it gets rather than abandoning the reload on a failed fetch. \n\t\t
\n\n\t\t1.5.0 — 4 September 2026
\n\t\t\n\t\t - New primary healing mechanism: an inline catcher. LiteSpeed Cache 7.9+ seeds
wp-content/litespeed/.htaccess with a STATIC_PROTECT_V2 block that hard-404s missing bundles at the web-server layer, and rewrites that file (strict byte-equality) from File::save() on every write under the static folder with no hook — so any routing block the plugin adds is wiped within seconds on a busy site and the 307-to-stub path never fires. The catcher sidesteps this entirely: a ~700-byte data-no-optimize script injected at the top of <head> (via litespeed_buffer_finalize, with a wp_head fallback for Optimax snapshots) listens for resource-load errors on /litespeed/(js|css)/ bundles and performs the same hide → ?LSCWP_CTRL=NOCACHE → reload with the same loop-guard, needing no server routing at all. Honours the JS/CSS toggles in Basic Settings; default on; new toggle under Self-Heal Settings. \n\t\t - Added a hardened public beacon endpoint
POST /wp-json/ls404fb/v1/dead-bundle that the catcher pings via sendBeacon, so a caught dead bundle still runs the configured LiteSpeed / Cloudflare purges for everyone (the second half of the original worker design). Only acts on /litespeed/(css|js)/ paths that are genuinely absent on disk; path-sanitised; per-(IP, asset) throttle of 120 s and a site-wide purge-storm guard of one purge per 60 s. \n\t\t - Demoted the
.htaccess self-heal to supplementary (kept for the Toolbox direct-URL 307 verification, non-JS clients and pre-7.9 LiteSpeed), and made it hold up better on 7.9+: a frontend heartbeat on wp and shutdown re-applies the block within the same request a wipe happened in, gated on a single stat() (mtime + size) so an unchanged file costs nothing; LSCWP hook priorities raised to PHP_INT_MAX; writes stay tmp+rename so they succeed even when the file is locked. \n\t\t - Defense in depth: a dashboard-wide
notice-warning (and a matching wp ls404fb health row and settings-page pill state) now flags when the LiteSpeed STATIC_PROTECT seeding is present but wp-content/litespeed/.htaccess is still writable, advising chmod 444. Locked, LiteSpeed’s file_put_contents() wipe fails while the plugin’s rename-based update still works. The plugin advises only — it never changes permissions on the operator’s behalf (a locked file also blocks LiteSpeed’s own rare template bumps, which the health check surfaces). \n\t\t - Docs honesty: the Self-Heal Settings section now states plainly that both layers are safety nets, that the
.htaccess route races an auto-generated file, and that the durable fixes are hosting-side (edge TTL below origin TTL; JS/CSS Combine off). Pages cached before 1.5.0 won’t carry the catcher until they expire. \n\t\t
\n\n\t\t1.4.4 — 4 September 2026
\n\t\t\n\t\t - Followed up on 1.4.3’s Cloudflare-bypass detector fix — the truly correct SWCFPC key is
swcfpc_config['cf_fallback_cache_excluded_urls'] (the exclude list that actually feeds the Cloudflare page rule), not cf_excluded_urls (a different list SWCFPC keeps for other purposes). 1.4.3’s false-positive therefore persisted on any site with *LSCWP_CTRL=NOCACHE* correctly excluded. Now checks the CF-feeding key first, then cf_excluded_urls, then the broader swcfpc_config sweep, then the legacy option keys. \n\t\t
\n\n\t\t1.4.3 — 4 September 2026
\n\t\t\n\t\t - Fixed a false-positive in the Cloudflare bypass detector that flagged every SPC site as unconfigured regardless of truth.
ls404fb_verify_cloudflare_bypass() was reading the wrong option keys (swcfpc_cache_settings, swcfpc_settings) — SWCFPC actually stores its Cloudflare exclude list at swcfpc_config['cf_excluded_urls']. Now reads the correct key first, then falls back to a broader sweep of swcfpc_config (for future key renames), then the legacy keys (for pre-swcfpc_config installs). This silences the dashboard-wide notice-error and the CLI health ERROR on sites that already had *LSCWP_CTRL=NOCACHE* correctly excluded. \n\t\t
\n\n\t\t1.4.2 — 4 September 2026
\n\t\t\n\t\t - Cloudflare Super Cache bypass-missing warning now shows as a dashboard-wide
notice-error across every admin page (except the plugin’s own Settings page, where the inline banner already surfaces it), so admins can’t miss the config gap that silently defeats the reload trick. Non-dismissible — the notice only clears when *LSCWP_CTRL=NOCACHE* is actually added to the SPCFC bypass list. Restricted to users with manage_options. \n\t\t
\n\n\t\t1.4.1 — 4 September 2026
\n\t\t\n\t\t - Replaced the naive
DISABLE_WP_CRON warning with a real liveness check. Every self-heal cron pulse now stamps ls404fb_selfheal_last_check; the health report compares that timestamp against the 15-minute interval and emits OK within 2× the interval, WARNING within 4×, ERROR beyond that — regardless of whether WP-Cron is native or a server-side ticker is hitting wp-cron.php. Added overdue detection on the queued run time too: if wp_next_scheduled returns a timestamp significantly in the past, the event is queued but nothing is dispatching it. DISABLE_WP_CRON is now an INFO config note, not a warning — it’s the correct setup on many fleets. \n\t\t
\n\n\t\t1.4.0 — 4 September 2026
\n\t\t\n\t\t - Added a WP-CLI command surface:
wp ls404fb init bootstraps the plugin state (schedules the self-heal cron, applies the .htaccess patch, migrates the legacy purge-option key), wp ls404fb health prints a table of every integration check (LiteSpeed Cache active + version, Cloudflare Super Cache + LSCWP_CTRL=NOCACHE bypass, self-heal toggle, target file writability, marker block state, drift, last-applied time, next cron, WP-Cron enabled, purge-option migration state, purge-on-404 wiring, fallback toggles, debug webhook, update endpoint reachability) with pass/warn/error rows and a matching exit code, and wp ls404fb apply force-re-applies the .htaccess patch on demand. Supports --format=json|csv|yaml and --strict. \n\t\t
\n\n\t\t1.3.1 — 4 September 2026
\n\t\t\n\t\t - Ensured the 15-minute self-heal cron is (re-)scheduled on settings save, on the Plugins screen, on the WordPress Dashboard, and on this plugin’s own Settings page — so in-place upgrades from 1.2.x that don’t re-run activation still pick up the cron. Toggling the Self-Heal switch now also unschedules the cron immediately when turned off. All calls are idempotent.
\n\t\t
\n\n\t\t1.3.0 — 4 September 2026
\n\t\t\n\t\t - Resurrected the 404 reload trick against newer LiteSpeed Cache releases, whose auto-generated
wp-content/litespeed/.htaccess (marker LSCACHE_STATIC_PROTECT_V2) short-circuits missing bundle requests at the web-server layer before WordPress can see them. The plugin now prepends its own marker block above LiteSpeed’s that routes missing js/css/ucss/ccss files back to index.php, and re-applies the patch on litespeed_purged_all, litespeed_purged_all_cssjs, litespeed_update_confs, plugin upgrades, admin page loads (mtime-guarded), and a 15-minute cron backstop. \n\t\t - Added a new Self-Heal Settings section with a default-on toggle and a live status pill (Patched & Watching / Waiting for LiteSpeed / Patch Missing / File Not Writable / Self-Heal Disabled) plus a hover tooltip showing the target file, writability, marker state, drift flag, last-applied timestamp, and next cron sweep.
\n\t\t - Fixed a long-standing typo in the purge-on-404 handler (
ls404fb_puging_settings → ls404fb_purging_settings) that silently ignored the Purging Settings toggles since the plugin’s original release. Adds a one-time migration so existing installs don’t need to re-save. \n\t\t - Replaced the generic “check your Cloudflare Super Cache config” nag with an active health check that reads SPCFC’s stored options and shows a green success banner when
LSCWP_CTRL=NOCACHE is on the bypass list, or a red error banner when it isn’t. \n\t\t
\n\n\t\t1.2.5 — 6 June 2026
\n\t\t\n\t\t - Slimmed the guard status tooltip to just the trigger conditions (LiteSpeed Cache + CSS Combine / Load CSS Async / Generate UCSS), and added an info icon to the chip to signal the tooltip.
\n\t\t
\n\n\t\t1.2.4 — 6 June 2026
\n\t\t\n\t\t - Guard status chip now uses the same
<code> styling and spacing as the SPC Purge / LiteSpeed Purge status chips, with added amber (needed but off) and grey (not needed) states. \n\t\t
\n\n\t\t1.2.3 — 6 June 2026
\n\t\t\n\t\t - Streamlined the Repair CSS Combine status display to a single inline \"Guard Needed / Guard Not Needed\" pill (green = needed and on, red = needed but switched off, grey = not needed), with the full per-condition breakdown moved into a hover/focus tooltip. Presentation only — the runtime gate is unchanged.
\n\t\t
\n\n\t\t1.2.2 — 6 June 2026
\n\t\t\n\t\t - Repair CSS Combine now self-disables at runtime when its preconditions aren't met (LiteSpeed active with CSS Combine, Load CSS Async, or Generate UCSS on) — skipping the per-tag and full-buffer work on sites that don't need it.
\n\t\t - Added a live status panel under the toggle showing each precondition's state and whether the guard is Active, Dormant, or Disabled on this site.
\n\t\t
\n\n\t\t1.2.1 — 6 June 2026
\n\t\t\n\t\t - Added a \"Repair CSS Combine\" toggle under a new Other Settings section (on by default) so the Combine Guard + Catcher can be switched off without deactivating the plugin.
\n\t\t
\n\n\t\t1.2.0 — 6 June 2026
\n\t\t\n\t\t - New \"Combine Guard + Catcher\" feature (on by default): works around a LiteSpeed Cache 7.2–7.8.1 bug (lscache_wp#999) where older WordPress cores render the dummy CSS <link> with a double space, defeating LSCWP's combine regex and dropping the combined stylesheet (naked, CSS-less page). The Guard collapses the dummy tag's whitespace so combine injects normally; the no-cache Catcher refuses to cache any page where the dummy placeholder survived.
\n\t\t
\n\n\t\t1.1.9 — 20 November 2022
\n\t\t\n\t\t - Added support for cases where no LiteSpeed JS is loaded but only CSS: user now sees warning to manually refresh the page.
\n\t\t
\n\n\t\t1.1.8 — 21 September 2022
\n\t\t\n\t\t - Fixed improperly-scoped fallback processing.
\n\t\t - Added resilience against WordPress Admin being targeted for fallback CSS handling.
\n\t\t
\n\n\t\t1.0.1-1.1.7 — 16 July 2022
\n\t\t\n\t\t - Bug fix compatibility with our other plugins.
\n\t\t - Allows for always-showing Loading message.
\n\t\t - Added cache-busting versioning to CSS and JS assets.
\n\t\t - Improved cache-proof verification prompts in plugin Toolbox.
\n\t\t
\n\t\n\t\t1.0.0 — 8 August 2022
\n\t\t\n\t\t - Initial release.
\n\t\t
","description":"Provides a dynamic fallback for 404-missing JS/CSS LiteSpeed-optimized assets. Inspired by Autoptimize's 404 fallback."},"author_profile":"https://profiles.wordpress.org/harryfear","name":"404 Fallback for LiteSpeed","requires":"4.8","author":"Harry F.","download_url":"https://plugins.skydesignltd.com/repos/404-litespeed-fallback/latest/404-litespeed-fallback.zip?ver=1.5.7","tested":"7.1"}