Title: Prevent Browser Caching
Author: Kostya Tereshchuk
Published: 30 outubro, 2017
Last modified: 15 julho, 2026
---
Pesquisar plugins
# Prevent Browser Caching
Por [Kostya Tereshchuk](https://profiles.wordpress.org/kostyatereshchuk/)
[Baixar](https://downloads.wordpress.org/plugin/prevent-browser-caching.3.2.1.zip)
[Pré-visualização ao vivo](https://br.wordpress.org/plugins/prevent-browser-caching/?preview=1)
* [Detalhes](https://br.wordpress.org/plugins/prevent-browser-caching/#description)
* [Avaliações](https://br.wordpress.org/plugins/prevent-browser-caching/#reviews)
* [Instalação](https://br.wordpress.org/plugins/prevent-browser-caching/#installation)
* [Desenvolvimento](https://br.wordpress.org/plugins/prevent-browser-caching/#developers)
[Suporte](https://wordpress.org/support/plugin/prevent-browser-caching/)
## Descrição
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](https://wordpress.org/support/plugin/prevent-browser-caching/)—
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.
## Capturas de tela
[⌊The settings page: choose what to keep fresh, when to update versions (including
automatically after plugin/theme/WordPress updates), whether to also clear the detected
page cache, and whether browsers may keep static files for a year — with the header
verification result right on the page.⌉⌊The settings page: choose what to keep fresh,
when to update versions (including automatically after plugin/theme/WordPress updates),
whether to also clear the detected page cache, and whether browsers may keep static
files for a year — with the header verification result right on the page.⌉[
The settings page: choose what to keep fresh, when to update versions (including
automatically after plugin/theme/WordPress updates), whether to also clear the detected
page cache, and whether browsers may keep static files for a year — with the header
verification result right on the page.
[⌊Upgrading from 2.x: your settings keep working as before, and one click enables
the recommended setup (reversible).⌉⌊Upgrading from 2.x: your settings keep working
as before, and one click enables the recommended setup (reversible).⌉[
Upgrading from 2.x: your settings keep working as before, and one click enables
the recommended setup (reversible).
[⌊After a manual update the plugin reports what was refreshed and what happened
to the page cache.⌉⌊After a manual update the plugin reports what was refreshed
and what happened to the page cache.⌉[
After a manual update the plugin reports what was refreshed and what happened to
the page cache.
## Instalação
#### From WordPress dashboard
1. Visit “Plugins > Add New”.
2. Search for “Prevent Browser Caching”.
3. Install and activate Prevent Browser Caching plugin.
#### From WordPress.org site
1. Download Prevent Browser Caching plugin.
2. Upload the “prevent-browser-caching” directory to your “/wp-content/plugins/” directory.
3. Activate Prevent Browser Caching on your Plugins page.
## Perguntas frequentes
### Does it affect site speed or SEO?
It can only help. In the recommended automatic mode browser caching keeps working
at full strength — repeat visitors load CSS/JS from their cache until a file really
changes, so repeat views are as fast as ever (faster than the old 2.x default, which
re-downloaded assets on every visit). And the opt-in “Speed up” option goes further:
one-year caching headers for your static files — the exact fix for the Lighthouse“
efficient cache policy” audit. The server cost is a few file-time lookups per page—
negligible. The “ver” URL parameter is the same mechanism WordPress core uses, search
engines are perfectly used to it, and the plugin does not change your page content,
markup or URLs seen by crawlers.
### Does it work together with page caching plugins?
Yes — and since 3.1.0 they can actively cooperate. Versioned asset URLs end up in
the cached HTML like any others, so serving stale HTML used to mean serving old
asset versions with it. When the “Also clear the page cache” checkbox on the settings
page is enabled, pressing “Update versions” (toolbar, settings page, WP-CLI or an
ability) also clears the detected page-cache plugin’s cache, so that HTML is regenerated
with the new versions. Supported: WP Rocket, LiteSpeed Cache, W3 Total Cache, WP
Super Cache, WP Fastest Cache, WP-Optimize, Breeze, Cache Enabler, Hummingbird,
SiteGround Optimizer, Swift Performance, Comet Cache. The checkbox is off by default—
another plugin’s cache is only touched when you say so (for example, if your page
cache serves logged-out visitors only, you may prefer not to rebuild it on every
update). Either way, the report shown after every update says whether the page cache
was cleared, and the version update always completes even if a purge fails. The
plugin also keeps leaving HTML cache headers to the page-cache plugin.
### Does it work with page builders (Elementor, Divi, Beaver Builder…)?
Yes. Builders generate their CSS as real files (usually in the uploads folder) and
give them a fresh time-based version whenever they regenerate — Elementor, for example,
serves its per-page CSS as `post-123.css?ver=`, and that version
changes every time the file is rewritten. On top of that, in the automatic mode
this plugin adds its own version component from the file’s modification time, so
even a builder file rewritten in place busts its cache immediately. Together that
makes the long-caching option safe for builder files too: their URLs always change
when their content does.
### Does it work with minification plugins (Autoptimize, WP-Optimize)?
Yes — verified against both. Minifiers put a content hash and the source files’
modification times into their generated file names, so those files bust their own
cache by name — and the long-caching option here is exactly the right policy for
them: WP-Optimize’s minified CSS/JS get the one-year headers and change URL whenever
a source file changes, while Autoptimize serves its cache folder with its own equivalent
one-year immutable policy, so the two never fight. Files the minifier leaves untouched
keep this plugin’s “ver” parameter — even when the minifier’s “remove query strings”
option is on (this plugin adds its version after them on purpose).
### Does the automatic mode clear my page cache when a file changes?
No — and that’s by design, not an oversight. In the automatic mode the version comes
from the file’s modification time, read at the moment a page is rendered; nothing“
happens” on the server when you upload a changed file, so there is no event to clear
the page cache on. Cached HTML keeps the old asset versions until the page cache
expires or is cleared. After bigger changes, press “Update versions” — with the “
Also clear the page cache” option enabled, that both updates the versions and clears
the detected page cache in one click.
### How do I fix the Lighthouse audit “Serve static assets with an efficient cache policy”?
Enable “Let browsers keep static files for a year” in the “Speed up” section of
the settings page (available while CSS/JS versioning is on). The plugin serves static
files with `Cache-Control: public, max-age=31536000, immutable`, which is exactly
what the audit asks for — and it is safe here, because the plugin changes a file’s
URL whenever the file changes, so visitors never get stuck with an outdated copy.
After enabling, the settings page tells you whether the headers were verified on
your site. The same option also resolves the older name of this recommendation —“
Leverage browser caching” — still shown by GTmetrix and other testing tools.
### Does the plugin edit my .htaccess?
Only if you enable the long-caching option, and only using WordPress’s own API (
the same one core uses for permalinks): a clearly marked block between `# BEGIN
Prevent Browser Caching` and `# END Prevent Browser Caching`. The block is updated
when you change related settings, and removed completely when you turn the option
off, deactivate or delete the plugin. On multisite, on nginx, or if you define the`
PBC_DISABLE_HTACCESS_WRITE` constant, the plugin never writes the file — it shows
you the rules to add manually instead.
### My caching plugin already adds browser-caching (expires) headers. Do I need both?
No — manage them in one place. If your caching plugin already serves long-lived
headers for static files, you can leave the “Speed up” option here off: versioning
keeps everything fresh either way. Nothing breaks if both end up enabled — the rules
don’t conflict, the later block simply wins — but a single source is cleaner. The
advantage of managing them here is that the headers are tied to versioning (URLs
change whenever files change, so a year-long cache can never show anyone an outdated
file) and the settings page verifies that the headers actually work on your server.
### The settings page says the caching headers are not showing up. What now?
The rules are in place, but your server did not apply them — most often the host’s
Apache lacks the `mod_headers`/`mod_expires` modules, or `.htaccess` overrides are
disabled. Ask your host to enable them, or copy the rules shown on the settings
page into the server configuration. Saving the settings re-runs the check. Until
the headers work, nothing breaks — browsers simply keep caching the way they did
before.
### I excluded a file from versioning — will it still be cached for a year?
If it is a local CSS/JS file served from your site: yes, the long-caching rules
work by file extension and cannot see your exclusion list. Exclusions are almost
always external URLs (payment scripts, CDNs), which the rules never touch — but
if you exclude a local file because it must not be cached long, either keep the
long-caching option off or add a narrower rule for that file in your server configuration.
### Why don’t external files get a version by default?
Several external services — payment scripts in particular (PayPal, Braintree, Authorize.
net) — reject requests with an unexpected “ver” query parameter, which used to break
checkout forms. Since 3.0.0 only local files are versioned by default; there is
a checkbox to include external URLs again if you relied on that.
### Do I lose browser caching with this plugin?
Not in the recommended automatic mode. Files are cached normally; the version only
changes when the file itself changes. The “every time a page loads” mode does disable
caching of CSS/JS — use it during active development only.
### The version does not update every X minutes as I set it. Why?
The legacy “every N minutes” mode works per visitor, using a cookie — it does not
rebuild anything on the server by cron. Each visitor gets a new assets version no
more often than the chosen interval. Since 3.0.0 the automatic mode is a better
choice for almost every case.
### Does it version images inside post content?
Yes, when “Images” is enabled: attachment URLs rendered by WordPress get versions
immediately, and image URLs hardcoded in post content get the site-wide media version
after the first update (the “Update versions” button or replacing a media file).
### My CDN ignores query strings.
Then query-parameter versioning cannot bust that CDN’s cache for those files. Configure
the CDN to include query strings in its cache key, or use filename-based versioning(
e.g. replace a file under a new name).
### My site shows an error after I deactivate the plugin.
If you added `prevent_browser_caching( ... )` to your theme’s functions.php, that
line calls a function this plugin provides. Once the plugin is deactivated the function
no longer exists, so PHP stops with a fatal error. Two ways to fix it: switch to
the `pbc_assets_version` filter (recommended — it never causes this), or wrap the
call in `if ( function_exists( 'prevent_browser_caching' ) ) { ... }`. See “For
developers” above.
## Avaliações
### [Continues to get better and better](https://wordpress.org/support/topic/continues-to-get-better-and-better/)
[Sea Jay](https://profiles.wordpress.org/jcollier/) 7 julho, 2026
The new features in 3.x versions raise a very good plugin to excellent! A must to
empty users’ browser caches after we make big design changes. Thank you!
### [Very good](https://wordpress.org/support/topic/very-good-7474/)
[robertorefresh](https://profiles.wordpress.org/robertorefresh/) 25 novembro, 2024
It works great!
### [Best Cache Plugin ever](https://wordpress.org/support/topic/best-cache-plugin-ever-16/)
[rompikapo](https://profiles.wordpress.org/rompikapo/) 17 maio, 2024
It is the first plugin that I install every time I create a new site, this plugin
is the web designer’s best friend, it instantly clears the browser cache and refreshes
the page with one click, saving me a lot of time when I update and design the site,
avoiding long trips in the browser, also works to show the page to customers, a
heartfelt thank you.
### [MAGIC!!!](https://wordpress.org/support/topic/magic-64/)
[teacherdesigner](https://profiles.wordpress.org/hoffkids/) 29 outubro, 2023
10-30-23 I do not how this thing does it, but it just solved my problem that was
bothering me for weeks and my hosting co could not help. I added this plugin (did
not even need to change a setting) and now my changes show up on websites especially
the CSS. thank you so much- you are so helpful and what you created is valuable!!!
### [O unico que funciona!](https://wordpress.org/support/topic/o-unico-que-funciona/)
[mdknet](https://profiles.wordpress.org/mdknet/) 14 março, 2023
Fui obrigado a logar no forum para avaliar, é o unico plugin que realmente limpa
o css e js, sempre que preciso estou aqui instalando
### [Lifesaver – will now use for all dev work](https://wordpress.org/support/topic/lifesaver-will-now-use-for-all-dev-work/)
[mrsminkie](https://profiles.wordpress.org/mrsminkie/) 27 fevereiro, 2023
I found this plugin while searching for a way to prevent CSS files from caching
while working with a particularly annoying theme (A****). This works perfectly and
I will use it on every website I’m developing from this point forwards. Thank you!
[ Leia todas as 29 avaliações ](https://wordpress.org/support/plugin/prevent-browser-caching/reviews/)
## Colaboradores e desenvolvedores
“Prevent Browser Caching” é um programa de código aberto. As seguintes pessoas contribuíram
para este plugin.
Colaboradores
* [ Kostya Tereshchuk ](https://profiles.wordpress.org/kostyatereshchuk/)
Prevent Browser Caching” foi traduzido para 8 localidades. Agradecemos aos [tradutores](https://translate.wordpress.org/projects/wp-plugins/prevent-browser-caching/contributors)
por suas contribuições.
[Traduzir o “Prevent Browser Caching” para seu idioma.](https://translate.wordpress.org/projects/wp-plugins/prevent-browser-caching)
### Interessado no desenvolvimento?
[Navegue pelo código](https://plugins.trac.wordpress.org/browser/prevent-browser-caching/),
consulte o [repositório SVN](https://plugins.svn.wordpress.org/prevent-browser-caching/)
ou assine o [registro de desenvolvimento](https://plugins.trac.wordpress.org/log/prevent-browser-caching/)
por [RSS](https://plugins.trac.wordpress.org/log/prevent-browser-caching/?limit=100&mode=stop_on_copy&format=rss).
## Registro de alterações
#### 3.2.1
* Fixed: a caching plugin that is installed but has its page caching switched off(
for example WP-Optimize used only for database cleanup or image compression)
is no longer treated as an active page cache. The “… is active, so page caching
headers are left to it” note and the “Also clear the page cache” option now appear
only when page caching is really enabled, and the “Pages (HTML)” option works
in that situation instead of silently stepping aside. The check mirrors each
supported plugin’s own on/off state and safely falls back to the previous behavior
when that state can’t be read. Props @jcollier for the report.
#### 3.2.0
* New: “Let browsers keep static files for a year” (opt-in, in the new “Speed up”
settings section) — serves CSS, JS, fonts and images with long-lived `Cache-Control`/`
Expires` headers. Safe by design: versioned URLs change whenever a file changes,
so visitors still get updates immediately. Fixes the Lighthouse audit “Serve
static assets with an efficient cache policy”. On Apache/LiteSpeed the rules
are written through WordPress’s own .htaccess API and removed again when the
option is turned off or the plugin is deactivated/deleted; on nginx and multisite
the settings page shows a ready-to-copy snippet instead.
* New: the plugin verifies the long-caching headers by fetching one of the site’s
own CSS files and shows the result on the settings page — so you know whether
your server actually applied the rules (some hosts lack the needed Apache modules;
the plugin tells you instead of silently assuming).
* New: “Refresh versions automatically after plugin, theme or WordPress updates”(
opt-in) — covers manual, bulk and automatic background updates, and clears the
page cache when that option is on. Uses the least invalidation your mode allows:
in the recommended automatic mode file versions already update by themselves,
so only the page cache is cleared. Image versions are never touched by this feature.
* New: a one-time “what’s new” note after upgrading, shown only on the plugin’s
own settings page (dismissible; nothing is added anywhere else in wp-admin).
* New for developers: the `pbc_cache_policy_rules` filter, the `pbc_after_auto_bump`
action, and the `PBC_DISABLE_HTACCESS_WRITE` constant (force snippet-only mode,
no file writes).
* `wp pbc status` and the status ability now also report the cache-policy state(
including the verification result) and the auto-refresh setting.
* Fixed: a valueless “ver” query parameter no longer turns into “ver=.123” after
a version update.
#### 3.1.0
* New: “Update versions” can now also clear the page cache when one of the supported
caching plugins is active — WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super
Cache, WP Fastest Cache, WP-Optimize, Breeze, Cache Enabler, Hummingbird, SiteGround
Optimizer, Swift Performance, Comet Cache. Fixes “I updated the versions, but
visitors still got the old design from the page cache”. Opt-in: a settings checkbox
turns it on (off by default — another plugin’s cache is only touched when you
say so). Each plugin is purged through its own public API; every call is guarded,
and the version update always completes even if a purge fails.
* New: after every “Update versions” click the plugin reports what happened — which
asset types got new versions (per your settings) and whether the detected page
cache was cleared. The report shows inline on the settings page and as a one-
time notice after using the toolbar button.
* New: WP-CLI support — `wp pbc update [--skip-purge]` and `wp pbc status [--format
=table|json|yaml]`.
* New: on WordPress 6.9+ the plugin registers two Abilities for AI agents and automation,`
prevent-browser-caching/bump-versions` and `prevent-browser-caching/status` (
Abilities API / REST / MCP adapter; require the `manage_options` capability).
* New for developers: the `pbc_purge_page_cache` filter (veto the purge) and the`
pbc_after_bump` action (observe every version update and its purge outcome).
* Fixed: image URLs inside RSS feeds no longer get a “ver” parameter.
* Fixed: an existing “ver” query parameter in image URLs is now detected precisely—
a “ver=” fragment inside another parameter name no longer counts as one.
* Housekeeping: uninstall on multisite now cleans up networks with more than 100
sites.
#### 3.0.0
* New automatic mode (now the recommended default): the assets version is taken
from the file modification time, so browser caching works at full strength and
busts exactly when a file changes.
* External URLs (payment scripts, CDNs) are no longer versioned by default — this
used to break PayPal/Braintree/Authorize.net checkouts. A checkbox brings external
versioning back; sites upgrading with saved settings keep their previous behavior
until they switch.
* New: image cache busting. Attachment URLs are versioned; editing or replacing
a media file busts its cache.
* New: HTML page freshness — optional Cache-Control header asking browsers to revalidate
pages, plus a back/forward-cache guard for stale pages on mobile. Steps aside
automatically when a page-cache plugin is detected.
* New: exclusions list (URL substrings or script/style handles) and `pbc_skip_src`/`
pbc_assets_version` filters for developers.
* New: optional cache busting in the admin area.
* New settings screen: a few clear switches, details unfold when you need them.
Sites upgrading from 2.x get a one-click “Enable recommended settings” banner(
reversible).
* The toolbar button is now called “Update versions”: it updates the versions of
CSS/JS files and images.
* After activation the plugin opens its settings page.
* Full backward compatibility: the `prevent_browser_caching()` function, all 2.
x options and the filter timing work exactly as before.
* Recommended for developers: use the `pbc_assets_version` filter instead of the`
prevent_browser_caching()` function — unlike a bare function call, it never causes
a fatal error if the plugin is deactivated.
* Fixed: PHP warning “Cannot modify header information” when another plugin printed
output before the cookie was set.
* Fixed: the manual update button on the settings page submitted the whole form.
* Housekeeping: uninstall now removes all plugin options (multisite-aware); all
strings are translatable; added a POT file; direct-access guards on all files.
* Raised the minimum PHP version to 7.2 (matches the WordPress minimum). Tested
on PHP up to 8.5.
#### 2.3.7
* Fixed a bug with URLs that contain repeated query params: only the last one survived
after adding the “ver” param. For example, Google Fonts URLs with several “family”
params lost all font families except the last one.
* Tested the plugin in WordPress 7.0.
* Declared the minimum required PHP version (5.6).
#### 2.3.6
* Tested the plugin in WordPress 6.9.
#### 2.3.5
* Tested the plugin in WordPress 6.5.
#### 2.3.4
* Tested the plugin in WordPress 6.1.
#### 2.3.3
* Tested the plugin in WordPress 6.0.
#### 2.3.2
* Fixed “Update CSS/JS” button in the admin bar.
#### 2.3.1
* Tested the plugin in WordPress 5.1.
#### 2.3
* Tested the plugin in WordPress 5.0-beta1 and optimized the code.
#### 2.2
* Added function “prevent_browser_caching” which disables all admin settings of
this plugin and allows to set the new settings.
* Changing “ver” param instead of adding additional “time” param.
#### 2.1
* Added option to show “Update CSS/JS” button on the toolbar.
#### 2.0
* Added setting page to the admin panel.
* Added automatically updating CSS and JS files every period for individual user
* Added manually updating CSS and JS files for all site visitors
#### 1.1
* Added plugin text domain.
#### 1.0
* First version of Prevent Browser Caching plugin.
## Meta
* Versão **3.2.1**
* Última atualização **1 dia atrás**
* Instalações ativas **10.000+**
* Versão do WordPress ** 4.7 ou superior **
* Testado até **7.0.1**
* Versão do PHP ** 7.2 ou superior **
* Idiomas
* [Catalan](https://ca.wordpress.org/plugins/prevent-browser-caching/), [English (US)](https://wordpress.org/plugins/prevent-browser-caching/),
[Spanish (Chile)](https://cl.wordpress.org/plugins/prevent-browser-caching/),
[Spanish (Colombia)](https://es-co.wordpress.org/plugins/prevent-browser-caching/),
[Spanish (Ecuador)](https://es-ec.wordpress.org/plugins/prevent-browser-caching/),
[Spanish (Mexico)](https://es-mx.wordpress.org/plugins/prevent-browser-caching/),
[Spanish (Spain)](https://es.wordpress.org/plugins/prevent-browser-caching/),
[Spanish (Venezuela)](https://ve.wordpress.org/plugins/prevent-browser-caching/)
e [Ukrainian](https://uk.wordpress.org/plugins/prevent-browser-caching/).
* [Traduzir para seu idioma](https://translate.wordpress.org/projects/wp-plugins/prevent-browser-caching)
* Tags
* [browser cache](https://br.wordpress.org/plugins/tags/browser-cache/)[cache busting](https://br.wordpress.org/plugins/tags/cache-busting/)
[caching](https://br.wordpress.org/plugins/tags/caching/)[speed](https://br.wordpress.org/plugins/tags/speed/)
[WP Cache](https://br.wordpress.org/plugins/tags/wp-cache/)
* [Visualização avançada](https://br.wordpress.org/plugins/prevent-browser-caching/advanced/)
## Classificações
4.9 de 5 estrelas.
* [ 28 avaliações com 5 estrelas ](https://wordpress.org/support/plugin/prevent-browser-caching/reviews/?filter=5)
* [ 0 avaliação com 4 estrela ](https://wordpress.org/support/plugin/prevent-browser-caching/reviews/?filter=4)
* [ 1 avaliação com 3 estrela ](https://wordpress.org/support/plugin/prevent-browser-caching/reviews/?filter=3)
* [ 0 avaliação com 2 estrela ](https://wordpress.org/support/plugin/prevent-browser-caching/reviews/?filter=2)
* [ 0 avaliação com 1 estrela ](https://wordpress.org/support/plugin/prevent-browser-caching/reviews/?filter=1)
[Your review](https://wordpress.org/support/plugin/prevent-browser-caching/reviews/#new-post)
[Ver todas avaliações](https://wordpress.org/support/plugin/prevent-browser-caching/reviews/)
## Colaboradores
* [ Kostya Tereshchuk ](https://profiles.wordpress.org/kostyatereshchuk/)
## Suporte
Problemas resolvidos nos últimos dois meses:
1 de 1
[Ver fórum de suporte](https://wordpress.org/support/plugin/prevent-browser-caching/)
## Doar
Gostaria de contribuir para o desenvolvimento deste plugin?
[ Doe para este plugin ](https://tutori.org/donate/)