In my previous post Automatic Dispatcher Cache Invalidation – Part 2, I explained the way to create a dispatcher flush agent that is triggered from a Publish instance. However, in CQ5.5 this will not always behave as expected. Out of the box, the CQ5.5 dispatcher flush agents on Publish only invalidate the cache when nodes of type cq:Page are replicated to it. This means that if you activate nodes of other types, including DAM assets, or replicating packages that only contain js and css nodes in client libraries etc, the replication of these will not invalidate the cache – your cache will still contain obsolete versions of these files until an actual page is replicated, and the cache invalidated.

AEM (CQ5.6) solves this issue with the new ‘On Receive’ trigger that has been made available to the Publish flush agents:

In CQ5.5, there is no such trigger (at this stage). There is a package that allows the cache to be invalidated when DAM assets are replicated which can be found here, but this still does not allow cache invalidation when other types of nodes are replicated.

My solution to this is to take the DAM asset invalidation workflow, script and launcher, and copy/modify these to suit the replication purposes that are required. For example, you could create a workflow that is triggered on modification of nodes of type nt:file that live under your /etc/designs/myproject tree, and this workflow can run a script to invalidate the cache. Careful implementation of these workflows will ensue that any replication successfully invalidates the cache when required.