PROJECTPAGE.md

The modular external cache invalidation framework.

The 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.

Drupal 8

The 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 README .pdf .md).

Getting started

For most simple configurations, start with:

• drush en purge purge_ui purge_drush purge_queuer_coretags purge_processor_cron
• Head over to admin/config/development/performance/purge.
• 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 purge_purger_http.

Third-party integration

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_http for generic HTTP-based invalidation, e.g. nginx, squid, etc.
• purge_queuer_url for legacy platforms not supporting cache tags. This is a poor solution when you regularly import content, it can lead to unsustainable big queues!
• acquia_purge
• akamai
• cloudflare
• cloudfront_purger
• fastlypurger
• keycdn
• varnish_purge

Anyone looking for a junior coding project, have a look at these issues:

• max_cdn_cache
• nginx_cache_clear

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 page_cache_maximum_age variable.

Release expectations

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.