Cache Autopilot – Documentation

Supported Integrations

Updated:

Integration Design Philosophy

Cache Autopilot integrates with common WordPress builders, custom fields, multilingual plugins, forms, and cache systems to ensure cache invalidation stays precise even on complex sites.

It prioritizes precise invalidation when relationships are known and safe global invalidation when they are not. This avoids stale pages without relying on risky assumptions.

Builders & Content Systems

Gutenberg

Cache Invalidator understands Site Editor content — templates, template parts, synced patterns, Navigation, and Styles — and follows how they are used through the WordPress template hierarchy. It refreshes the affected URLs when their usage can be resolved completely and safely broadens invalidation when a theme template or inherited template cannot be mapped to every page.

Zero config.

What is supported

  • Template parts (wp_template_part)
  • Site editor templates (wp_template)
  • Synced patterns (wp_block)
  • Navigation structures (wp_navigation)
  • Global style updates
  • Block-based pages and posts

Template targeting

  • Archive templates — category, tag, custom taxonomy, and custom post type archives
  • Single templates (single) — all viewable public post types
  • Post-type single templates (single-{post_type}) — all published entries of that post type
  • Slug-specific templates (single-{post_type}-{slug}) — the exact matching entry only

Nesting chain resolution

  • Full nesting chain resolved automatically: synced pattern inside template part inside template used by posts — updating any level refreshes all affected pages.

How it works

  1. Classifies structural editor entities vs public content
  2. Resolves affected frontend pages using structural relationships and template hierarchy
  3. Routes global design changes through safe global invalidation
  4. Falls back safely when structural relationships cannot be resolved

Design principle

Structural and template changes affect layout and rendering, not individual URLs. Cache Invalidator resolves exact targets where possible — archive pages, post type entries, or a single slug-matched post — and falls back explicitly when it cannot. No guesswork, no global purges where precision is available.

Elementor

PROThis feature is available in Cache Autopilot PRO.

Elementor 4.3 ready

Cache Autopilot includes deep Elementor awareness to correctly handle reusable Elementor content and Theme Builder templates without unnecessary global purges.

Zero config.

Supports both modern Elementor Components (Atomic Editor) and classic Global Widgets.

Elementor targeted cache refresh demo

What is supported

Elementor content
  • Pages and posts built with Elementor
  • Public custom post types using Elementor
Global Elementor styling
  • Atomic Default Styles (Elementor 4.3+)
Reusable Elementor content
  • Components (Atomic Editor)
  • Global widgets
  • Template widgets
Templates
  • Theme Builder site-part templates
  • Loop Item templates
    • Primary Loop templates
    • Alternate Loop Grid templates
  • Saved Templates
    • Page
    • Section
    • Container
    • Div Block
    • Flexbox
    • Grid
    • Atomic Form
  • Floating Elements
  • Popups
Supported change paths

Cache Autopilot follows Elementor’s standard save and persistence lifecycles. Changes are detected whether they originate from:

  • Elementor editor and WordPress admin
  • Elementor REST API
  • Elementor MCP (Elementor 4.3+)
  • Elementor template and Site Kit imports
  • Elementor design-system imports
Clear Files & Data and global cleanup

Cache Autopilot also detects Elementor’s global CSS and data cleanup lifecycle, including cleanup initiated through:

  • Clear Files & Data in Elementor
  • Elementor REST API cache clearing
  • Elementor WP-CLI cache flushing
  • URL replacement
  • Site Kit and design-system imports

This ensures frontend consistency even when Elementor performs non-targeted internal resets

Direct database changes or third-party tools that bypass Elementor and WordPress lifecycle APIs are not guaranteed to trigger automatic invalidation.

How it works

Cache Autopilot understands how Elementor content is reused and where Elementor templates are assigned:

  • Detects changes to Components, Global Widgets, templates and other reusable Elementor content
  • Finds pages where reusable content is used
  • Resolves Theme Builder templates through their Display Conditions
  • Handles reusable content nested inside other templates or Global Widgets
  • Refreshes the affected pages instead of clearing the entire cache
  • Falls back safely when affected pages cannot be determined

Design principle

When relationships are known, invalidate precisely.
When relationships are uncertain, fall back safely.

Additional Builder Support

Cache Invalidator includes storage-aware scanning for additional builders. This means the plugin knows where each builder stores its content and can identify which posts were built with each builder, enabling accurate form and reference resolution without unnecessary global fallbacks. Works with:

These builders do not receive the deep structural resolution that Elementor and Gutenberg get (document classification, theme builder template traversal, reusable component tracking). Their support focuses on reliable content scanning and candidate identification.

What this enables

  • Form and shortcode reference resolution scans the correct storage fields per builder
  • Candidate narrowing reduces unnecessary database queries
  • Builder metadata (builder_key, builder_confidence) is available in ekesto_ci_post_selectors filter context for custom extensions
  • Prevents unnecessary global cache purges when references are found in builder-specific storage

Custom Fields & eCommerce

Advanced Custom Fields (ACF)

PROThis feature is available in Cache Autopilot PRO.

Cache Invalidator includes native Advanced Custom Fields (ACF) awareness to follow content relationships defined through your invalidation rules.

Set up with just a few clicks.

When referenced content changes, affected frontend pages and relevant archives are invalidated precisely — without requiring broad cache purges.

This enables reliable cache freshness for structured content setups where ACF connects content across multiple levels.

What is supported

  • ACF relationship and post_object fields
  • Single and multiple references
  • Nested field structures (group, repeater, flexible_content) where relationship fields are directly stored and resolvable
  • Multi-level relationship chains (for example Country → Venue → Event → Pages)
  • Archive invalidation for the changed content where listings are affected
  • Async deep traversal for complex relationship graphs
  • Custom relationship rules for advanced data models

How it works

Invalidation rules define where changes may propagate. ACF relationships determine what is actually connected.

When content changes:

  • Relationships are resolved across configured content chains
  • Referencing content is discovered automatically
  • Archives of the changed content are included where listings are affected
  • Targets are deduplicated into one precise URL list
  • Deep traversal runs asynchronously when needed
  • Ambiguous relationships are ignored to prevent unnecessary purges

Assigning ACF Relationships for Related Content Invalidation

Cache Invalidator can automatically follow ACF content relationships to determine which pages must refresh when content changes.

In order to define a post relationship (assigning a Related Post Ttype to the Host Post Type), a Post Type first needs to be enabled in the Cache Invalidator settings. Only then can a Content Relationship be defined.

This works best when relationships reflect how content is actually used on your site — in other words, which content is shown inside other content.

Use relationships to model real content dependencies

Example:
Country → Venue → Event → Specific Pages

When a country changes, the system can propagate invalidation through the chain and refresh affected pages automatically.

Use relationship or post_object fields

Supported field types:

  • Relationship
  • Post Object
  • Single or multiple references

These provide deterministic connections the resolver can safely follow.

Keep relationships directional

Define relationships from the content being displayed to the content it references.

Examples:
Event → Venue
Venue → Country

Directional relationships allow precise invalidation instead of broad refreshes.

Avoid overly broad relationships

Very large relationship sets (for example “all posts”) may be ignored to prevent unnecessary invalidation.

Prefer precise editorial relationships instead of generic content collections.

WooCommerce

Cache Invalidator includes native WooCommerce awareness so product changes automatically refresh affected storefront pages.

Included in Cache Autopilot Free.

Set up with just a few clicks.

What is supported

  • Shop page refreshes automatically
  • Product updates refresh the product page automatically
  • Upsells refresh product pages where the changed product is displayed
  • Grouped product changes refresh their parent product
  • Product variation changes refresh the parent product
  • Product category and tag archives refresh when products change
  • Dynamic product-page content can be covered by refreshing all product singles when required

How it works

By default, Cache Autopilot keeps WooCommerce refreshes targeted.

When a product changes:

  • WooCommerce product relationships are resolved
  • Relevant product categories and tags are resolved
  • Affected product pages, archives, and taxonomies are included
  • A precise list of affected URLs is generated
  • Only those pages are purged and preloaded again

This keeps the storefront fresh without clearing the entire cache.

Product archive pagination

If you want Cache Autopilot to refresh paginated WooCommerce product archives after a product change, enable Include paginated pages under Cache Invalidator → Product → Post Type Archive.

WooCommerce block templates should use the Default query type for product archives.

This keeps standard archive pagination URLs such as:

/shop/page/2/

Cache Autopilot does not support query-based pagination URLs such as:

/shop/?query-9-page=2

These can be generated when the Product Collection block is set to Custom.

To change the number of products per archive page without switching to Custom, use WooCommerce’s Products per row and Rows per page settings. With block themes, these may only be available at:

/wp-admin/customize.php

Related Products and other dynamic product content

WooCommerce’s native Related Products section on a Product Single Template is generated dynamically. Other WooCommerce extensions can also display products on product pages in ways that cannot be predicted reliably.

If your product template contains this kind of dynamic product content, select Product under Additional Singular Post Types.

Cache Autopilot will then refresh all product single pages whenever a product changes, while the rest of the site stays cached.

If your product template does not contain dynamic product-dependent content, leave Product unselected. Cache Autopilot will continue using its targeted WooCommerce relationship resolution and refresh only the product pages it can determine are affected.

Advanced Woo setups

Most WooCommerce shops require no additional configuration.

PRO: If your shop uses custom product relationships — for example bundles or custom product references — these can be added using the developer filter:

ekesto_ci_relationship_meta_keys

Site-wide Features

Multilingual Compatibility

PROThis feature is available in Cache Autopilot PRO.

Cache Autopilot automatically detects supported multilingual plugins and includes translated URLs during invalidation so visitors always see updated content in their language.

Supported form plugins

How translation detection works

Supported multilingual plugins use different translation models. Cache Autopilot handles these differences automatically. No configuration is required.

WPML and Polylang store translations as separate posts. Cache Invalidator detects related translations and invalidates each affected page.

TranslatePress uses language-specific URLs for the same content. Cache Invalidator expands invalidation to the corresponding language URLs.

Language invalidation behavior

By default, content changes invalidate only translations of the affected content.

Global design or structural changes may invalidate all languages depending on Multilingual Fanout in Cache Invalidator settings.

Translations represent the same content in different languages. Cache Invalidator treats them as related content and keeps their cache state consistent.

Form Plugins Compatibility

Cache Invalidator detects supported form plugins and monitors form changes (create, update, delete).

When a form changes, all public post types (all public post types (page and post on a basic WP install, plus any public custom post types such as WooCommerce’s product) embedding that form are identified via shortcode and block reference scanning and invalidated automatically.

Supported form plugins

Detection behavior

Adapter detection is automatic. Only adapters whose form plugin is active are registered.

Form references are detected in:

Developer configuration

Scan scope can be modified via ekesto_ci_forms_scan_post_types.

Fallback behavior can be modified via ekesto_ci_forms_global_fallback.

Cache Adapters

Cache Invalidator automatically detects the active supported cache plugin and uses its adapter to purge the resolved target URLs.

Cache plugin requirements

Cache Autopilot relies on targeted cache invalidation. To work correctly, the cache plugin must provide a reliable way to purge specific URLs.

This allows Cache Autopilot to refresh its resolved target pages precisely, without falling back to full cache clears or indirect methods.

Some cache plugins only support clearing the entire cache or purging by post ID. These methods cannot reliably cover all affected pages, especially when shared content, relationships, or structural changes are involved.

For this reason, Cache Autopilot only includes cache plugins with usable URL-level purge support.

Supported cache plugins

The following cache plugins provide the URL-level purge capability required by Cache Autopilot:

Some integrations have plugin-specific recommendations or limitations, documented below.

Why some common cache plugins are not listed

Some widely used cache plugins do not provide a reliable way to purge individual URLs.

In those setups, cache refresh depends on indirect mechanisms such as full cache clearing or plugin-specific regeneration behaviour. This can leave stale content active or unnecessarily evict pages that did not need to be refreshed.

Cache plugin setup notes

General recommendations

These recommendations apply to page-cache expiry, purge and preload settings. Leave separate optimisation and cache features — such as object cache, CSS/JS optimisation, images and fonts — unchanged unless specifically noted for your cache plugin.

Cache lifespan

If your cache plugin automatically expires page cache after a fixed period, we recommend disabling that feature where possible — or setting a very long lifespan, such as one year.

Cache Autopilot refreshes affected pages when content changes, so a fixed cache lifetime is usually unnecessary and can cause otherwise valid cached pages to be deleted and rebuilt for no reason.

If you prefer an additional fallback, keep a longer cache lifetime instead of disabling it completely.

Preload

If your cache plugin already has a preload feature, you can continue using it instead of Cache Autopilot’s Cache Warmup.

Before relying on it, make sure the cache plugin actually preloads pages after targeted URL purges. Behaviour varies between cache plugins.

Cache Autopilot’s Cache Warmup provides a predictable alternative by rebuilding purged pages in paced background batches with its own queue, progress tracking and logs.

We generally recommend using one preload system to avoid requesting the same pages twice unnecessarily.

Automatic purge rules

If your cache plugin automatically purges additional pages when content is published or updated, consider disabling or reducing those rules.

Cache Autopilot determines which pages are affected by a change and purges those targets directly. Broad automatic purge rules in the cache plugin can cause additional cached pages to be removed unnecessarily.

Keep any native purge rules you still rely on for behaviour that Cache Autopilot does not manage.

Speed Optimizer

SiteGround Dynamic Cache Limitation

When SiteGround Dynamic Cache is enabled, purging a targeted URL may also purge descendant URLs under the same path. For example, purging /parent/ may also purge /parent/child/.

These additional server-side purges are outside Cache Autopilot’s resolved target list, so the descendant pages are not automatically preloaded.

For strict targeted cache refresh behaviour, disable SiteGround Dynamic Cache and use File-Based Cache only.