HTL Clear All Cache

Description

HTL Clear All Cache (by Hash Tech Logic) is a lightweight, standalone cache manager for WordPress. It clears the cache layers your site can actually control, detects the ones it cannot, and always tells you exactly what happened.

Clear what you control. Detect what you don’t.

It does not need WooCommerce, Elementor, WP Rocket, LiteSpeed Cache, W3 Total Cache or any other plugin. When one of those is present, the plugin detects it and can optionally ask it to purge its own cache through its public API, but only after you turn that on.

Features

• Clear All Cache in one click, with a clear summary: what was cleared, what was skipped (not available) and what failed.
• Individual clearing for each cache, plus Clear Selected with checkboxes.
• Admin Bar quick menu on the dashboard and on the front end: Clear All, Clear Plugin Cache, Clear Transients, Clear Object Cache (when available) and Cache Settings. Results appear in a small notification without reloading the page.
• Cache environment scanner: WordPress, persistent object cache, Redis, Memcached, APCu, page-cache drop-ins, cache plugins, hosting cache, PHP OPcache and CDNs that are visible in response headers.
• Automatic clearing after content is published, updated or deleted, after theme, plugin and WordPress updates, after theme switches, after Customizer changes and after selected settings pages are saved. Every trigger can be turned on or off individually, and several changes in one request cause just one clear.
• Statistics: plugin cache size and file count, transients in the database, object cache type, number of clear operations, last duration and times cleared per cache.
• Activity log with time, action, source, result, duration, per-cache messages and the user who ran it. Retention period and maximum size are configurable.
• Optional browser cache-busting for your CSS and JavaScript files.
• Multisite aware: each site has its own settings, log and plugin cache. Actions from one site never affect other sites unless a network administrator explicitly allows it.
• Modular: every cache type is a module behind one contract, so new integrations can be added without changing the core.

Cache modules

• Plugin Cache – a namespaced cache folder fully controlled by this plugin (wp-content/cache/cache-clearing/site-{ID}/). Themes and plugins can store data in it through a small developer API. Its size and file count are shown on the dashboard.
• Transients – temporary data stored in the database by WordPress, themes and plugins. By default only expired transients are removed. You can choose to remove all transients instead.
• Object Cache – a persistent object cache such as Redis or Memcached, flushed only through the WordPress object cache API (wp_cache_flush()). If none is active it shows “Not detected”.
• Browser Cache-Busting (optional, off by default) – adds a version token to your site’s CSS and JavaScript URLs so browsers download fresh copies after a clear.
• Integrations (optional, off by default) – WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, WP Fastest Cache, Cache Enabler, SiteGround Speed Optimizer, Nginx Helper, Autoptimize and Elementor CSS files. Each one only calls that plugin’s own public purge function or action.

What this plugin never does

• It never reports a cache as cleared when the operation failed.
• It never deletes another plugin’s cache folders or files.
• It never accepts a file path from a form and never deletes files outside its own folder.
• It never runs shell commands.
• It never claims to delete a visitor’s browser cache (no website can do that).
• It never mixes database optimization into “Clear All Cache”.

Usage

Dashboard

• Clear All Cache clears every cache that is available and safe on this site.
• The cache status cards show each cache’s state, size and details, with its own clear button.
• Clear Selected lets you tick exactly which caches to clear.
• Statistics and Recent activity show what happened and when.
• Scan Cache Environment opens the Environment page with fresh results.

Environment

Click Scan Cache Environment to see which cache layers are active. The scan only reads information and never changes anything. It loads your homepage once, as a logged-out visitor, to look for page-cache and CDN headers.

Logs

Shows every clear, scan and settings reset with its result and details. Use Clear Logs to delete all entries.

Settings

• Automatic Clearing – choose the triggers and which caches they clear. By default automatic clears only touch the lightweight plugin cache and expired transients.
• Admin Bar – show or hide the quick menu, on the dashboard and on the front end.
• Cache Behaviour – clear expired transients only (recommended) or all transients.
• Integrations – turn on supported cache plugins you want to purge from here.
• Logging – turn the log on or off, include or exclude automatic clears, and set retention (1–365 days) and maximum entries (10–500).
• Advanced – browser cache-busting and, on multisite, whether the shared object cache may be flushed.
• Reset Settings – restore every default. Logs, statistics and cached data are kept.

Troubleshooting

The Plugin Cache card says “Not writable”

WordPress cannot create or write to wp-content/cache/cache-clearing/. Ask your host to make wp-content/cache/ writable by the web server. The other caches still work.

“Safety check failed: the plugin cache folder could not be verified”

The folder is missing its marker file or has been replaced by a link to another location, so nothing was deleted. Deactivate and reactivate the plugin to recreate the folder safely.

“Another cache-clearing operation is already running”

Two clears were started at the same time. Wait a few seconds and try again. A lock left behind by a crashed request expires automatically after two minutes.

The object cache flush failed

The cache server did not confirm the flush. Check that Redis or Memcached is running and that the connection settings of your object cache plugin are correct. The Environment page shows the connection state when the drop-in reports it.

The homepage check on the Environment page failed

Your server could not load its own homepage (a “loopback request”). This is common on local development servers and some firewalled hosts. The rest of the scan still works.

The Admin Bar menu is missing

Check Settings → Admin Bar, make sure the Admin Bar is shown for your user in your profile, and that you are an administrator.

An integration shows “failed”

The other plugin is active but did not register its public purge function or action, for example because its caching is switched off in its own settings. Nothing was purged, so the plugin reports a failure instead of pretending it worked.

Security

• Every action checks the user’s capability and a WordPress nonce, including Admin Bar links and background (AJAX) requests. There are no actions for logged-out visitors.
• All input is sanitized and validated against known values. Cache types are chosen from a fixed list; file paths are never accepted from users.
• All output is escaped. Background requests return HTML rendered and escaped by the server, and scripts insert text with textContent.
• Database queries use $wpdb->prepare() and only touch transient rows of the current site.
• The plugin cache folder is fixed in code, verified with realpath() and a marker file before anything is deleted, and symbolic links are never followed. Only files matching the plugin’s own naming pattern are deleted. Cache files start with <?php exit; ?>, are protected by .htaccess and index.php, are stored as JSON and are never included or executed.
• Redirects after an action use wp_safe_redirect() and only go back to pages on this site. Result notices are one-time, private to the user who ran the action and expire after five minutes.
• The log stores no passwords, secrets, IP addresses or e-mail addresses, only the numeric user ID. Error messages are redacted before saving.
• No shell commands are executed and no external services are contacted. The only outgoing request is the optional environment scan of your own homepage.

Compatibility

• WordPress 6.1 or newer (tested up to 7.1), PHP 7.4 or newer (tested on PHP 8.4).
• Works with block themes and classic themes. Changes to block theme templates, template parts, global styles and navigation also trigger automatic clearing.
• Works with and without a persistent object cache. Tested with Redis Object Cache.
• Multisite: settings, logs and the plugin cache are per site. Network-wide operations (object cache flush and integrations that may purge every site) are only possible after a network administrator allows them. There is no network admin screen in version 1; manage caches from each site’s dashboard.
• Works without JavaScript: every button also works as a normal form or link.
• The “Update URI” plugin header prevents WordPress from offering updates for an unrelated WordPress.org plugin with the same folder name. Remove that header if you publish this plugin on WordPress.org.

For developers

Store data in the plugin cache

cache_clearing_set( 'key', $value, 'my-group', HOUR_IN_SECONDS );
$value = cache_clearing_get( 'key', 'my-group', $default );
cache_clearing_delete( 'key', 'my-group' );

Values must be JSON-serializable. Everything stored this way is removed when the Plugin Cache is cleared.

Clear everything from code

$result = cache_clearing_clear_all(); // Returns a Cache_Clearing\Operation_Result.

This makes no capability check, so only call it from code that is already authorized.

Add your own cache module

Implement Cache_Clearing\Cache_Module_Interface (or extend Cache_Clearing\Modules\Abstract_Module) and register it:

add_action( 'cache_clearing_register_modules', function ( $manager ) { $manager->register_module( new My_Module( cache_clearing()->settings() ) ); } );

Hooks

• cache_clearing_capability (filter) – capability required to use the plugin. Default manage_options.
• cache_clearing_register_modules (action) – register cache modules.
• cache_clearing_integrations (filter) – add or remove external integrations.
• cache_clearing_clear_all_modules (filter) – module IDs included in Clear All.
• cache_clearing_before_clear / cache_clearing_after_clear (actions) – run code around a clear.
• cache_clearing_auto_clear_post_types (filter) – post types whose changes trigger automatic clearing.
• cache_clearing_protected_transients (filter) – transient names that are never deleted.