The CachePilot beta is open. Join the beta for free

From 19 to 15 modules: the history of CachePilot

From 19 to 15 modules and from 54,500 to 24,250 lines: how CachePilot was started in February 2026 and rebuilt in three days in November 2026.

Five versions of one plugin page stacked behind each other on a dark grid, the newest in front with an orange button

CachePilot started in February 2026, paused for most of the year and was rebuilt between 2 and 4 November 2026. In those three days the code base shrank from about 54,500 to 24,250 lines, the modules went from 19 to 15, and five releases from 1.1.0 to 1.4.1 followed. The repository holds 58 commits from the first one to the module review of 4 November.

How did CachePilot develop?

  1. The start

    First commit with plugin version 1.0.2, 19 module folders, 204 tests and a Docker stack with WordPress 6.7, PHP 8.3, Redis 7 and MariaDB 11.

  2. A new structure

    The plugin moves to plugin/, the development tools to dev/. Core, Autopilot and the modules are slimmed down in several passes.

  3. 1.1.0 and 1.2.0

    Caches that saved no work are removed. The page cache serves pages through advanced-cache.php before WordPress loads.

  4. 1.3.0 and 1.4.0

    Page cache rules for shops and the cart, then a CSS and JS minify module.

  5. 1.4.1

    Zero-config setup, safety check, weekly report, a new admin and a German translation.

Why was CachePilot rebuilt?

After the first two commits on 9 February 2026 the repository saw no commits until 2 November. When work resumed, a review showed that much of the code did not pay its way. Some modules cached data that WordPress or the plugin in question already kept cheaply, so they added Redis traffic without saving database work. There was a second Redis layer next to the drop-in, and the page cache did not actually serve cached pages. The decision was to keep only what measurably saves work.

Which modules were removed, and why?

Of the 19 module folders of February, 15 modules remain. Five went, one is new:

  • Elementor, Jetpack and Yoast SEO: removed in 1.1.0 because their caches did not save any work.
  • TLS: TLS to Redis is part of the core settings now, with certificate verification switched on by default.
  • Autopilot: no longer a module but part of the core, so it can act on every module.
  • Minify: new in 1.4.0.

The remaining modules are ACF, Admin Bar, Cache Groups, Debug, Minify, Multisite, Options, Page Cache, Statistics, Transients, WCML, WooCommerce, WordPress Core, WPML and WP Rocket. Version 1.1.0 also removed the REST API endpoints and made the modules run on frontend, REST and AJAX requests, so cache invalidation works for Gutenberg saves and WooCommerce checkouts as well.

What did each release of the rebuild add?

1.1.0: half the code, the same features

About half of the code base was removed without losing features. Options are kept in a single Redis hash that the drop-in maintains, and the admin works without jQuery and without external fonts.

1.2.0: pages before WordPress

The page cache serves cached pages through advanced-cache.php, before plugins and theme load. Autopilot switches it on when no other page cache plugin is active. A bug in the prefetch, which recorded only part of the keys a page uses, was fixed. Details are on the page cache page.

1.3.0: rules for shops

Filter, sort and variation parameters enter the cache key, tracking parameters are ignored, the cart fragments of an empty cart are cached, and purges cover pagination, archives, terms and translations. Visitors with a filled cart get cached pages, while pages rendered for them are never stored. The guide Page cache and WooCommerce explains these rules.

1.4.0: minify without combining

The CSS and JS Minify module serves minified copies of local files, built with wikimedia/minify 2.12.0 (Apache-2.0). Files are not combined: with HTTP/2 and HTTP/3 separate files load in parallel and stay cached one by one, so a change to one file does not invalidate a bundle.

1.4.1: no setup needed

Zero-config setup, a safety check that withdraws Page Cache or Minify when they break a page, the weekly report, a redesigned admin and a German translation. The release post for 1.4.1 covers it.

What comes next?

CachePilot is in a free beta for businesses. Testers download the plugin from their account and get updates through the CachePilot update server. Join the beta, or read how the plugin compares in the benchmarks.

Sources

  • Git history of the CachePilot repository: 58 commits from 6735cf9 (9 February 2026) to f75199d (4 November 2026); no commits between e67d913 (9 February) and 7e77d76 (2 November).
  • Commit 1e46739, 3 November 2026: move to plugin/ and dev/.
  • Commits 8d84955 (1.1.0), 5696f83 (page cache before WordPress, 1.2.0), cb65350 (1.3.0), 9dabd17 and 0ff5da7 (wikimedia/minify 2.12.0, 1.4.0), 46829a1 (1.4.1).
  • plugin/readme.txt, changelog entries 1.1.0 to 1.4.1.
  • Line count of the code base before the rebuild (about 54,500) and on 4 November 2026 (24,250).

Related articles

  • The CachePilot mark, an open white circle with an orange dot, next to a column of five switches, three of them switched on in orange

    CachePilot 1.4.1: zero-config Autopilot

    CachePilot 1.4.1 finds Redis on activation and starts Autopilot without a wizard. New: safety check, weekly report, redesigned admin, German translation.

  • A server rack on a dark grid connected to six separate instance boxes, one per customer; the first box and its line are orange

    CachePilot Server for ISPConfig

    CachePilot Server for ISPConfig 1.0.0 and 1.1.0: customers create their own Redis instances in the panel, with passwords, limits and live figures.

  • A web page on a dark grid sends a request to a stack of cache slots; one slot is orange and an orange arrow carries the answer back to the page

    CachePilot: the start

    CachePilot is a Redis object cache for WordPress that configures itself. Its first commit in the current repository, 6735cf9, is dated 9 February 2026 and…