How it works

The Cache Lifecycle

WP Cache Autopilot manages a lifecycle pipeline for every content change:

• Detection
  A WordPress or cache-plugin event fires (post save, taxonomy change, menu update, structural template changes, reusable components, presentation settings, builder updates, etc.). Cache Invalidator’s listeners classify the trigger.
• Resolution
  The system determines which cached pages are affected. This involves group matching, relationship propagation, archive resolution, structural content resolution, and multilingual fanout policy.
• Purge
  Affected cache entries are removed via the active cache adapter (when applicable).
• Emission
  A normalized result is emitted via WordPress action (targeted URLs or global invalidation).
• Intake
  Cache Warmup receives the URL list and records run intent without performing expensive preparation during editor requests.
• Preparation
  Full warmup preparation (sitemap resolution, prioritization, eligibility validation) runs asynchronously under WP-Cron to keep content operations fast.
• Warmup
  WP-Cron fires batch execution. Each eligible frontend URL receives an HTTP GET request to rebuild its cache entry.

This is a best-effort system. Cache adapter capabilities vary, WP-Cron timing is host-dependent, and sitemap membership or eligibility rules may exclude some URLs from targeted warmup.

See: Developer Reference → Architecture Overview for detailed pipeline architecture.

The Hook Bridge

The primary communication path between the plugins is the WordPress action:

do_action('ekesto_ci_invalidation_urls', array $urls, array $context);

This is the only integration point used between the plugins.

Cache Warmup may optionally reuse small pieces of Cache Invalidator logic (for example URL eligibility checks) when available, but both plugins remain fully independent and operate without shared state or required direct dependencies.

See: Developer Reference → ekesto_ci_invalidation_urls for detailed pipeline architecture.

Targeted Warmup vs Full Warmup

The system produces two distinct warmup behaviors:

Targeted warmup — Triggered by Cache Invalidator when specific content changes. Only affected frontend-eligible URLs are warmed. This is the primary operating mode during normal content editing.

Full warmup — Triggered when a global invalidation is emitted (e.g. cache-plugin full clear or manual action). Warms all planned URLs from configured sitemaps after asynchronous preparation.

When a targeted warmup arrives during an active full warmup, Cache Warmup preserves it for priority treatment. Targeted URLs are buffered during preparation and merged near the current processing position once the full warmup queue is materialized.

Operates on a best-effort basis, influenced by your specific setup and environment.

See: Troubleshooting → Known limitations