Cache Clearing

By clicking into the Cache Clearing Rules menu, you can configure the settings for each channel and category group. Channel Rules are only applied when a channel entry is created, updated, or deleted. Category Group Rules are only applied when a category within the group is created, updated, or deleted.

Channel Rules Settings

From the Channel Rules settings page, you can configure which items are removed from the cache based on the item key or tags when an entry from that channel is created, updated or deleted.

You can configure the tags to break, specific items to clear and whether these items should be refreshed, and the delay between refreshing each item.

The following is a full list of variables youc an use in these field values.

{author_id}
{author_username}
{channel_id}
{channel_name}
{channel_title}
{edit_date}
{entry_id}
{entry_date}
{page_uri}
{title}
{url_title}
{username}
{cat_url_title}
{cat_url_title_1}
{cat_url_title_2} etc

The {cat_url_title} variables behave a little differently than the other variables. If a single category is assigned to an entry, then {cat_url_title} will reflect that assigned categories value. However, if multiple cateegories are assigned, you will need to add a rule for each possible number of categories assigned. For example if you have an entry assigned to the categories of alpha, beta, charlie, and you want to clear the url of blog/category/beta when the entry is saved you will need to add multiple cache clearing rules. E.g. blog/category/{cat_url_title_1} , blog/category/{cat_url_title_2}, and blog/category/{cat_url_title_3} to ensure the cache is properly cleared.

If you are using the Structure module with static caching, and you want to clear a page's cache when the entry is saved, you'd enter static/{page_uri} as a Clear Item value.

You can further restrict cache clearing by Status or Category. If a Status or Category is selected, the possible entries that will have their cache cleared will be reduced to those that match the selected criteria. If you do not want this reduction, then do not select anything. After possible list of entries is reduced, the rest of the tag or item based cache clearing rules will be applied.

For example, if you have an entry with the title of "Speedy", the URL Title of "speedy", is assigned to the "Beta" category , and have a clear item rule of static/add-ons/{url_title} , when the "Speedy" entry is saved, since "Beta" is selected, the clear item rule will be applied and it will clear the cache. However, if you have assigned the category of "Delta" to the "Speedy" entry, the static/add-ons/{url_title} clear item rule will not match static/add-ons/speedy because the URL Title "speedy" will not be found from the list of entries, and {url_title} will not parse as "speedy", thus not matching the rule.

Pattern Matching

Available starting in Speedy v1.11.0

Clear Items and Clear Tags both support regular expression pattern matching. For example if you have a paginated set of pages that are cached, and when any entry in one of those pages is updated you may need to clear the cache for all pagination pages (e.g. /blog/P2, /blog/P3 etc). Since pagination grows over time managing the clearing rules for this would become burdensome. Instead you can create one Clear Items entry with the following value:

^static/blog/P[0-9]+

^static/blog/P(\d+) would also work, but not if you're using the Database cache driver. MySQL's regular expression operation has a slightly different syntax.

Note that both examples are starting with a ^, which indicates the start of a string to match. The ^ is required as part of Speedy's support for regular expression matching. It indicates to Speedy that it needs to alter the behavior used from matching exact strings, which is the fastest method, to using a regular expression, which can be a little slower.

If you are using the Redis driver with static or fragment caching, be very strict with your regular expression's. The smaller the matching pattern the better because Redis does not have a performant method to find cached items with regular expressions. Using the example above, static/blog/^P[0-9]+ would actually be much more performant in Redis than matching the whole string. Speedy splits up the regular expression beginning at the ^ to optimize the Redis query to the smallest possible data set before performing the pattern matching. It will only look in the static/blog/ subset of keys to match, ignoring all other keys, instead of trying to match static/blog/P[0-9]+ against all keys in Redis.

You can also use similar regular expressions to match against tags. If you tag a bunch products with their product ID, e.g. product-123, product-456, or product-789, you can enter one rule to clear all items matching that tag: ^product-[0-9]+

A few things to note:

1. Pattern matching is only supported in the Database, Redis, File, and Static cache drivers.

2. As stated, use pattern matching very carefully if using Redis.

3. Support for pattern matching is only available if you find a clear and obvious bug with the pattern matching feature. Support is not provided to help determine what pattern should be used to clear items. There are plenty of tools available to help write regular expressions.