| 开发者 | apos37 |
|---|---|
| 更新时间 | 2026年10月24日 05:05 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
/wp-content/plugins/clear-cache-everywhere/ directory.It executes multiple cache-clearing actions across WordPress core, object caching systems, server-level caching, browser cache, and supported third-party plugins. Individual actions can be triggered independently.
Clearing cache is not just a single action. When you click “Clear All,” the plugin may be flushing multiple cache layers: object cache, persistent cache (Redis/Memcached), OPcache, reverse proxies like Varnish, REST caches, transients, sessions, and third-party integrations. Each layer operates differently and may require disk I/O, memory resets, or network requests. On larger sites, clearing cache can take longer because: • Persistent object caches may contain thousands of keys that must be invalidated. • OPcache must reload compiled PHP scripts into memory. • Reverse proxies and CDNs require network-based purge requests. • Transients and fragment caches may involve large amounts of stored data. After cache is cleared, the site must rebuild it. Themes and plugins will: • Re-run expensive database queries. • Recompile templates. • Regenerate CSS/JS assets. • Rebuild REST responses. • Recreate transients and computed data. This recaching happens on the next page load and can temporarily slow down the first request after a purge. That is expected behavior. If you find that clearing everything takes longer than you prefer, certain actions (such as Transients) can be disabled from the “Clear All” button and admin bar in the settings. They can still be cleared independently from the settings page when needed. In some cases, you may not need to clear every layer. For example, content edits typically do not require transients or OPcache to be reset. Selectively clearing only what is necessary can significantly reduce execution time.
This depends on your hosting provider. If they offer a cache purge URL, you can configure it in the plugin settings. For example, if you have GoDaddy's Website Security and Backups, you can navigate to Firewall > Settings > Performance > Clear Cache, then grab the Clear Cache API link to put in your settings.
Yes! The plugin sends cache-control headers to prompt browsers to reload updated content.
Yes. Developers can hook into the clearing process to add custom actions or settings. Full developer documentation is available here: https://pluginrx.com/docs/plugin/clear-cache-everywhere/
Yes! A helper function is available for you to use: cceverywhere_clear_all( $log_results = false ).
The function returns the results of the cache clearing processing. Optionally, you can log the results by setting the $log_results parameter to true. This will log the results to the debug log. Results from this function also appear in the Logs tab, labeled "Helper Function."
Open the Logs tab in the plugin header. Failures are always logged with the action, where it was triggered from (settings page, admin bar, individual button, URL, cron, or helper function), the duration, and the error. HTTP errors such as a 500 include the response, and PHP fatals include the file and line.
Not by default. Turn on Log Successful Clears in the Logs settings at the bottom of the Settings tab if you want a full history. Logs are deleted automatically after the number of days set in Clear Logs After (Days), which defaults to 30. You can also delete entries manually from the Logs tab.
It prints each clearing request's response to your browser's developer console, which is useful for troubleshooting and verifying that everything has actually been cleared while on the front-end. It is on by default and can be turned off in the Logs settings.
We recommend using our website support forum as the primary method for requesting features and getting help. You can also reach out via our Discord support server or the WordPress.org support forum, but please note that WordPress.org doesn’t always notify us of new posts, so it’s not ideal for time-sensitive issues.
rt_nginx_helper_purge_all action hookfunction_exists() on a class method, which never evaluates true; now uses method_exists()is_plugin_active(), so unverified or version-mismatched integrations no longer surface as failing checkboxescceverywhere_clear_all() helper function now correctly supports the $log_results parametermethod_exists() instead of function_exists()clear_all() for requests coming through the URL parameterwordpress_sec_* and wp-settings-* are now preserved when clearing cookieshref attribute from Clear Cache button on settings pageget_clearing_actions() now caches its result to avoid redundant calls per requestcceverywhere_clearing_actions filter to allow modifying the actions array programmaticallycceverywhere_before_clear and cceverywhere_after_clear hookscceverywhere_before_clear_cache and cceverywhere_after_clear_cache removedcceverywhere_custom_settings hook updated to accept run_context and callback hooks, please see updated developer docsshow_skipped_notice hook