WP Cache Autopilot – Documentation

Use Cases

Updated:

How to Use This Page

WordPress sites are built in different ways — different builders, different field plugins, different content structures. Cache invalidation behavior depends on that stack, so this page is organized by feature rather than by a single site type.

Most sites will recognize themselves in more than one section. That is expected. Start with the section that matches your primary setup, then check any others that apply.

Operator tip:
After installing both plugins and completing the Getting Started checklist, use this page to fine-tune behavior for your specific stack. These sections can also be shared directly when answering support questions — each one has a stable anchor link.

Gutenberg Block Theme Site

Gutenberg structural awareness is built in and active by default.

Applies to

Sites with a block-based theme (Full Site Editing) using synced patterns, template parts, site editor templates, and global styles.

Configuration needed

None.

Operator tip:
Menu and navigation changes are covered by the Navigation updates toggle in Cache Invalidator → Settings → Theme & UI Surface. It is enabled by default.

See: Supported Integrations → Gutenberg for what is resolved automatically.

Elementor Sites

Elementor structural awareness is built in and active by default.

Applies to

Sites built with Elementor, using reusable components, global widgets, theme builder templates, or archive templates.

Configuration needed

None.

Operator tip:
Both modern Elementor Components (Atomic editor) and legacy Global Widgets are supported. No difference in setup.

See: Supported Integrations → Elementor for what is resolved automatically.

WooCommerce Store

Applies to

Sites using WooCommerce with a product shop page and archive pages.

Configuration needed

A few clicks.

How to configure Product relationships

  1. Go to Cache Invalidator → Settings → Post Type Tabs and enable the Product post type.
  2. Enable archive/category/tag options inside the Product tab if you want product archive, product category, and product tag pages refreshed too.
  3. Save.

See: Supported Integrations → WooCommerce for the full list of what is resolved automatically.

Relevant Filters

For custom product relationships (bundles, custom product references not covered by built-in WooCommerce fields): add a meta key filter to extend relationship resolution.

See: Developer Reference → ekesto_ci_relationship_meta_keys for custom relationship configuration.

ACF Relationship Fields

Applies to

Sites where one post type references another via ACF relationship or post_object fields — for example, Events referencing Venues, or Articles referencing Authors.

Configuration needed

A few clicks per relationship.

This is the one area that requires deliberate setup — the system needs to know which content types are connected on your site.

How to configure ACF relationships

  1. Go to Cache Invalidator → Settings → Post Type Tabs and enable the host post type that hosts (the post type doing the referencing).
  2. Open the tab for the host post type and locate the Content Relationships panel.
  3. Add a relationship: select the related post type.
  4. Save.

When the related post type changes, Cache Invalidator follows the relationship and refreshes the correct host pages automatically.

Relationships are directional.
Define them from the content doing the displaying toward the content being referenced. Example: Event → Venue (not Venue → Event).

Example: Events and Venues

An Event post type has an ACF relationship field pointing to a Venue. When a Venue is updated, Cache Invalidator follows the relationship in reverse — finds all Events referencing that Venue — and refreshes those event pages.

The same logic applies to deeper chains.

Country → Venue → Event → Pages: updating a Country propagates through the full chain and refreshes every affected page.

Operator tip:
Start with your most important relationship and verify it end-to-end before adding more. Edit a referenced post, then check the Cache Warmup log for a targeted warmup run showing the expected URLs.

Supported field types: relationship, post_object — single and multiple references. Also works inside group, repeater, and flexible_content containers where fields are directly stored.

See: Supported Integrations → ACF for field type details, nested structure support, and async deep traversal behavior.

See: Cache Invalidator → Content Relationships for the settings reference.

Classic Themes

Applies to

Sites using a traditional PHP theme — widget areas, classic menus, the Customizer, PHP templates with the classic editor.

Configuration needed

Default settings cover most cases. Widget-to-page mapping requires a filter for precise targeting.

Relevant toggles

All enabled by default in Cache Invalidator → Settings → Theme & UI Surface and Patterns & Widgets:

  • Menu changes — purges cache when a menu or menu location is modified
  • Customizer changes — purges cache when Customizer settings are saved
  • Widget changes — purges cache when widgets or sidebar layouts are modified; falls back to configured target pages when specific widget-to-page mapping is unavailable

See: Cache Invalidator → Theme & Archive Changes for the full settings reference.

Relevant filters

ekesto_ci_widget_selectors

Maps specific widget sidebars directly to pages. When defined, only those pages are invalidated on widget change — no fallback needed. Disable the fallback toggle once mapping is in place.

ekesto_ci_widget_template_mappings

Maps widget sidebars to classic page templates. When a mapped sidebar changes, all published pages assigned to that template are invalidated.

Pages and Posts Only

Applies to

Sites using only the built-in WordPress page and post types. No custom post types, no WooCommerce, no ACF relationships.

Configuration needed

Minimal.

  1. In Cache Invalidator → Settings → Post Type Tabs, enable the Post Post Type.
  2. Set Target Pages to the pages that display that content — typically your homepage and blog listing page, or any page that contains e.g. the Query Loop block.
  3. Enable Archive Targets → Taxonomy archives if you use category archive pages.
  4. If your posts use Tags, then you may want to enable Propagation Behvaior → Include tags (post_tag).

See: Cache Invalidator → Post Types Tab for more details.

Operator tip:
Add your homepage and any listing pages as priority pages in Cache Warmup → Priorities so they are warmed first after every purge cycle.

Custom Post Type Sites

Applies to

Sites with one or more custom post types — Events, Team Members, Projects, Properties, or similar — that appear on listing pages, archive pages, or embedded inside other pages.

Configuration needed

Enable each custom post type in Cache Invalidator and define which pages should refresh when it changes.

  1. In Cache Invalidator → Settings → Post Type Tabs, enable the custom post type.
  2. Open its tab and set Target Pages to the pages that display this content — listing pages, the homepage if relevant, any archive pages.
  3. Enable Archive Targets if the post type has a post type archive (e.g. /events/) or taxonomy archives (e.g. /event-category/conference/).
  4. If your posts use Tags, then you may want to enable Propagation Behvaior → Include tags (post_tag).
  5. If individual posts of this type display other posts of the same or other types (for example, a “latest events”, “related events” section on an event detail page), enable Additional Post Type Targets to invalidate all singular pages of that type on change.

See: Cache Invalidator → Post Types Tab for the full settings reference including archive targets and additional post type targets.

Operator tip:
Configure one post type end-to-end and verify it in the Cache Warmup log before moving to the next. Incremental setup is easier to debug than configuring everything at once.

Optional: Define ACF realtionships

If your custom post types reference each other via ACF fields, see the ACF Relationship Fields section.

Multilingual Site

Applies to

Sites running a supported multilingual plugin with content in more than one language.

Configuration needed

None for detection. One setting to review for fanout behavior.

This section is an overlay — it applies on top of whichever other sections describe your site. A multilingual WooCommerce site built on Elementor should follow those sections first, then review this one.

Default behavior

Cache Invalidator detects your active multilingual plugin automatically and includes translated URLs during invalidation. No resolver configuration is required.

  • When a post changes, only the translations of that post are refreshed
  • When a global change fires — menus, widgets, Customizer — all language variants are refreshed

If your translated pages share layout elements or listing pages that must stay in sync across languages after a post edit, enable Post-trigger multilingual fanout in Cache Invalidator → Settings → Multilingual Fanout.

Operator tip:
Enable Support Debug Mode and make a test edit to verify that translated URLs appear in the invalidation log alongside the primary language URL.

See: Supported Integrations → Multilingual Compatibility for supported plugins and how each translation model is handled.

See: Cache Invalidator → Multilingual Support for fanout policy settings.

Large Sites

Applies to

Sites with houndres or thousands of published pages, large product catalogs, or complex content structures where invalidation scope and editor performance matter.

Configuration needed

Deliberate targeting. The defaults that work on small sites can create unnecessary load at scale.

  1. Use Selected pages as the Target Mode for every post type. Avoid All pages and Purge all cache — at scale, these touch thousands of URLs on every content change.
  2. Enable Async execution in Cache Invalidator → Settings → Invalidation Behavior. This offloads relationship resolution to background processing so editor save times stay fast regardless of how many relationships need to be followed.
  3. Configure Priority Pages in Cache Warmup → Priorities for your highest-traffic landing pages so they are warmed first in every cycle.

Operator tip:
When making multiple changes that trigger full cache clears (e.g. menus), pause Cache Warmup and re-enable it when done. This avoids unnecessary work and is available from any admin page via the WP admin bar.

Operator tip:
Timed invalidation is useful for content updated on external schedules (event feeds, stock data).

See: Cache Invalidator → Invalidation Behavior for async deep invalidation configuration.

See: Cache Warmup → Batch Execution and Pacing for warmup rate and priority configuration.