Disable Automatic Full Cache Purge on Global Updates
By default, Super Page Cache purges the entire site cache when global changes are saved — such as editing a navigation menu, switching a theme, or saving Customizer settings. On large sites (50,000+ cached URLs), each of these events can trigger a full purge that overwhelms the server and causes CPU spikes. This guide explains how to selectively disable those automatic full purges while keeping manual purge control intact.
📝 Note: This guide addresses purges triggered by menu, theme, and Customizer updates. For purges triggered by post or page saves, see Optimizing Super Page Cache for Large Sites.
In this article
When to Use This Workaround
This workaround is appropriate when you can confirm that full cache purges are being triggered specifically by global element changes rather than by content edits.
Symptoms
- CPU spikes immediately after saving a navigation menu, switching a theme, or saving changes in the WordPress Customizer.
- Server becomes slow or unresponsive for several seconds to minutes after those changes — even when no posts were edited.
- Site performance degrades during routine admin tasks like updating a menu item or adjusting a global header or footer.
Confirm via plugin logs
Before adding any code, verify that the purges are actually originating from these global events:
- Go to Super Page Cache > Settings, open the General tab, and enable Show advanced settings. Click Save Settings.
- Go to the Advanced tab, scroll to the Logs Settings section, and enable Log mode. Click Save Settings.
- Save a menu change: go to Appearance > Menus, make a small edit, and click Save Menu.
- Download the log file (the download link appears in the Logs Settings section) and look for a full-cache purge entry recorded at the time of the menu save.
If the log shows a full purge triggered immediately by the menu save (or a theme/Customizer save), use the filter below to control that behavior.
Use the Supported Filter
Super Page Cache includes the public swcfpc_purge_cache_on_theme_edit filter for controlling global full-cache purges. It runs before a global-change purge and receives:
$should_purge(bool) — the default purge decision.$current_action(string) — the WordPress action that triggered the purge.$auto_purge_whole(bool) — whether Purge whole cache is selected in Super Page Cache > Settings > Advanced > Cloudflare Cache Behavior > Automatically Purge Cloudflare's Cache When Something Changes.
This filter is triggered for these actions:
wp_update_nav_menuupdate_option_theme_mods_{stylesheet}avada_clear_dynamic_css_cacheswitch_themecustomize_save_afterpermalink_structure_changed
⚠️ Important: Test this change on a staging environment before applying it to production. If your filter skips a global-change purge, manually purge the cache after that change to ensure visitors see updated content.
Disable all global full-cache purges
Use this when you want to skip every full purge triggered by the global actions listed above:
add_filter( 'swcfpc_purge_cache_on_theme_edit', '__return_false' );Skip only navigation menu saves
Use this when you want to keep the default behavior for all other global actions:
add_filter(
'swcfpc_purge_cache_on_theme_edit',
static function ( $should_purge, $current_action ) {
return 'wp_update_nav_menu' === $current_action ? false : $should_purge;
},
10,
2
);Purge only when whole-cache mode is selected
Use this when you want global changes to purge the full cache only if Purge whole cache mode is selected:
add_filter(
'swcfpc_purge_cache_on_theme_edit',
static function ( $should_purge, $current_action, $auto_purge_whole ) {
return $auto_purge_whole;
},
10,
3
);Add the selected snippet to a site-specific plugin, an MU plugin, or your child theme's functions.php. An MU plugin is recommended for production because it cannot be accidentally deactivated and is not removed by a theme update.
Verification Steps
After adding the code, confirm that your selected global actions no longer trigger an automatic full purge and that manual purging still works.
Test that menu updates no longer trigger a full purge
- Make sure Log mode is still enabled (Super Page Cache > Settings > Advanced > Logs Settings).
- Go to Appearance > Menus, change a menu item label, and click Save Menu.
- Download the updated log file and check the entries recorded at the time of the save.
- Confirm that no full-cache purge appears in the log for that event.
Manually purge the cache after the menu update
Because automatic purging is now disabled for these events, you need to purge the cache manually after updating a menu, theme, or Customizer settings:
- In the WordPress admin toolbar, click Super Page Cache.
- Select Purge whole cache to clear the Cloudflare cache for the whole site, or use the plugin's dashboard button at Super Page Cache > Dashboard.
- Visit the pages that display the updated menu or theme change in an incognito or private browsing window to confirm that the new content is visible.
Confirm manual purging still works
- After running a manual purge, download the log file again.
- Confirm that a full-cache purge entry appears in the log — this verifies that manual purges are functioning normally.
Caveats and Alternatives
Manual purge required after skipped global changes. When your filter returns
falsefor a global action, Super Page Cache will not automatically clear the cache for that event. You must purge the cache manually after those changes. Visitors will see stale content until you do.Post and page purges are unaffected. This filter only controls global element events. Purges triggered by post saves, comment updates, and other content changes continue to work as configured.
Theme updates. If you add the snippet to
functions.php, it will be removed if you update or replace your theme. Using a must-use plugin avoids this problem.For post-related purge optimizations, see Optimizing Super Page Cache for Large Sites, which covers smart purging, queue settings, and preloader management.
⚠️ Important: If your site displays dynamic or personalized menus and theme elements (for example, WooCommerce cart counts in a header), always test thoroughly after adding this code to ensure cached pages still show the correct content for your visitors.
