In the latest versions (5.0+) of Plone, caching features, including plone.app.caching
, are shipped with Plone out of the box. However, these add-ons assume a dedicated front-end cache program, like Varnish, will be doing the data purges. For users hosting a Plone site through a cloud provider like Amazon Web Service (AWS), the connection between Plone and the AWS tool (e.g., Amazon CloudFront) is neither reliable nor supported through the standard Plone documentation.
When solutions to problems don’t exist, Six Feet Up creates them. Enter collective.cloudfront
, a Plone add-on designed to watch for Purge notifications from plone.app.caching
and send the corresponding invalidation requests to an instance of Amazon’s CloudFront. In other words, collective.cloudfront
saves time and money by bridging the gap between Plone and AWS and automating the purge process — when changes are made on a Plone site, the cache stored in CloudFront is also purged to avoid serving outdated content to the end user.
In the process of developing collective.cloudfront
, I identified and submitted pull requests to fix several bugs in plone.app.caching
. The bugs were sending multiple API requests to AWS servers for duplicate content — a costly issue, especially for large websites. Fortunately, the pull requests I documented for Plone’s open-source community solve the problem.
Additionally, my fellow Sixie and current Plone President, Chrissy Wainwright, contributed to collective.cloudfront
by creating a “purge all” button to delete a website’s cache at a designated time, rather than piece by piece as changes are made.
collective.cloudfront
add-on, check out the following documents:collective.cloudfront
README.rstcollective.cloudfront
on PyPiplone.app.caching
documentationBeing proactive and making contributions to the open source community is deeply ingrained into Six Feet Up’s culture and core values. Sign up for our newsletters to read more about best practices and get tech tips in your inbox.