The following is a guide to installing the Section Drupal module into an existing Drupal 8 application. This module allows Section’s global, distributed caching layer to quickly respond to invalidation events from a Drupal instance in exactly the same way that Drupal’s internal cache or a local varnish cache running on the host machine does, ensuring that the content in Section’s global caching layer is never stale.
if (req.method == "BAN")and
if (req.method == "PURGE")are not necessary on section because bans are handled via the API.
obj.http.Cache-Tags ~ "config:user.role.authenticated"
obj.http.Cache-Tags ~ "config:user.role.administrator"and/or
obj.http.Cache-Tags ~ "config:system.menu.admin"
This module can be found here. Download the latest release as a zip/tar file and load into your Drupal instance. We also support installing via composer.
Click the Extend tab in the admin console or otherwise navigate to
/admin/modules. If the Purge module is installed correctly, this page should contain a section called PURGE with various available submodules. Enable the
Purge Tokens, and
Purge UI submodules. We are also compatible with Drush but it is not required.
You also need to enable a way to process cache invalidation items. You choices are the
Cron processor and the
Late runtime processor.The
Cron Processor will process cache invalidations only when the cronjob is run (it runs automatically on a predefined schedule or you can initiate it manually from the admin console), while the
Late runtime processor will initiate cache bans as soon as a piece of content is changed. It does not matter to our module whether you choose either or both.
Finally, enable the Section Purger itself, along with the
Section HTTP Tags Header module and the
Core Tags Queuer. This module ensures that Drupal sends the appropriate cache tags that our module uses to evict expired assets from the cache.
/admin/config/system/keys/add and input your section.io password. Use key type
Authentication, and choose whichever key provider you find to be the safest in your particular environment. (More info on this in the key module documentation).
/admin/config/development/performance and set
Page Cache Max Age to whatever value you prefer. Since the extension is clearing the cache whenever a change event occurs, there is no need to wait for object resources to expire naturally and you can safely choose 1 year. Varnish Cache’s default behavior is to cache according to the cache-control headers on the response, but Varnish Cache can also be configured to set its own internal TTL value for cached objects based on content-type, status, or other response attributes. For more information on this, please see our Varnish Cache guides.
/admin/config/development/performance. If your installation of the purge module succeeded, you’ll see a
Purge tab next to the
Performance tab at the top of the page.
Next, click on
Add Purger to open the UI to create a new Purger and select
HTTP Purger. Once created, you should see a flash message informing you that the purger has been successfully created.
Next, click on the small arrow next to the purger and click
configure. This will open the UI to fill in your account credentials and connect your Drupal module to the Section platform.
The Drupal Site Name field should be the full hostname of the site for which you are configuring the purger, and is only necessary when setting up a Drupal 8 multisite. If your Drupal instance is not a multi-site, then this field can be left blank.
Once here, input the details of the user account you would like to use to authenticate with our API. Once done, click
Save Configuration. Once saved and configured properly, the status bar on the right hand side should show all green as pictured below.
You can set the logging levels from the block on the right sidebar on the purge page.
You can view the logs at
If you are seeing timeout errors connecting to aperture, raise the timeout in the purger settings.