Visual Rules Builder

Every caching decision in MilliCache is a rule. MilliCache ships a full rules engine, but writing rules requires PHP. The Rules module adds a Rules tab to your settings screen where you build, edit, and reorder rules visually. No code, no deployment.

Open it at Settings → MilliCache → Rules.

What a Rule Looks Like#Copied!

A rule combines three things:

  1. Conditions: when does this rule apply? Match by URL, cookie, query parameter, request method, user role, or any of the WordPress conditionals such as is_singular or is_search.
  2. Match type: whether all, any, or none of the conditions must match.
  3. Actions: what happens when it matches. All caching actions from the engine are available, such as setting a custom TTL, bypassing the cache, or adding flags.

Rules run in order (1 to 999, default 50), so a later rule can refine or override an earlier one. Drag rules in the list to reorder them; only the moved rule's order number changes.

Example rules you can build in a minute (see Examples below):

  • Do not cache any URL under /members/
  • Use a 5-minute TTL for your /news/ section
  • Bypass the cache when a currency cookie is present
  • Split the cache into separate variants by request header, such as Markdown and HTML versions of the same page

Built-in Rules and Overrides#Copied!

The list also shows the rules MilliCache and its extensions register in code, read-only and visually separated (toggle their visibility in the table's appearance settings). You can override any unlocked built-in rule: the builder creates an editable copy under the same rule ID, and your version shadows the original. An "Overrides" badge marks such rules so it stays obvious which behavior is yours.

A few critical built-in rules are locked and cannot be overridden; they protect things that would break the site if cached (see Built-in Rules).

Available Conditions#Copied!

The condition picker is a searchable, grouped list built from the MilliRules engine:

  • Request conditions: URL, query parameters, cookies, headers, request method, and more (see the conditions reference)
  • WordPress conditionals: is_singular, is_single, is_page, is_archive, is_home, is_front_page, is_search, is_404, is_feed, is_category, is_tag, is_tax, is_author, is_date, is_post_type_archive, is_paged, is_attachment, is_user_logged_in, is_preview, is_customize_preview, is_page_template, is_embed, is_robots
  • Content conditionals: has_block, has_blocks, has_post_thumbnail, has_excerpt, has_tag, has_term, has_category, has_nav_menu, has_post_format
  • Choice-based conditions with prefilled options: post type, post status, user role, request method, and WordPress environment type

Developers can add further is_*/has_* conditionals to the picker via the millicache_rule_builder_conditionals filter.

Examples#Copied!

Each example lists what you pick in the rule editor. Text values support wildcards: * matches anything, ? matches one character, and /regex/ switches to a regular expression.

Never Cache a Members Area#Copied!

Condition Request URL is */members/*
Action Set Cache Decision, with Should Cache off and a reason like Members area

The reason shows up in the debug headers, so you can always see why a page was not cached.

Short TTL for a News Section#Copied!

Condition Request URL is */news/*
Action Set TTL to 300 seconds

Fresh content expires after five minutes while the rest of the site keeps the default TTL. When several rules set a TTL, the rule with the higher order wins.

Condition Cookie currency exists
Action Set Cache Decision, with Should Cache off

Visitors who picked a currency see live pages; everyone else keeps getting cached ones. If the personalized output is itself cacheable per currency, a bucket (next example) is the better tool: it keeps caching on and gives each currency its own entry.

Separate Buckets for Markdown and HTML (Accept Header)#Copied!

Sites that serve AI agents a Markdown representation of their pages (for example with a content-negotiation plugin that responds to Accept: text/markdown) need the cache to keep both representations of the same URL apart. Buckets do exactly that:

Condition Request Header, with Header Name Accept and value *text/markdown*
Action Set Bucket, with Bucket Name format and Token md

Requests preferring Markdown are cached in their own format=md bucket, while browsers keep hitting the regular HTML entry. Both entries live under the same page context and carry the same flags, so publishing an update invalidates the HTML and Markdown copies together instead of letting them drift apart.

The same pattern covers any header- or cookie-based variant: A/B test arms, currencies, consent states. One Set Bucket action per variant dimension, and the Entries browser shows the resulting variants per page.

Note: Rules built purely from request conditions (URL, header, cookie, query, method) run in MilliCache's early phase, before WordPress even loads, exactly like the built-in bypass rules. Rules that use WordPress conditionals naturally run once WordPress is available, so they cannot influence decisions made earlier. Locked built-ins, such as the REST API bypass, cannot be overridden either way.

Multisite: Network and Site Rules#Copied!

On multisite the Rules tab exists in both places:

  • Network Admin rules apply to every site in the network. Network administrators can mark a rule (or a single action inside it) as locked, which prevents sites from overriding it.
  • Site rules apply to one site. A site rule that reuses the ID of an unlocked network rule overrides it for that site, marked with the same "Overrides" badge.

Validation#Copied!

The builder validates before saving, inline in the editor:

  • A rule needs an ID (letters, numbers, hyphens, underscores, dots, colons) and at least one action
  • Order must be an integer between 1 and 999
  • Conditions and actions are checked by the rules engine itself, so a rule that saves is a rule that runs

WP-CLI#Copied!

Manage rules from the command line with wp millicache rules:

Command Description
wp millicache rules list List all custom rules
wp millicache rules get <id> Show one rule as JSON or YAML
wp millicache rules enable <id> Enable a rule
wp millicache rules disable <id> Disable a rule
wp millicache rules delete <id> Delete a rule
wp millicache rules export [--file=<file>] Export all custom rules as JSON
wp millicache rules import <file> [--replace] Import rules from a JSON file

Options:

  • list supports --format=table|json|csv|yaml (default: table)
  • get supports --format=json|yaml (default: json)
  • import appends and skips duplicate IDs by default; --replace replaces all existing custom rules

Examples:

 1# See what is active
 2wp millicache rules list
 3
 4# Move rules between environments
 5wp millicache rules export --file=rules.json
 6wp millicache rules import rules.json --replace

Export and import make rules portable: build them on staging, review the JSON in version control, and import them in production.

Rules in Code Still Work#Copied!

The builder complements the PHP API, it does not replace it. Rules registered in code via the MilliRules fluent API keep working and appear read-only in the list. Use code for rules that belong in version control with your theme or plugin, and the builder for everything you want to change without a deployment.

Next Steps#Copied!

Last updated: