Conditions

Conditions decide where and when a snippet runs: only on product pages, only for logged-out visitors, only during a sale, only on the staging site. They're at the bottom of the settings panel.

No conditions means the snippet runs everywhere its location allows. The editor says so: No conditions: runs everywhere its location allows.

Adding conditions #

1. Click + Add condition.
2. Pick a rule from the list. Rules are grouped: Visitor, Page, WooCommerce (Pro), Date & time and Site.
3. Choose an operator (is, is not, contains, is at least…) and a value.
4. Save.

How rules combine #

Rules are arranged in groups:

• Inside a group, every rule must match. The group is headed All of these match:. Add another rule to the same group with + AND.
• Between groups, any group is enough. Start another group with + OR group.

So a snippet runs when any group matches, and a group matches when all its rules match.

Example. Show a banner to logged-out visitors on the shop page, or to anyone arriving from a Facebook ad:

• Group 1: Is logged in no · AND · Page type is WooCommerce: shop
• OR group 2: Query parameter utm_source equals facebook

Negative rules #

Most rules can be turned around with is not, does not contain, does not equal or does not exist. Use them to exclude: URL does not contain /checkout.

Conditions and timing #

Some rules can only be checked once WordPress knows enough about the request:

If you combine a rule with a location that runs too early, for example Page type with a PHP snippet on Run immediately, Snipfire tells you when you save and keeps the snippet switched off until you pick a later location. See Where snippets run.

Page rules only apply on the front end. In the admin area, a Page type or Post type rule never matches.

Most PHP snippets don't need conditions at all. If your snippet only adds hooks (add_action, add_filter), put the check inside the callback instead, where WordPress knows everything:

add_action( 'wp_footer', function () {
    if ( is_product() ) {
        echo '<p>Free returns within 30 days.</p>';
    }
} );

A rule that can't be checked never matches #

Snipfire is careful: when a rule can't be answered, it doesn't match, whether it says is or is not. Examples: a visitor's country is unknown; a rule needs WooCommerce and WooCommerce is switched off; a rule needs Snipfire Pro and Pro isn't active. A snippet is never run by accident because something couldn't be checked.

Rules that need something that isn't there stay in the snippet, so nothing is lost:

• Pro rules while Snipfire Pro isn't active (country, region, referrer, language, cookie consent given, WooCommerce cart and customer) are kept when you save, import or sync the snippet. They never match until Pro is back. The editor still shows them, with a button to remove them, and warns you when you save.
• WooCommerce rules while WooCommerce is switched off stay in the snippet, marked (not active), and don't match.

Conditions and page caching #

Rules that depend on the individual visitor (Cookie, Visitor is logged in, User role, Query parameter, Device, Referrer, Visitor country, Visitor region, the WooCommerce cart and customer rules) are checked on the server when the page is built. If your site uses a page cache, the cached page from the first visitor may be shown to everyone.

What to do:

• Most caching plugins already skip logged-in users, the cart and the checkout.
• For other pages where a visitor-dependent snippet matters, exclude them from the cache, or let the cache vary by the cookie or header involved.
• For tracking scripts that depend on cookie consent, don't use a condition: use the snippet's Cookie consent setting (Pro), which works in the browser and is cache-safe. See Cookie consent.

The editor shows a note about caching on the rules where this matters.

Next #

• All condition rules, with an example for each
• Condition recipes: common setups, ready to copy