A plugin for Neos CMS to auto purge NGINX proxy cache after publishing
This package provides an improved integration for Neos CMS and the NGINX proxy cache. The NGINX proxy cache caches the output of your website for a certain time and will deliver the cached version to your visitors with much greater performance. This system can also help with high traffic or smaller attacks on your site.
But of course NGINX cannot know when your content is updated. Therefore it's helpful to send refresh and invalidation notifications from your CMS when editing. This allows you to increase cache times and be sure that your visitors see current content with great performance.
Read An Introduction to Cache Invalidation to understand the main issue of caching and its advantages and drawbacks.
- ✓ Send refresh requests to NGINX when a page is published
- ✓ Send invalidation requests to NGINX when a page is not available anymore (needs the optional NGINX purge module)
- ✓ Send headers with each page to tell NGINX about the cache timeouts of a page
- ✓ Backend module to check configuration and flush single pages or purge the whole cache
- ✓ Disable caching via node properties
- ✓ Respect caching timeouts defined in Fusion
Not possible yet
- Invalidate other pages than the published one, f.e. refresh a blog overview when a single article has been published.
- Neos CMS 4.x
- NGINX as webserver
- NGINX purge module (optional)
Add the dependency to your site package like this
composer require --no-update shel/neos-nginx-cache
And then run
composer update in your project's root folder.
If you don't have the NGINX purge module, the package will only send refresh requests instead of using invalidations. You can find more information on how to setup the purge module here.
For more information on the setup and configuration, see the documentation
- Official NGINX proxy documentation
- NGINX configuration for the library used in this package
- NGINX caching example by digitalocean
This package was inspired by MOC.Varnish.
Varnish works similarly, but allows you to create a much finer configuration when and what is flushed from its cache. But the setup & configuration needs more knowledge as you need the Varnish service running additionally and you need to configure your webserver to communicate with it.
Therefore this package was created to help people who have smaller sites, which don't need the bigger setup or don't have access to Varnish on their servers.
For larger sites it's recommended to use Varnish when a lot of editing is happening.
Contributions are very welcome!
Please create detailed issues and PRs.