{"id":299720,"date":"2026-06-15T23:15:21","date_gmt":"2026-06-15T23:15:21","guid":{"rendered":"https:\/\/wordpress.org\/plugins\/mscache-varnish-purge\/"},"modified":"2026-06-15T23:15:01","modified_gmt":"2026-06-15T23:15:01","slug":"mscache-varnish-purge","status":"publish","type":"plugin","link":"https:\/\/cn.wordpress.org\/plugins\/mscache-varnish-purge\/","author":13604496,"comment_status":"closed","ping_status":"closed","template":"","meta":{"version":"1.0.0","stable_tag":"1.0.0","tested":"7.0","requires":"5.6","requires_php":"7.0","requires_plugins":null,"header_name":"MSCache Varnish Purge","header_author":"Managed Server S.r.l. - Performance Managed Hosting","header_description":"Purge Varnish cache from the WordPress admin area via raw socket PURGE, with automatic purge on content changes, exclusions, manual purge tools and full cache purge support.","assets_banners_color":"9b9b8c","last_updated":"2026-06-15 23:15:01","external_support_url":"","external_repository_url":"","donate_link":"","header_plugin_uri":"https:\/\/managedserver.it\/mscache-varnish-purge\/","header_author_uri":"https:\/\/managedserver.it","rating":0,"author_block_rating":0,"active_installs":0,"downloads":38,"num_ratings":0,"support_threads":0,"support_threads_resolved":0,"author_block_count":0,"sections":["description","installation","faq","changelog"],"tags":{"1.0.0":{"tag":"1.0.0","author":"dreamsnet","date":"2026-06-15 23:15:01"}},"upgrade_notice":[],"ratings":[],"assets_icons":{"icon-128x128.png":{"filename":"icon-128x128.png","revision":3573780,"resolution":"128x128","location":"assets","locale":"","width":128,"height":128},"icon-256x256.png":{"filename":"icon-256x256.png","revision":3573780,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256},"icon-512x512.png":{"filename":"icon-512x512.png","revision":3573780,"resolution":"512x512","location":"assets","locale":"","width":512,"height":512}},"assets_banners":{"banner-1544x500.png":{"filename":"banner-1544x500.png","revision":3573780,"resolution":"1544x500","location":"assets","locale":"","width":1544,"height":500},"banner-772x250.png":{"filename":"banner-772x250.png","revision":3573780,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.0.0"],"block_files":[],"assets_screenshots":[],"screenshots":[]},"plugin_section":[262246],"plugin_tags":[146,247,7914,45950,3886],"plugin_category":[52,54],"plugin_contributors":[267309],"plugin_business_model":[],"class_list":["post-299720","plugin","type-plugin","status-publish","hentry","plugin_section-dashboard-widgets","plugin_tags-cache","plugin_tags-performance","plugin_tags-purge","plugin_tags-reverse-proxy","plugin_tags-varnish","plugin_category-performance","plugin_category-security-and-spam-protection","plugin_contributors-dreamsnet","plugin_committers-dreamsnet"],"banners":{"banner":"https:\/\/ps.w.org\/mscache-varnish-purge\/assets\/banner-772x250.png?rev=3573780","banner_2x":"https:\/\/ps.w.org\/mscache-varnish-purge\/assets\/banner-1544x500.png?rev=3573780","banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/mscache-varnish-purge\/assets\/icon-128x128.png?rev=3573780","icon_2x":"https:\/\/ps.w.org\/mscache-varnish-purge\/assets\/icon-256x256.png?rev=3573780","generated":false},"screenshots":[],"raw_content":"<!--section=description-->\n<p><strong>MSCache Varnish Purge<\/strong> helps WordPress administrators purge the Varnish cache for sites running behind a Varnish HTTP reverse proxy. It is developed by <a href=\"https:\/\/managedserver.it\">Managed Server S.r.l.<\/a> and provides settings for configuring the Varnish connection, automatic cache invalidation when content changes, and manual purge tools available from the WordPress admin area.<\/p>\n\n<p>This plugin is useful when your WordPress site sits behind Varnish and you need cached pages to be invalidated after content is published or updated, or on demand. It requires a reachable Varnish instance whose VCL is configured to accept PURGE requests from the WordPress server (see the FAQ for a reference VCL).<\/p>\n\n<p>The settings page is available at <strong>Settings \u2192 MSCache Varnish Purge<\/strong>. On WordPress Multisite, shared connection settings are configured at <strong>Network Admin \u2192 Settings \u2192 MSCache Network<\/strong>, while each site keeps its own purge options.<\/p>\n\n<h4>Key Features<\/h4>\n\n<ul>\n<li><strong>Asynchronous raw socket PURGE<\/strong> \u2014 sends PURGE requests via a direct TCP socket (fsockopen) without waiting for the Varnish response, so the purge request does not block the WordPress request.<\/li>\n<li><strong>Automatic purge on content changes<\/strong> \u2014 when a post, page, or custom post type is published, updated, trashed, or deleted, the plugin automatically purges the affected URLs including the post itself, home page, categories, tags, author archives, and date archives.<\/li>\n<li><strong>Full cache purge<\/strong> \u2014 supports multiple methods for purging the entire cache: PURGE wildcard, PURGE custom path, or BAN with configurable header.<\/li>\n<li><strong>Additional URLs<\/strong> \u2014 define a list of extra paths to purge alongside content changes or on demand.<\/li>\n<li><strong>Exclusion patterns<\/strong> \u2014 define glob or regex patterns for URLs that should be excluded from caching. Matching requests receive the <code>ms-cache: excluded<\/code> HTTP header, which can be used by Varnish to skip caching.<\/li>\n<li><strong>Admin bar integration<\/strong> \u2014 quick-access purge buttons in the WordPress admin bar: Purge All, Purge Home, Purge Current Page.<\/li>\n<li><strong>Bulk and row actions<\/strong> \u2014 purge cache for selected posts\/pages directly from the list table.<\/li>\n<li><strong>Debug logging<\/strong> \u2014 optional logging of all purge operations to a protected log directory.<\/li>\n<li><strong>PHP 7 and PHP 8 compatible<\/strong> \u2014 works on PHP 7.0 through PHP 8.x without deprecation warnings.<\/li>\n<\/ul>\n\n<h4>How It Works<\/h4>\n\n<p>The plugin opens a raw TCP socket to your Varnish server and sends an HTTP PURGE request with the appropriate Host header. The socket is closed immediately after writing the request \u2014 the plugin does <strong>not<\/strong> wait for Varnish to respond. This \"fire and forget\" approach is designed to avoid blocking the WordPress request while the purge is processed.<\/p>\n\n<h4>External Services<\/h4>\n\n<p>This plugin optionally connects to the following external services when configured by the administrator:<\/p>\n\n<p><strong>Cloudflare API<\/strong> \u2014 When the Cloudflare integration is enabled, the plugin sends cache purge requests to the Cloudflare API v4 (<code>https:\/\/api.cloudflare.com\/client\/v4\/<\/code>) to synchronize Varnish cache invalidation with Cloudflare CDN edge cache. This requires a Cloudflare account, a Zone ID, and an API Token with \"Zone.Cache Purge\" permission. No personal data or visitor information is transmitted \u2014 only URL paths and authentication credentials are sent.<\/p>\n\n<ul>\n<li><a href=\"https:\/\/www.cloudflare.com\/terms\/\">Cloudflare Terms of Service<\/a><\/li>\n<li><a href=\"https:\/\/www.cloudflare.com\/privacypolicy\/\">Cloudflare Privacy Policy<\/a><\/li>\n<\/ul>\n\n<p><strong>Varnish Cache<\/strong> \u2014 The plugin opens raw TCP socket connections to a Varnish server at a user-configured IP address and port (default: 127.0.0.1:80). This is typically a localhost connection to infrastructure managed by the site administrator. No external third-party service is contacted for this functionality.<\/p>\n\n<h4>Data Handling &amp; Logging<\/h4>\n\n<p>When debug mode is enabled by the administrator, the plugin logs technical data (URL paths, timestamps, socket connection status, purge results) to files in <code>wp-content\/uploads\/mscache-logs\/<\/code>. Log files are protected with <code>.htaccess<\/code> rules, obfuscated filenames, and an <code>index.php<\/code> guard. No personally identifiable information (PII) or visitor data is collected, stored, or transmitted. Purge statistics (success\/failure counts, recent activity) are stored in the WordPress options table and are visible only to administrators.<\/p>\n\n<h3>Configuration<\/h3>\n\n<h4>General Settings<\/h4>\n\n<ul>\n<li><strong>Enable Plugin<\/strong> \u2014 master switch for all purge functionality.<\/li>\n<li><strong>Varnish IP<\/strong> \u2014 the IP address of your Varnish server (default: 127.0.0.1).<\/li>\n<li><strong>Varnish Port<\/strong> \u2014 the port Varnish listens on (default: 80).<\/li>\n<li><strong>Custom Host Header<\/strong> \u2014 override the Host header sent with purge requests. Leave empty to use your WordPress site URL.<\/li>\n<li><strong>Socket Timeout<\/strong> \u2014 connection timeout in seconds (default: 5).<\/li>\n<\/ul>\n\n<h4>Automatic Purge<\/h4>\n\n<p>Choose which content changes trigger automatic cache purge:<\/p>\n\n<ul>\n<li>Posts, Pages, Custom Post Types<\/li>\n<li>Home page<\/li>\n<li>Category, tag, author, and date archives<\/li>\n<\/ul>\n\n<h4>Full Cache Purge<\/h4>\n\n<p>Three methods are available:<\/p>\n\n<ul>\n<li><strong>PURGE \/.&#042;<\/strong> \u2014 sends a PURGE request with a wildcard path. Requires Varnish VCL to handle regex\/wildcard PURGE.<\/li>\n<li><strong>PURGE custom path<\/strong> \u2014 sends PURGE to a specific path (e.g., <code>\/purge-all<\/code>). Useful when your VCL maps a special path to a full ban.<\/li>\n<li><strong>BAN with custom header<\/strong> \u2014 sends a BAN request with a configurable header name and value. The most flexible option but requires matching VCL configuration.<\/li>\n<\/ul>\n\n<p><strong>Important:<\/strong> The actual behavior of a full purge depends entirely on your Varnish VCL configuration. The plugin only sends the request \u2014 it is your VCL that decides what gets purged.<\/p>\n\n<h4>Additional URLs<\/h4>\n\n<p>Enter one URL per line (absolute or relative paths). These URLs can be purged:<\/p>\n\n<ul>\n<li>Automatically alongside post\/page saves (if the option is enabled)<\/li>\n<li>Manually via the \"Purge Additional URLs\" button<\/li>\n<\/ul>\n\n<h4>Exclusions<\/h4>\n\n<p>Define patterns (one per line) for URLs that should be excluded from caching. Two matching modes:<\/p>\n\n<ul>\n<li><strong>Glob<\/strong> (default) \u2014 supports <code>*<\/code> (any characters) and <code>?<\/code> (single character). Example: <code>\/wp-admin\/*<\/code>, <code>\/cart*<\/code>, <code>*.xml<\/code><\/li>\n<li><strong>Regex<\/strong> (advanced) \u2014 full regular expression support. Use with caution.<\/li>\n<\/ul>\n\n<p>When a frontend request matches an exclusion pattern, the plugin sends the HTTP header <code>ms-cache: excluded<\/code>. Your Varnish VCL can check for this header and bypass caching accordingly.<\/p>\n\n<p>Lines starting with <code>#<\/code> are treated as comments and ignored.<\/p>\n\n<p>Matching is performed on the request path only, ignoring the query string.<\/p>\n\n<h3>Disclaimer<\/h3>\n\n<p>This plugin is provided \"as is\" under the terms of the GNU General Public License v2 or later. MANAGED SERVER S.R.L. does not warrant that the plugin will function correctly on hosting environments, servers, or Varnish configurations not directly managed by the company. The plugin has been tested and validated exclusively on the Managed Server hosting infrastructure. Use on third-party environments is at the user's sole risk and responsibility. In no event shall MANAGED SERVER S.R.L. be liable for any direct, indirect, incidental, or consequential damages arising from the use of this plugin outside of the Managed Server infrastructure.<\/p>\n\n<!--section=installation-->\n<ol>\n<li>Upload the <code>mscache-varnish-purge<\/code> folder to <code>\/wp-content\/plugins\/<\/code>.<\/li>\n<li>Activate the plugin through the WordPress admin panel.<\/li>\n<li>Go to <strong>Settings \u2192 MSCache Varnish Purge<\/strong> to configure. On a Multisite network, shared connection settings are at <strong>Network Admin \u2192 Settings \u2192 MSCache Network<\/strong>.<\/li>\n<li>Set the Varnish IP address (default: 127.0.0.1) and port (default: 80).<\/li>\n<li>Enable the plugin and configure automatic purge options.<\/li>\n<li>Make sure your Varnish VCL is configured to handle PURGE requests (see FAQ).<\/li>\n<\/ol>\n\n<!--section=faq-->\n<dl>\n<dt id=\"compatibility%20and%20supported%20environments\"><h3>Compatibility and Supported Environments<\/h3><\/dt>\n<dd><p>This plugin has been designed, developed, tested, and validated on the hosting infrastructure of <strong>Managed Server S.r.l. \u2014 Performance Managed Hosting<\/strong> (<a href=\"https:\/\/managedserver.it\">managedserver.it<\/a>). The reference stack consists of Nginx (SSL termination and micro-caching) + Varnish Cache 3.x\/4.x (HTTP reverse proxy) + Apache\/Nginx (backend) + PHP-FPM, running on Linux.<\/p>\n\n<p>The plugin communicates with Varnish via raw TCP socket on a configurable IP address and port. <strong>Whether it works on other hosting environments depends entirely on:<\/strong><\/p>\n\n<ul>\n<li>The Varnish version installed and its VCL configuration<\/li>\n<li>The IP address and port on which Varnish listens for HTTP requests<\/li>\n<li>The network topology (is Varnish on localhost? Behind a load balancer? On a separate machine?)<\/li>\n<li>The presence of additional caching layers (Nginx proxy cache, CDN, etc.)<\/li>\n<li>ACL rules in the VCL that control which IPs are authorized to send PURGE requests<\/li>\n<\/ul>\n\n<p><strong>Other hosting providers that use Varnish Cache may work perfectly with this plugin<\/strong>, provided that their VCL is configured to accept PURGE requests from the WordPress server and that the IP\/port are set correctly in the plugin settings.<\/p>\n\n<p><strong>Disclaimer:<\/strong> MANAGED SERVER S.R.L. does not assume any responsibility, direct or indirect, for malfunctions, data loss, cache inconsistencies, service interruptions, or any other issue arising from the use of this plugin on hosting environments, servers, or infrastructure not directly managed by Managed Server S.r.l. The plugin is provided \"as is\" under the GPLv2 license. Use on third-party environments is at your own risk and responsibility. We strongly recommend testing thoroughly in a staging environment before deploying to production.<\/p><\/dd>\n<dt id=\"what%20varnish%20vcl%20do%20i%20need%3F\"><h3>What Varnish VCL do I need?<\/h3><\/dt>\n<dd><p>Your VCL must handle PURGE requests from the WordPress server and optionally support the <code>ms-cache: excluded<\/code> header for cache exclusions. Below is the reference VCL configuration tested and validated on the Managed Server infrastructure, for Varnish 3.x. Replace <code>123.123.123.123<\/code> with your server's public IP address and <code>127.0.0.2<\/code> with your actual backend address and port.<\/p>\n\n<p><strong>vcl_recv \u2014 PURGE handling (single URL + full domain):<\/strong><\/p>\n\n<p>`\nbackend website {\n    .host = \"127.0.0.2\";\n    .port = \"80\";\n}<\/p>\n\n<p>sub vcl_recv {<\/p><\/dd>\n<dt id=\"set%20x-forwarded-for%20header\"><h3>Set X-Forwarded-For header<\/h3><\/dt>\n<dd><p>if (req.http.x-forwarded-for) {\n        set req.http.X-Forwarded-For =\n            req.http.X-Forwarded-For + \", \" + client.ip;\n    } else {\n        set req.http.X-Forwarded-For = client.ip;\n    }<\/p><\/dd>\n<dt id=\"---------------------------------------------------------------\"><h3>---------------------------------------------------------------<\/h3><\/dt>\n<dd><p>if (beresp.http.ms-cache == \"excluded\") {\n        set beresp.ttl = 0s;\n        set beresp.http.X-Cache = \"EXCLUDED\";<\/p><\/dd>\n<dt id=\"...%20your%20other%20vcl_recv%20rules%20...\"><h3>... your other vcl_recv rules ...<\/h3><\/dt>\n<dd><p>}<\/p>\n\n<pre><code>**vcl_fetch \u2014 Respect the ms-cache: excluded header from the plugin:**\n<\/code><\/pre>\n\n<p>sub vcl_fetch {<\/p><\/dd>\n<dt id=\"unset%20beresp.http.ms-cache%3B\"><h3>unset beresp.http.ms-cache;<\/h3><\/dt>\n<dd><p>return (hit_for_pass);\n    }<\/p><\/dd>\n<dt id=\"...%20your%20other%20vcl_fetch%20rules%20...\"><h3>... your other vcl_fetch rules ...<\/h3><\/dt>\n<dd><p>}\n`<\/p><\/dd>\n<dt id=\"how%20does%20the%20purge%20mechanism%20work%3F\"><h3>How does the purge mechanism work?<\/h3><\/dt>\n<dd><p>The plugin sends an HTTP <code>PURGE<\/code> request to Varnish via a raw TCP socket connection (<code>fsockopen<\/code>). The request includes the URL path to invalidate and the correct <code>Host<\/code> header for the domain.<\/p>\n\n<p><strong>Single URL purge<\/strong> \u2014 When a post is saved, the plugin sends:<\/p>\n\n<pre><code>PURGE \/2026\/04\/03\/my-post-title\/ HTTP\/1.0\nHost: www.example.com\nConnection: Close\n<\/code><\/pre>\n\n<p>The VCL uses <code>ban()<\/code> with a regex anchored match (<code>^\/path\/$<\/code>) to invalidate the URL. This approach is used instead of <code>return(purge)<\/code> because most production Varnish configurations include additional keys in <code>vcl_hash<\/code> (e.g., <code>x-ua-device<\/code> for mobile\/desktop variants). A <code>ban()<\/code> invalidates <strong>all variants<\/strong> of the URL in a single operation, regardless of the hash.<\/p>\n\n<p><strong>Full cache purge<\/strong> \u2014 When \"Purge Entire Cache\" is clicked, the plugin sends:<\/p>\n\n<pre><code>PURGE \/.* HTTP\/1.0\nHost: www.example.com\nConnection: Close\n<\/code><\/pre>\n\n<p>The VCL interprets <code>\/.*<\/code> as a regex matching all URLs for that host, effectively invalidating the entire domain cache.<\/p>\n\n<p><strong>Asynchronous (fire-and-forget)<\/strong> \u2014 The socket is closed immediately after sending the request. The plugin does NOT wait for Varnish to respond, so the purge request does not block the WordPress request. In debug mode, the plugin reads the response status line for logging purposes.<\/p><\/dd>\n<dt id=\"what%20is%20the%20difference%20between%20purge%20and%20ban%3F\"><h3>What is the difference between PURGE and BAN?<\/h3><\/dt>\n<dd><ul>\n<li><p><strong>PURGE<\/strong> (<code>return(purge)<\/code> in VCL) removes a single cached object matching an exact URL and hash. It is fast and frees memory immediately, but only works for the exact hash \u2014 if your <code>vcl_hash<\/code> includes device type, language, or other keys, you would need a separate PURGE for each variant.<\/p><\/li>\n<li><p><strong>BAN<\/strong> (<code>ban()<\/code> in VCL) adds a rule to the ban list that retroactively invalidates all cached objects matching a condition. Objects are checked against the ban list when they are next requested. BAN is more flexible because it can match patterns (regex) and invalidates all variants of a URL regardless of the hash.<\/p><\/li>\n<\/ul>\n\n<p><strong>This plugin uses the BAN mechanism<\/strong> (via the PURGE HTTP method) because it is the most reliable approach for production environments with multi-variant caching (mobile\/desktop, multilingual, A\/B testing, etc.).<\/p><\/dd>\n<dt id=\"what%20does%20the%20ms-cache%3A%20excluded%20header%20do%3F\"><h3>What does the ms-cache: excluded header do?<\/h3><\/dt>\n<dd><p>When a frontend request path matches one of the exclusion patterns configured in the plugin settings (e.g., <code>\/cart\/*<\/code>, <code>\/checkout\/*<\/code>, <code>\/my-account\/*<\/code>), the plugin adds the HTTP response header <code>ms-cache: excluded<\/code>. This header does nothing by itself \u2014 it is a signal for your caching layer to skip caching for that response.<\/p>\n\n<p><strong>In Varnish:<\/strong> The <code>vcl_fetch<\/code> block shown above checks for this header and sets <code>beresp.ttl = 0s<\/code> + <code>return(hit_for_pass)<\/code>, ensuring the response is never stored in cache.<\/p>\n\n<p><strong>In Nginx proxy cache:<\/strong> You can use this header with <code>proxy_no_cache<\/code> to achieve the same effect. See the Nginx integration section in the plugin documentation.<\/p>\n\n<p><strong>WooCommerce pages<\/strong> (Cart, Checkout, My Account) can be automatically excluded without manual pattern configuration by enabling the \"Auto-Exclude WooCommerce Pages\" option in the WooCommerce tab.<\/p><\/dd>\n<dt id=\"does%20this%20plugin%20work%20with%20wordpress%20multisite%3F\"><h3>Does this plugin work with WordPress Multisite?<\/h3><\/dt>\n<dd><p>Yes. The plugin fully supports WordPress Multisite with a dual-layer configuration:<\/p>\n\n<ul>\n<li><strong>Network-level settings<\/strong> \u2014 Varnish IP, port, socket timeout, Cloudflare CDN integration, and third-party plugin integrations are configured once in Network Admin \u2192 Settings \u2192 MSCache Network and shared across all sites in the network.<\/li>\n<li><strong>Per-site settings<\/strong> \u2014 Each site in the network has its own independent configuration for auto-purge options, exclusion patterns, WooCommerce integration, permissions, and debug mode.<\/li>\n<li><strong>Dynamic host header<\/strong> \u2014 The plugin automatically detects and uses the correct domain name for each site when sending PURGE requests. Sites with custom domains (domain mapping) are supported.<\/li>\n<li><strong>Network admin dashboard<\/strong> \u2014 Shows all sites in the network with their host headers and plugin status (enabled\/disabled) at a glance.<\/li>\n<li><strong>WP-CLI<\/strong> \u2014 The <code>wp mscache purge-network<\/code> command purges the cache for all sites in the network in a single operation, iterating through each site with the correct host header.<\/li>\n<\/ul><\/dd>\n<dt id=\"is%20it%20safe%20for%20shared%20hosting%3F\"><h3>Is it safe for shared hosting?<\/h3><\/dt>\n<dd><p>Yes. The plugin only opens outbound TCP connections to the configured Varnish IP (default: <code>127.0.0.1<\/code>, localhost). It does not require any special PHP extensions beyond the standard <code>fsockopen<\/code> function available in all PHP installations. It is compatible with PHP 7.0 through PHP 8.x without deprecation warnings.<\/p><\/dd>\n<dt id=\"why%20raw%20sockets%20instead%20of%20wp_remote_request%3F\"><h3>Why raw sockets instead of wp_remote_request?<\/h3><\/dt>\n<dd><p>The WordPress HTTP API (<code>wp_remote_request<\/code>) sends the request and waits for the full HTTP response cycle before returning control to WordPress. This adds latency to every post save.<\/p>\n\n<p>Raw sockets with <code>fsockopen<\/code> allow the plugin to:<\/p>\n\n<ol>\n<li>Open a TCP connection to Varnish<\/li>\n<li>Write the PURGE request<\/li>\n<li>Close the connection immediately \u2014 without reading the response<\/li>\n<\/ol>\n\n<p>This \"fire and forget\" approach avoids waiting for the full HTTP response cycle on each purge, so the purge request does not block the WordPress admin request regardless of how long Varnish takes to process it.<\/p>\n\n<p>In debug mode, the plugin optionally reads the first response line (status code) for logging, which adds ~2-3ms but provides valuable diagnostic information.<\/p><\/dd>\n<dt id=\"what%20integrations%20are%20supported%3F\"><h3>What integrations are supported?<\/h3><\/dt>\n<dd><p>The plugin integrates with:<\/p>\n\n<ul>\n<li><strong>Cloudflare CDN<\/strong> \u2014 Synchronized cache purge via Cloudflare API v4 (per-URL or purge-everything)<\/li>\n<li><strong>WP Rocket<\/strong> \u2014 Bidirectional sync (MSCache \u2192 WP Rocket and WP Rocket \u2192 MSCache)<\/li>\n<li><strong>FlyingPress<\/strong> \u2014 Bidirectional sync<\/li>\n<li><strong>W3 Total Cache<\/strong> \u2014 Sync purge (MSCache \u2192 W3TC)<\/li>\n<li><strong>Autoptimize<\/strong> \u2014 CSS\/JS cache clear on full Varnish purge<\/li>\n<li><strong>Redis \/ Memcached Object Cache<\/strong> \u2014 Optional flush on full purge<\/li>\n<li><strong>WooCommerce<\/strong> \u2014 Dedicated integration with stock, sales, reviews, coupons, attributes, orders, and auto-exclusion of dynamic pages<\/li>\n<\/ul>\n\n<p>Each integration is detailed below.<\/p><\/dd>\n<dt id=\"cloudflare%20cdn%20integration\"><h3>Cloudflare CDN Integration<\/h3><\/dt>\n<dd><p>Many websites use Cloudflare as a CDN and security layer in front of their origin server. When Varnish is purged, the content at the origin is fresh \u2014 but Cloudflare edge nodes around the world may still serve stale cached copies to visitors for hours or days.<\/p>\n\n<p>The plugin solves this by optionally sending purge requests to the Cloudflare API v4 every time Varnish is purged. Configuration requires a Cloudflare <strong>API Token<\/strong> (with \"Zone.Cache Purge\" permission) and the <strong>Zone ID<\/strong> of your domain, both available from the Cloudflare dashboard.<\/p>\n\n<p>Three purge modes are available:<\/p>\n\n<ul>\n<li><strong>Per-URL<\/strong> \u2014 Each individual URL purged from Varnish is also purged from Cloudflare. Precise but generates more API calls. Cloudflare free plan allows 1,000 purge API calls per day.<\/li>\n<li><strong>Purge Everything<\/strong> \u2014 Any Varnish purge event triggers a full Cloudflare cache purge. Simple but clears the entire CDN cache including static assets (CSS, JS, images).<\/li>\n<li><strong>Per-URL + full purge fallback<\/strong> (recommended) \u2014 Individual page purges are sent per-URL to Cloudflare. Full Varnish purge events trigger a Cloudflare \"purge everything\". This mode balances per-URL precision with simplicity.<\/li>\n<\/ul>\n\n<p>A <strong>Test Connection<\/strong> button in the Cloudflare tab verifies that the API Token and Zone ID are valid and shows the zone name and status.<\/p><\/dd>\n<dt id=\"wp%20rocket%20integration\"><h3>WP Rocket Integration<\/h3><\/dt>\n<dd><p>WP Rocket is one of the most popular WordPress performance plugins, providing page caching, file optimization, and lazy loading. When both MSCache and WP Rocket are active, two separate caching layers exist: Varnish (server-level) and WP Rocket (application-level). If only one is purged, visitors may see inconsistent content.<\/p>\n\n<p>The integration provides <strong>bidirectional synchronization<\/strong>:<\/p>\n\n<ul>\n<li><strong>MSCache \u2192 WP Rocket<\/strong> \u2014 When MSCache purges a URL from Varnish, it also calls <code>rocket_clean_post()<\/code> to clear that page from WP Rocket's local page cache. On a full Varnish purge, <code>rocket_clean_domain()<\/code> clears the entire WP Rocket cache.<\/li>\n<li><strong>WP Rocket \u2192 MSCache<\/strong> \u2014 When a user clicks \"Clear Cache\" in WP Rocket (or WP Rocket clears cache automatically), MSCache listens to the <code>after_rocket_clean_domain<\/code>, <code>after_rocket_clean_post<\/code>, and <code>after_rocket_clean_home<\/code> hooks and sends corresponding PURGE requests to Varnish.<\/li>\n<\/ul>\n\n<p><strong>Important:<\/strong> WP Rocket has its own built-in Varnish add-on. If both the WP Rocket Varnish add-on and this MSCache integration are active simultaneously, you may get duplicate PURGE requests to Varnish. The plugin auto-detects this conflict and displays a warning in the Integrations tab. Disable WP Rocket's Varnish add-on when using MSCache.<\/p>\n\n<p>An infinite loop guard prevents MSCache \u2192 WP Rocket \u2192 MSCache \u2192 WP Rocket cycles.<\/p><\/dd>\n<dt id=\"flyingpress%20integration\"><h3>FlyingPress Integration<\/h3><\/dt>\n<dd><p>FlyingPress is a lightweight WordPress performance plugin focused on page caching and CDN. The integration works similarly to WP Rocket:<\/p>\n\n<ul>\n<li><strong>MSCache \u2192 FlyingPress<\/strong> \u2014 Calls <code>FlyingPress\\Purge::purge_url()<\/code> for single pages and <code>FlyingPress\\Purge::purge_everything()<\/code> for full cache purge.<\/li>\n<li><strong>FlyingPress \u2192 MSCache<\/strong> \u2014 Listens to the <code>flying_press_purge_everything<\/code> action. When FlyingPress clears its cache, MSCache also sends a full PURGE to Varnish.<\/li>\n<\/ul>\n\n<p>The plugin auto-detects FlyingPress via <code>FLYING_PRESS_VERSION<\/code> constant or class existence and shows the detection status in the Integrations tab.<\/p><\/dd>\n<dt id=\"w3%20total%20cache%20integration\"><h3>W3 Total Cache Integration<\/h3><\/dt>\n<dd><p>W3 Total Cache (W3TC) is a comprehensive performance plugin with page cache, database cache, object cache, and CDN support. The integration is <strong>one-directional<\/strong> (MSCache \u2192 W3TC):<\/p>\n\n<ul>\n<li>When MSCache purges a single URL, it calls <code>w3tc_flush_post()<\/code> to clear that page from all W3TC cache layers.<\/li>\n<li>When MSCache performs a full purge, it calls <code>w3tc_flush_all()<\/code> to clear the entire W3TC cache.<\/li>\n<\/ul>\n\n<p><strong>Important:<\/strong> W3TC has its own Varnish module. If both the W3TC Varnish module and MSCache are active, you will get duplicate PURGE requests. The plugin auto-detects this conflict and warns you. Disable W3TC's Varnish module when using MSCache.<\/p><\/dd>\n<dt id=\"autoptimize%20integration\"><h3>Autoptimize Integration<\/h3><\/dt>\n<dd><p>Autoptimize aggregates and minifies CSS and JavaScript files to reduce HTTP requests and file sizes. After a theme or plugin update, the optimized asset bundles may reference outdated code.<\/p>\n\n<p>The integration is <strong>one-directional and limited to full purge only<\/strong>:<\/p>\n\n<ul>\n<li>When MSCache performs a full Varnish purge (e.g., after a plugin\/theme update), it also calls <code>autoptimizeCache::clearall()<\/code> to regenerate all optimized CSS\/JS bundles.<\/li>\n<li>Single page purges do <strong>not<\/strong> trigger Autoptimize clear, because regenerating all optimized assets for a single page change would be disproportionately expensive.<\/li>\n<\/ul>\n\n<p>This ensures that after major updates, both the Varnish cache and the Autoptimize asset cache are fresh and consistent.<\/p><\/dd>\n<dt id=\"redis%20%2F%20memcached%20object%20cache%20integration\"><h3>Redis \/ Memcached Object Cache Integration<\/h3><\/dt>\n<dd><p>WordPress object cache (Redis, Memcached, APCu) stores transients, database query results, and rendered fragments in memory. When Varnish is fully purged (e.g., after a major site update), the object cache may still contain stale data that causes WordPress to render pages with outdated content \u2014 even though Varnish fetches fresh HTML from the backend.<\/p>\n\n<p>The integration is <strong>one-directional and limited to full purge only<\/strong>:<\/p>\n\n<ul>\n<li>When MSCache performs a full Varnish purge, it optionally calls <code>wp_cache_flush()<\/code> to clear the entire object cache.<\/li>\n<li>Single page purges do <strong>not<\/strong> trigger an object cache flush, because flushing the entire object cache for a single page change would degrade performance.<\/li>\n<\/ul>\n\n<p><strong>Use with caution on high-traffic sites:<\/strong> Flushing the object cache causes a temporary spike in database queries as WordPress rebuilds its cached queries and transients. On a high-traffic site this can briefly increase server load.<\/p>\n\n<p>The plugin auto-detects the active object cache backend (Redis, Memcached, APCu, or none) and displays it in the Integrations tab.<\/p><\/dd>\n<dt id=\"woocommerce%20integration\"><h3>WooCommerce Integration<\/h3><\/dt>\n<dd><p>WooCommerce introduces unique caching challenges: product prices change with sales and coupons, stock quantities change with every order, reviews affect displayed ratings, and pages like Cart, Checkout, and My Account contain user-specific dynamic content that must never be cached.<\/p>\n\n<p>The plugin provides a <strong>dedicated WooCommerce tab<\/strong> with granular control over each integration point:<\/p>\n\n<ul>\n<li><p><strong>Product stock changes<\/strong> \u2014 When a product's stock is updated (purchase, restock, manual edit), the product page, shop page, and all product category pages are purged. This prevents the common issue where a product shows \"In Stock\" in the cached page while it is actually sold out.<\/p><\/li>\n<li><p><strong>Scheduled sales<\/strong> \u2014 WooCommerce uses a cron job to activate and deactivate scheduled sale prices. The plugin hooks into this cron event and purges all products currently on sale plus the shop page, ensuring that sale prices and \"On Sale\" badges appear and disappear instantly.<\/p><\/li>\n<li><p><strong>Product reviews<\/strong> \u2014 When a product review is posted, approved, unapproved, or deleted, the product page and shop page are purged to reflect the updated star rating and review count.<\/p><\/li>\n<li><p><strong>Coupons<\/strong> \u2014 When a coupon is created or modified, the shop page and home page are purged. This is relevant if your shop displays coupon-dependent promotions or pricing.<\/p><\/li>\n<li><p><strong>Product attributes<\/strong> \u2014 When product attributes (Color, Size, Material, etc.) are renamed, added, or deleted, the shop page is purged to ensure filter\/navigation labels are correct.<\/p><\/li>\n<li><p><strong>Order status changes<\/strong> \u2014 When an order transitions to processing, completed, cancelled, or refunded, the plugin purges the product page, shop page, and product category pages for <strong>every product in that order<\/strong>. For example, an order with 6 products triggers purge of all 6 product pages plus their categories and the shop page, in a single deduplicated operation.<\/p><\/li>\n<li><p><strong>Auto-exclusion of dynamic pages<\/strong> \u2014 Cart, Checkout, and My Account pages are automatically detected using WooCommerce's own <code>wc_get_page_id()<\/code> function and marked with the <code>ms-cache: excluded<\/code> header. This works regardless of custom page slugs or permalink structures, without requiring manual exclusion pattern configuration.<\/p><\/li>\n<\/ul>\n\n<p>All WooCommerce hooks are registered conditionally \u2014 they only activate if WooCommerce is installed and the corresponding option is enabled. If WooCommerce is not active, the entire tab has no effect and no hooks are loaded.<\/p><\/dd>\n\n<\/dl>\n\n<!--section=changelog-->\n<h4>1.0.0<\/h4>\n\n<ul>\n<li>Initial release.<\/li>\n<li>Asynchronous raw socket PURGE via fsockopen (fire-and-forget).<\/li>\n<li>Automatic purge on post, page, and custom post type save, trash, delete, and status transitions.<\/li>\n<li>Automatic purge on comment approval, edit, and deletion.<\/li>\n<li>Automatic purge on taxonomy term edit and deletion.<\/li>\n<li>Automatic purge on nav menu, widget, and Customizer changes.<\/li>\n<li>Automatic purge on scheduled post publication (WP-Cron).<\/li>\n<li>Automatic purge on plugin, theme, and WordPress core updates.<\/li>\n<li>Automatic purge on theme switch and permalink structure change.<\/li>\n<li>Automatic purge on featured image change and media attachment updates.<\/li>\n<li>Automatic purge on frontend-affecting option changes (site title, blog page, etc.).<\/li>\n<li>REST API content update support (Gutenberg editor compatibility).<\/li>\n<li>Full cache purge with three configurable methods (wildcard, custom path, BAN).<\/li>\n<li>Additional URL list with manual and automatic purge.<\/li>\n<li>Exclusion patterns with glob and regex support, pattern tester, and ms-cache: excluded header.<\/li>\n<li>WooCommerce integration: stock, scheduled sales, reviews, coupons, attributes, orders, auto-exclusion.<\/li>\n<li>AMP page purge support (endpoint \/amp\/ and query parameter ?amp formats).<\/li>\n<li>Cloudflare CDN synchronization (per-URL, purge-everything, hybrid mode).<\/li>\n<li>Integrations with WP Rocket, FlyingPress, W3 Total Cache, Autoptimize, and Object Cache.<\/li>\n<li>WordPress Multisite support with network-level and per-site settings.<\/li>\n<li>WP-CLI commands: purge, purge-network, status, test.<\/li>\n<li>REST API endpoints for external purge triggers.<\/li>\n<li>Role-based purge permissions.<\/li>\n<li>Admin bar with server icon, status indicator, purge buttons, and Purge Page + Archives.<\/li>\n<li>Dashboard widget in WP Admin with status, purge count, and quick purge button.<\/li>\n<li>Post editor metabox with per-page purge button.<\/li>\n<li>Bulk and row actions for purging selected posts\/pages.<\/li>\n<li>Full cache purge warning modal with confirmation.<\/li>\n<li>Frontend toast notification after admin bar purge.<\/li>\n<li>Dashboard with purge statistics (7-day history), recent activity log with search, pagination, and user tracking.<\/li>\n<li>Connection test with Varnish diagnostic (version detection, response parsing).<\/li>\n<li>Import\/Export settings as JSON.<\/li>\n<li>Debug logging to protected files with daily rotation and admin log viewer.<\/li>\n<li>Tabbed settings interface with Dashicons, tooltips, and responsive design.<\/li>\n<li>Security: CRLF injection prevention, ReDoS protection, SSRF blocking, log injection sanitization.<\/li>\n<li>Translations: English, Italian, French, German, Spanish.<\/li>\n<li>PHP 7.0+ and PHP 8.x compatible.<\/li>\n<li>GPLv2 or later license.<\/li>\n<\/ul>","raw_excerpt":"Purge Varnish cache from the WordPress admin: automatic purge on content changes, exclusions, manual tools and full cache purge.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/cn.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/299720","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cn.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/cn.wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/cn.wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=299720"}],"author":[{"embeddable":true,"href":"https:\/\/cn.wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/dreamsnet"}],"wp:attachment":[{"href":"https:\/\/cn.wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=299720"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/cn.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=299720"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/cn.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=299720"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/cn.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=299720"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/cn.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=299720"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/cn.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=299720"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}