WP Cache Autopilot – Documentation

Supported Integrations

Updated:

Integration Design Philosophy

WP 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 Gutenberg structural content like templates, template parts, synced patterns, navigation, and global styles – so layout changes refresh the correct pages automatically.

Zero config.

Gutenberg support is considered first-class because these structures directly affect frontend rendering across multiple pages.

What is supported

  • Block-based pages and posts
  • Template parts (wp_template_part)
  • Site editor templates (wp_template)
  • Synced patterns (wp_block)
  • Nested block chain such as: synced pattern inside template part inside template used by posts. Updating that pattern refreshes any post that contains any of these 3.
  • Navigation structures (wp_navigation)
  • Global style updates

How it works

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

Design principle

Structural editor changes affect layout, not individual URLs. Cache Invalidator prioritizes correctness over guesswork when resolving their impact.

Elementor

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

Zero config.

Supports both modern Elementor Components (Atomic editor) and legacy Global Widgets.

What is supported

Elementor content

  • Pages and posts built with Elementor
  • Public custom post types using Elementor

Reusable Elementor documents

  • Components (Atomic editor)
  • Global widgets
  • Template widgets

Templates

  • Templates (like headers, popups, sections, loop items)
  • Archive templates
  • Single templates
  • Conditional templates

Clear Files & Data detection

When Elementor’s Clear Files & Data is triggered, Cache Invalidator treats this as a full site-level change:

  • Elementor clears generated CSS, assets, and internal caches
  • No information about affected pages is provided
  • Cache Invalidator performs a global invalidation
  • Cache Warmup rebuilds the full site cache in the background

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

How it works

Cache Invalidator understands how Elementor content is connected and refreshes only the pages actually affected by a change:

  • Detects when you edit reusable Elementor content (reusable components, global widgets, templates)
  • Finds all pages where that content is used
  • Refreshes only those pages instead of clearing the entire cache
  • Automatically refreshes affected pages even when reusable Elementor content is nested inside other templates or global widgets.
  • Falls back safely if relationships 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)

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 pages.

Set up with just a few clicks.

This ensures customers always see correct product data across the storefront.

What is supported

  • Shop page refreshes automatically
  • Product updates refresh the product page automatically
  • Upsells and cross-sells refresh related products
  • Grouped products refresh their parent product
  • Product variation changes refresh the parent product
  • Product category archives refresh when products change
  • Product tag archives refresh when products change

How it works

When a product changes:

  • Related products are detected automatically
  • Product categories and tags are resolved
  • Affected product archives and taxonomies are included
  • A precise list of affected URLs is generated
  • Only those pages are invalidated and warmed again

This keeps your shop accurate without clearing the entire cache.

Advanced Woo setups

Most WooCommerce shops require no configuration.

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

WP 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. WP 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 cache plugin and uses its adapter for purge (clear cache) operations.

Cache plugin requirements

WP Cache Autopilot relies on targeted cache invalidation. To work correctly, the cache plugin must support purging specific URLs.

This allows the system to apply 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 based on post IDs. These approaches cannot reliably invalidate all affected pages, especially when relationships or structural content are involved.

For this reason, only cache plugins with direct URL-level purge support are included.

Supported cache plugins

Supported cache plugins — including free options — provide this capability:

All listed integrations support the required URL-level purging.

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 behavior such as regeneration or full cache clearing. This can leave stale content active or cause unnecessary cache rebuilds.