The modular external cache invalidation framework.
purge module facilitates cleaning external caching systems, reverse proxies and CDNs as content actually changes. This allows external caching layers to keep unchanged content cached infinitely, making content delivery more efficient, resilient and better guarded against traffic spikes.
8.x-3.x versions enable invalidation of content from external systems leveraging Drupal's brand new cache architecture. The technology-agnostic plugin architecture allows for different server configurations and use cases. Last but not least, it enforces a separation of concerns and should be seen as a middleware solution (see
For most simple configurations, start with:
drush en purge purge_ui purge_drush purge_queuer_coretags purge_processor_cron
- Head over to
- Now you need to install - and probably configure - a third-party module that provides a purger. If no module supports invalidation of your cache layer and doing so works over HTTP, then use the generic
This project aims to get all modules dealing with proxies and CDNs on board and to integrate with Purge. As known to date, these modules are or are being integrated:
purge_purger_httpfor generic HTTP-based invalidation, e.g. Varnish, Squid and Nginx.
Interested? Reach out any time of day and we'll get you going!
Drupal 7 and Pressflow 6
The current stable
1.x versions depend on the cache expiration module and act upon events that are likely to expire URLs from external caching systems. Technically these versions work by sending HTTP out
PURGE requests per changed item, the request can be defined exactly. You can find the installation instructions and frequently asked questions bundled in the code repository.
Mind the coverage gap
Due to the architectural nature of Drupal 7 and versions below, it is impossible for cache expiration to detect every single content change. In some cases you may need to use the expire module API or rules integration to cover views, blocks and places left undetected. In all cases we recommend testing thoroughly before increasing your
As our focus is on Drupal 8, the
1.x branch is in maintenance-only mode and receives mostly bug- and security fixes. The
2.x branch is considered experimental, unmaintained and will likely never reach a production release.