內容簡介
Prevent Browser Caching 外掛可確保訪客始終載入網站的最新版本，避免因瀏覽器快取而顯示舊版內容。它在不禁用快取的情況下，提升網站更新的即時性，讓使用者體驗更流暢。
【主要功能】
• 自動更新 CSS 和 JS 版本
• 更新媒體庫中的圖片版本
• 確保 HTML 頁面新鮮度
• 一鍵更新所有資源版本
• 與多種快取外掛兼容
• 提升重複訪問的速度
外掛標籤
開發者團隊
原文外掛簡介
You changed the site, but a client or visitor still sees the old version and you have to say “please clear your browser cache”? This plugin makes that conversation unnecessary.
Prevent Browser Caching makes sure browsers always load the current version of your site — without disabling browser caching and slowing the site down.
What it does
CSS & JS versions. WordPress loads assets with a “ver” URL parameter (e.g. style.css?ver=4.9.6). Browsers cache the file until this parameter changes. In the recommended automatic mode the plugin sets the version from the file’s own modification time: browser caching works at full strength, and the moment you update a file every visitor gets the new one.
Image versions. When you edit or replace a file in the Media Library, visitors get the new image instead of the cached one.
HTML page freshness. Asks browsers to check for a newer version of a page before showing a cached copy — fixes “I still see the old page on my phone”.
One-click update. The “Update versions” toolbar button forces fresh copies of all assets for every visitor — and shows a short report of what exactly happened.
Page cache stays in sync (opt-in). If a page-cache plugin is active, updating versions can also clear its cache — so cached HTML stops referencing the old file versions and every visitor sees the new site immediately. One checkbox turns it on, and after every update the plugin reports what was refreshed and what happened to the page cache. Works with WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, WP Fastest Cache, WP-Optimize, Breeze, Cache Enabler, Hummingbird, SiteGround Optimizer, Swift Performance and Comet Cache.
Faster repeat visits (opt-in, new in 3.2). Because versioning guarantees freshness, the plugin can safely serve your static files with one-year browser caching headers — the exact fix for the Lighthouse audit “Serve static assets with an efficient cache policy”. It writes the rules through WordPress’s own .htaccess API on Apache/LiteSpeed (removed again on deactivation), shows a ready-to-copy snippet for nginx, and then actually fetches one of your CSS files to verify the headers really work — the result is shown on the settings page.
Auto refresh after updates (opt-in, new in 3.2). Plugin, theme and WordPress updates change CSS and JS files. With this option every update — including automatic background updates — is followed by a version refresh (and a page-cache clear when that option is on), so visitors never see a broken layout after an update.
CLI & AI agents. WP-CLI commands (wp pbc update, wp pbc status) and WordPress Abilities let deploy scripts and AI agents update versions safely.
Safe by default
External URLs (payment scripts, CDNs, third-party services) are left untouched — some of them break when an unexpected “ver” parameter is added. You can turn external versioning back on with one checkbox.
Specific files (by part of the URL) or script/style handles can be excluded from versioning — CSS, JS and images alike.
If a page-cache plugin is active, the HTML freshness headers step aside automatically.
Another plugin’s page cache is never cleared unless you enable that yourself — the purge-on-update integration is opt-in, and the report after every update tells you whether the page cache was cleared or left alone.
The long-caching headers are opt-in too, and only available while CSS/JS versioning is on — the plugin never lets browsers hold files for a year without a way to bust them. Disabling the option (or deactivating the plugin) removes the rules completely.
Update modes
Automatically, when a file changes (recommended) — version = file modification time. Zero clicks, full caching.
Every time a page loads — development mode: CSS & JS are never cached (images and pages are unaffected). Use it only while actively developing.
Manually — versions change only when you press the “Update versions” button.
For developers
The recommended way to set the CSS/JS version from code is the pbc_assets_version filter. Add this to the functions.php file of your theme and change the value whenever you need to update assets:
add_filter( 'pbc_assets_version', function( $ver ) {
return '123';
} );
Because it uses WordPress’s own add_filter(), it keeps working safely even if the plugin is ever deactivated — your site won’t break.
Filters for fine-tuning:
pbc_skip_src( $skip, $src, $handle ) — return true to leave a given asset URL untouched.
pbc_assets_version( $ver, $src, $handle ) — change the version applied to a given asset.
pbc_purge_page_cache( $purge, $plugin_name ) — return false to prevent the page-cache purge on version updates.
pbc_after_bump( $result ) — action fired after every version update, with the new timestamp and the purge outcome.
pbc_cache_policy_rules( $rules, $options ) — change the generated long-caching rules before they are written to .htaccess (or shown as a snippet).
pbc_after_auto_bump( $context ) — action fired after an automatic post-update refresh, with the update type and the purge outcome.
PBC_DISABLE_HTACCESS_WRITE — define this constant as true (e.g. in wp-config.php) and the plugin will never write to .htaccess itself; the settings page shows the rules for manual setup instead.
WP-CLI
wp pbc update — updates the versions (and clears the detected page cache when the settings option is on). Add --skip-purge to leave the page cache alone for that run.
wp pbc status — shows the mode, what is versioned, the last manual update and the detected page-cache plugin. Supports --format=table|json|yaml.
Abilities (AI agents & automation)
On WordPress 6.9+ the plugin registers two Abilities, discoverable via the Abilities API, REST and the MCP adapter — so AI agents and site-management tools can operate the plugin without custom glue code:
prevent-browser-caching/bump-versions — update the versions; optional boolean input purge (set false to skip the page-cache purge).
prevent-browser-caching/status — read-only report of the current configuration.
Both require the manage_options capability.
Legacy: earlier versions documented a prevent_browser_caching() function instead. It still works exactly as before — it disables the plugin’s admin settings and gives you full control — but I recommend the filter above: a bare function call in functions.php triggers a fatal error if the plugin is ever deactivated. If you keep using the function, guard it:
if ( function_exists( 'prevent_browser_caching' ) ) {
prevent_browser_caching( array(
'assets_version' => '123'
) );
}
Thank you
Many of the recent improvements started as reports and questions in the support forum — thank you to everyone who took the time to describe a problem or share an idea. If something doesn’t work as expected on your site, please open a topic there: it genuinely helps make the plugin better for everyone.
