Varnish HTTP Purge sends a request to delete (aka flush) the cached data of a page or post every time it it modified. This happens when updating, publishing, commenting on, or deleting an post, and when changing themes.
Varnish is a web application accelerator also known as a caching HTTP reverse proxy. You install it in front of any server that speaks HTTP and configure it to cache the contents. This plugin does not install Varnish for you, nor will it configure Varnish for WordPress.
Not all page caches are deleted every time, depending on your Varnish configuration. For example, when a post, page, or custom post type is edited, or a new comment is added, only the following pages will purge:
- The front page
- The post/page edited
- Any categories, tags, and/or custom taxonomies associated with the page
- Related feeds
- Associated JSON API pages
In addition, your entire cache will be deleted on the following actions:
- Changing themes
- Press the ‘Purge Varnish Cache’ button on the dashboard or toolbar
Plugins can hook into the purge actions as well, to filter their own events to trigger a purge.
And if you’re into WP-CLI, you can use that too:
wp varnish purge
On a multisite network using subfolders, only network admins can purge the main site. This is a security decision.
- Pretty Permalinks enabled
- Varnish 3.x or higher
DownloadLatest version: Download Varnish HTTP Purge v4.3.1 [zip]
FAQQ. How can I tell everything’s working? A. From your WordPress Dashboard, go to Tools -> Varnish Status. There a page will auto-scan your main plugin page and report back any issues found. This includes any known problematic plugins. Q. Does every WordPress plugin and theme work with Varnish? A. No. Some of them have behaviour that causes Varnish not to cache. While I can’t debug that for you, there is an “Is Varnish Working?” tool (see WP Admin -> Tools -> Varnish Status) that tries to detect most of the common issues and direct you to resolutions. Q. How can I debug my site? A. Use the Varnish Status page. It will try and help you figure out what’s wrong. Q. Will you fix my site if there’s a conflict with a theme or plugin? A. I’m sorry but I can’t do that, I don’t have that much availability. I will try to point you towards solving it on your own. Bear in mind, that may mean you have to decide if using a specific plugin or theme is worth an imperfect cache. Q. What version of Varnish is supported? A. This was built and tested on Varnish 3.x. While it is reported to work on 2.x and 4.x, it is only supported on v3 at this time. Q. Why doesn’t every page cache get deleted when I make a new post? A. Philosophy. There are many other plugins out there which will allow you to granularly select what pages should and should not be deleted on updates. With that in mind, the choice was made for decisions instead of options, and simplicity was the driving principle. The plugin decides what’s best to delete on updates, and provides hooks for developers to use as needed. Q. Why doesn’t my cache get deleted when I edit my theme? A. If you activate a new theme, or use the customizer to edit your theme, it will delete your cache. If you edit theme (or plugin) files directly, WordPress cannot easily detect those changes, therefor the plugin will not delete the cache. In that situation, you will need to empty the cache manually. Q. How do I manually delete the whole cache? A. Click the ‘Empty Varnish Cache’ button on the “Right Now” Dashboard (see the screenshot if you can’t find it). There’s also an “Empty Cache” button on the admin toolbar. Q. I don’t see a button! A. That means your account doesn’t have the appropriate permissions. Only administrators can empty the entire cache. In the case of a subfolder multisite network, only the network admins can empty the cache for the primary site. Q. Why is nothing caching when I use PageSpeed? A. PageSpeed likes to put in Caching headers to say not to cache. To fix this, you need to put this in your
.htaccesssection for PageSpeed:
ModPagespeedModifyCachingHeaders offIf you’re using nginx, it’s
pagespeed ModifyCachingHeaders off;Q. Why aren’t my changes showing when I use CloudFlare or another proxy? A. When you use CloudFlare or any other similar service, you’ve got a proxy in front of the Varnish proxy. In general this isn’t a bad thing, though it can introduce some network latency (that means your site may run slower because it has to go through multiple layers to get to the content). The problem arises when the DNS shenanigans send the purge request to your domain name. When you’ve got an additional proxy like CloudFlare, you don’t want the request to go to the proxy, you want it to go to Varnish server. On single-site, you can edit this via the Tools -> Varnish Status page. On Multisite, you’ll need to add the following to your wp-config.php file:
Replace “126.96.36.199” with the IP of your Varnish Server (not CloudFlare, Varnish). DO NOT put in http in this define. If you want to use WP-CLI, you can set an option in the database. This will NOT take precedence over the define, it’s just there to let hosts who are using something like wp-cli do this for you in an automated fashion:
wp option add vhp_varnish_ip 188.8.131.52
Q. How do I find my Varnish IP? A. Your Varnish IP must be one of the IPs that Varnish is listening on. If you use multiple IPs, or if you’ve customized your ACLs, you’ll need to pick on that doesn’t conflict with your other settings. For example, if you have Varnish listening on a public and private IP, you’ll want to pick the private. On the other hand, if you told Varnish to listen on 0.0.0.0 (i.e. “listen on every interface you can”) you would need to check what IP you set your purge ACL to allow (commonly 127.0.0.1 aka localhost), and use that (i.e. 127.0.0.1). If your webhost set up Varnish, you may need to ask them for the specifics if they don’t have it documented. I’ve listed the ones I know about here, however you should still check with them if you’re not sure.
wp option update vhp_varnish_ip 184.108.40.2060
- DreamHost – If you’re using DreamPress and Cloudflare, go into the Panel and click on the DNS settings for the domain. The entry for resolve-to.domain is your varnish server: `resolve-to.www A 220.127.116.11` — If you’re NOT using Cloudflare, you don’t need it; it’s just your normal IP.
X-Purge-Methodin the header with a value of regex. If your Varnish server doesn’t doesn’t understand the wildcard, you can configure it to check for the header. Q. How can I see what the plugin is sending to Varnish? A. Danger! Here be dragons! If you’re command line savvy, you can monitor the interactions between the plugin and Varnish. This can help you understand what’s not working quite right, but it can very confusing. Detailed directions can be found on the debugging section. Q. How do I configure my VCL? A. This is a question beyond the support of plugin. I don’t offer any Varnish Config help due to resources. I will say this, you absolutely must have PURGE set up in your VCL. This is still supported in Varnish v3, though may not be set up by default. Also, here are some links to other people who use this plugin and have made public their VCLs: Full documentation can be found on Custom Filters in the wiki. Q. Hey, don’t you work at DreamHost? Is this Official or DreamHost only? A.
- Yes, I do work for DreamHost.
- No, this plugin is not really official nor DreamHost Only
- 10 October 2017
- Copied a wrong line.
- 10 October 2017
- Add Varnish Flush for “this” page on front end
- Do not flush non-public taxonomies
- 30 August 2017
- More flexible support for custom cat/tag bases
- Added in support for custom taxonomies
- New function to generate the URLs, so it can be called by external plugins
- Move right now box to be called later, preventing double calls
- Extra check for if it’s a URL, because some plugins are weird (props @danielkun)