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.
The Varnish HTTP Purge plugin 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.
In addition, it provides debugging tools to help you determine how effective your site setup is with Varnish. In order to provide the most up to date compatibility information, this tool contacts a service hosted on DreamObjects. Public information about this service is available on DreamObjects. The service is ONLY accessed when using the Varnish Debugging tool.
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
- Pressing the Empty 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.
On a multisite network using subfolders, only network admins can purge the main site. This is a security decision, as emptying the cache too often can be computationally expensive and cause server outages for a network.
wp varnish purge– Flush the entire cache
wp varnish debug– Help for debugging how well Varnish is (or isn’t) working
If you’re working on a site and need to turn off caching, add this to your wp-config file:
define( 'VHP_DEBUG', true );
That will break cache on page loads. It is not recommended for production!
- Pretty Permalinks enabled
- Varnish 3.x or higher
By default, no data is tracked. If you use the site scanner/debugging tool, your domain and IP address will access a remote service hosted on DreamObjects. No personally identifying transaction data is recorded or stored, only overall usage. IP addresses of the website making the request may be recorded by the service, but there is no way to access them and use it to correspond with individuals or processes.
Use of this service is required for the debugging tool, in order to provide up to date compatibility checks on plugins and themes that may conflict with running a server based cache (such as Varnish or Nginx) without needing to update the plugin every day.
DownloadLatest version: Download Varnish HTTP Purge v4.5.2 [zip]
FAQQ. Is this plugin caching my data? A. No. This plugin tells your cache system when content is updated, and to delete the cached data at that time. Q. How does this plugin know what to delete? A. When you update content on your site, like making a post or editing one, or someone leaving a comment, WordPress triggers a command on your server to purge (aka empty) the cache for any related pages, including the REST API. Q. Why doesn’t the plugin automatically delete the whole cache? 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. Can I delete the entire cache? A. Yes! Click the ‘Empty 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. If you don’t see a button, then 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. Will the plugin delete my cache when I edit my theme or plugins? A. No. WordPress can’t detect file changes like that, and you really don’t want it to. That would empty the cache every time you edited any file, which would cause your site to become unstable. You will need to use the Empty Cache buttons when you’re done editing your code. Q. Does every WordPress plugin and theme work with Varnish? A. No. Some of them have behaviour that causes Varnish not to cache, either by accident or design. Q. I’m a developer, can I tell your cache to empty in my plugin/theme? A. Yes! Full documentation can be found on Custom Filters in the wiki. Q. Can I turn off caching? A. Yes and no. Remember, the plugin isn’t doing the caching so it really depends on your server setup. You can set the following define in your
wp-config.phpfile to attempt and disable caching, however this may not work on all setups:
define( 'VHP_DEBUG', true );Q. How can I tell if everything’s caching? A. From your WordPress Dashboard, go to Tools -> Varnish Debugging. There a page will auto-scan your front page and report back any issues found. This includes any known problematic plugins. You can use it to scan any URL on your domain (but ONLY on your own domain). Q. Why doesn’t the debug page autoload anymore? A. The scan files were off-loaded to a service to allow for more frequent updates without having to require people to update the plugin. In order to ensure no one is scanned without consent, the auto-scanning was disabled. 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 put 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 WordPress tries to send the purge request to your domain name and, with a proxy, that means the proxy service and not your website. 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:
define('VHP_VARNISH_IP','18.104.22.168');Replace “22.214.171.124” 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 update vhp_varnish_ip 126.96.36.1990Q. 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.
- 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 188.8.131.52` — If you’re NOT using Cloudflare, you don’t need it; it’s just your normal IP.
localhostas Nginx requires a service control installed for the IP address to work. Q. Will you write my cache rules for me? A. This is a question beyond the support of plugin. I do not have the resources available to offer any configuration help. Here are some basic gotchas to be aware of:
- To empty any cached data, the service will need to respect the PURGE command
- Not all cache services set up PURGE by default
- When flushing the whole cache, the plugin sends a PURGE command of
/.*and sets the
- Yes, I do work for DreamHost.
- No, this plugin is not really official nor DreamHost Only
- June 2018
- Bug Fix: Prevent error for non-admins
- June 2018
- Due to contention (devs hate it, users like it) the empty cache button colour on the toolbar is removed, and replaced with a carrot icon (I did not make it orange, but I wanted to)
- Add carrot icon to collapsed (mobile) toolbar
- Better button hiding
- Fixed a stupid argument issue with flushing memcached and I should have known better but oh well
- FAQ update re nginx
- May 2018
- Remote storage of problem plugins/themes
- Prevent auto-loading of scan for improved disclosure and compliance
- Changed colour of the purge button for improved visibility
- Support for nginx proxy headers