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:
- 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_singularoris_search. - Match type: whether all, any, or none of the conditions must match.
- 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
currencycookie 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.
Bypass While a Cookie Is Present#Copied!
| 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.
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:
listsupports--format=table|json|csv|yaml(default:table)getsupports--format=json|yaml(default:json)importappends and skips duplicate IDs by default;--replacereplaces 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!
- Rules Introduction: how MilliCache rules work
- Built-in Rules: what ships by default
- MilliRules Conditions Reference: every available condition
Last updated: