Check it on your site

Look at one header, then roll out in steps.

Every change the package handles is tested end to end on every commit: pickers, blocks, rich text, media, cultures, listings, renames, unpublishing and the recycle bin, on one server, on two, and with Umbraco’s output cache on. What your site adds is its own setup, so take a quick look there too.

Look at a header

curl -sD - -o /dev/null https://cms.example.com/umbraco/delivery/api/v2/content/item/some/page/ | grep -i x-umbraco-cache-keys

It lists umbraco, the page’s own key and the key of everything the page shows. References are read through Umbraco’s own reference tracking, so anything Umbraco lists under a page’s References is covered, your own property editors included.

If a CDN or proxy sits in front of Umbraco, request the page through it too and check the header arrives whole. nginx needs a proxy_buffer_size of 16k or more for long headers.

Roll out in steps

1. Without a target. Install the package and add no target. It records each change and the keys it would purge under Settings > Advanced > Cache tags > Changes, and sends nothing.
2. With a target. Add your target and tag your frontend’s cache, but keep your revalidate time. Publish a page and watch it, and the pages that show it, refresh.
3. A long cache. Once that looks right, raise the revalidate time. Keep a safety revalidate, such as a day.

To roll back at any step, remove the target.