WP Super Cache writes static cache files into two parallel folders. The supercache mode stores plain HTML under wp-content/cache/supercache/<host>/<path>/, served directly by Apache or Nginx without invoking PHP. The legacy wp-cache mode stores serialized cache files under wp-content/cache/wp-cache-<hash>.html, served by PHP for logged-in or commented users. The preload schedule lives in wp_options under the wp_cache_preload_* keys and walks the sitemap on a fixed cron interval. The default Cache Contents screen surfaces a Delete Cache toggle and a file count, which works on a small site and hides every interesting detail the moment a preload run stalls.

SleekView Kanban reads the same supercache and wp-cache folders the Cache Contents screen scans. A derived wpsc_state field buckets URLs by whether a supercache HTML file exists, whether the preload schedule has the URL queued, whether the file age is past the configured TTL, and whether the URL is in the rejected URI list. Card fronts can show the URL path, the supercache file size, the file modification time, the wp-cache fallback flag, and the preload position so a developer can spot stale or skipped pages without leaving the board.

Dragging a card between columns calls the WP Super Cache helper functions. A move from Stale back to Uncached deletes the supercache file and re-queues the URL for the next preload tick. A move from Preloading back to Uncached cancels the in-flight cron task. The plugin's automatic purge on post save keeps running, so a manual board action never collides with the plugin's normal cache invalidation flow on disk.

WP Super Cache has been the default cache plugin for years on shared hosts and budget VPS deployments. The plugin works because it stays simple. A static HTML file lives next to the URL it serves, and the web server hands it back without ever calling PHP.

The simplicity is what makes the plugin reliable, and the simplicity is what makes it hard to operate at scale. A single Delete Cache toggle hides the fact that only a small subset of URLs is stale. A preload position counter hides the fact that one URL is wedged on a slow third-party include and the run never finishes.

The team relearns these blind spots every time a launch goes badly. A kanban board flips that around. Every URL is a card.

Every cache state is a column. A glance at the board tells the team how many URLs are uncached, how many are mid-preload, how many are stale past their TTL, and which paths dominate each group. Dragging a card writes the change back to disk through the same helper functions the cron task already trusts.

The Delete Cache toggle still exists, and still works as a last resort. The board exists for the rest of the time, when the team needs to see the cache the way a cache plugin already sees it.