Free tools Windows power users keep installed
One-click scans. No signup required.
To disable MediaWiki’s built-in page and client caching across an entire wiki, add these settings to LocalSettings.php:
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
$wgParserCacheType = CACHE_NONE;
$wgCachePages = false;CACHE_NONE stops MediaWiki’s ParserCache from storing rendered page output. $wgCachePages = false turns off MediaWiki’s client-side page-cache behavior, including its ability to answer some requests with 304 Not Modified. This does not disable a separate reverse proxy or CDN; those layers must be purged or reconfigured independently.
As an Amazon Associate I earn from qualifying purchases.
What “disable caching” means in MediaWiki
MediaWiki does not have one universal cache switch. A page request can involve several independent layers, and each layer has a different control. Before changing configuration, identify where the stale response is coming from.
| Layer | What it stores or controls | Relevant control | What changing it affects |
|---|---|---|---|
| ParserCache | Rendered HTML generated from wikitext for page views | $wgParserCacheType |
MediaWiki’s internal rendered-page cache |
| MediaWiki client page caching | HTTP behavior for browsers and conditional requests | $wgCachePages |
Whether MediaWiki can honor HTTP_IF_MODIFIED_SINCE and return 304 Not Modified |
| Reverse proxy or CDN | Responses held outside MediaWiki, such as by a front-end proxy | Proxy or CDN policy and purge tools | Shared-cache responses before a request reaches MediaWiki |
| API HTTP caching | GET responses cached by browsers or shared proxies | maxage and smaxage request parameters |
Freshness instructions for API consumers and intermediary caches |
The two settings in the introduction disable the first two layers for the whole wiki. They do not reach a proxy, CDN, or other service positioned in front of the web server.
Disable MediaWiki’s page and client caching site-wide
1. Edit the active configuration file
Open the LocalSettings.php used by the target wiki. Make a backup before editing it, and ensure the change is made on the server and installation that actually serves the affected requests. A different virtual host, container, or wiki configuration will not be changed by editing an unused file.
2. Set ParserCache to CACHE_NONE
$wgParserCacheType selects how MediaWiki stores rendered page output. Assigning CACHE_NONE tells MediaWiki not to cache that rendered output. ParserCache is the primary internal caching mechanism for serving page views, so this is the setting that stops the normal rendered-page cache.
Recommended Free Tools
3. Turn off client-side page caching
$wgCachePages controls MediaWiki’s client page-cache behavior and is enabled by default. Set it to false when browsers must not receive MediaWiki’s normal cacheable-page behavior. With the setting enabled, MediaWiki can use a request’s HTTP_IF_MODIFIED_SINCE value and return 304 Not Modified; disabling it prevents that MediaWiki behavior.
4. Save, then exercise the same URL again
After saving the configuration, request an affected page in the same wiki and URL path that exhibited the problem. If the response is still stale, do not assume the two settings failed: an upstream proxy or CDN can continue serving an older response without contacting MediaWiki at all. Check that layer separately.
Why a stale page can remain after changing LocalSettings.php
The response is cached by a reverse proxy or CDN
A reverse proxy or CDN is outside MediaWiki’s ParserCache. LocalSettings.php changes neither remove objects already stored there nor change its freshness policy. Purge the affected URL or cache zone using that service’s controls, or change its policy so the response is revalidated or not stored. If you cannot administer the intermediary, ask its operator to purge the relevant host and paths.
The browser is reusing an earlier response
When client caching has been allowed, a browser may have an older response in its own cache. Test the URL with a fresh request and inspect the response headers. A result generated by MediaWiki after the configuration change can still appear old in a browser that has not revalidated its stored copy.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteThe edited configuration is not the configuration being loaded
Multi-wiki installations often have several LocalSettings.php files or virtual hosts. Confirm the domain, wiki database, deployment target, and file path you edited. A syntactically invalid configuration may also prevent the wiki from loading; restore the backup and correct the PHP syntax if the site stops responding.
The problem is not a page-view cache
API requests have their own HTTP cache controls, and a special page or extension can set a response’s cache policy independently. Diagnose the request type before applying a site-wide setting. Turning off ParserCache does not automatically make every API response or extension-generated response uncacheable.
Disable parser caching while keeping browser caching
If the goal is to regenerate rendered wikitext on every view but retain MediaWiki’s client-side browser behavior, change only $wgParserCacheType and leave $wgCachePages enabled. This is a narrower change: MediaWiki will stop reusing its stored rendered output, while browsers may still cache responses according to the normal HTTP rules.
This combination can be useful while debugging a template, parser function, or rendering issue. It does not make an already cached browser or intermediary response disappear. Those caches can continue to serve their own copies until they revalidate or are purged.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Disable caching for one extension or generated response
Special pages and extension output
For an extension special page that must not be client-cached, the documented pattern is:
global $wgOut;
$wgOut->enableClientCache(false);Use this in the extension code that builds the response. It targets client caching for that output rather than changing the entire wiki’s ParserCache policy.
Parser-tag output
For output produced by a parser tag, set the output cache expiry to zero:
$parser->getOutput()->updateCacheExpiry(0);This is the current approach for parser-tag output. Do not use the older $parser->disableCache() method in new code: it was deprecated in MediaWiki 1.28 and removed in MediaWiki 1.35. Code that still calls it must be updated before moving to a release where the method no longer exists.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Suppress parser caching for one namespace
MediaWiki 1.42 and later document $wgParserCacheFilterConfig for namespace-specific parser-cache decisions. Set the namespace’s minCpuTime threshold to PHP_INT_MAX to disable parser caching for that namespace. Set it to 0 to always cache.
The exact array key must match the namespace configuration used by the target wiki. Treat this as a version-sensitive configuration: the filter is documented as introduced in 1.42, so do not apply this recipe unchanged to an older MediaWiki release. Test the affected namespace while leaving an unrelated namespace available as a control.
Expire old entries without permanently disabling caching
If the real requirement is to discard entries created before a configuration or template change, use $wgCacheEpoch instead of turning off caching indefinitely. Set it to a timestamp chosen for the invalidation point. Entries older than that epoch are treated as expired, while newer entries can still be cached.
Cache-epoch invalidation is not equivalent to CACHE_NONE: it removes the need to reuse old entries without eliminating the performance benefit of caching future renders. This is generally the better operational choice when a one-time configuration change caused stale output.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Control caching for API requests
For GET API responses, MediaWiki supports the maxage and smaxage parameters. maxage targets browser freshness; smaxage targets shared proxies. These parameters affect the HTTP response for that request rather than changing the wiki’s global ParserCache configuration.
- Errors are not cached.
- Responses tied to a logged-in user’s context are marked
Cache-Control: privatefor shared caches. - A request with different cache parameters has a different URL, so it may not reuse a response cached for an earlier URL.
When an API consumer reports stale data, compare the exact request URL and its cache parameters, then inspect the browser and shared-proxy behavior. A site-wide ParserCache change alone does not override API cache instructions.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose the narrowest effective change
| Problem | Preferred action | Scope | Performance consequence |
|---|---|---|---|
| Every page view shows stale rendered wikitext inside MediaWiki | Set $wgParserCacheType = CACHE_NONE |
Whole wiki’s ParserCache | Rendered pages are regenerated instead of reused; rendering is more expensive |
| Browsers receive conditional responses or retain MediaWiki’s client-cache behavior | Set $wgCachePages = false |
Whole wiki’s client page caching | Less browser-side reuse and more origin requests |
| Only an extension special page must be fresh | Call $wgOut->enableClientCache(false) |
That extension response | Other pages retain their normal settings |
| Only parser-tag output must expire immediately | Call $parser->getOutput()->updateCacheExpiry(0) |
That parser output | Other parser output can remain cached |
| One namespace should avoid ParserCache | Use $wgParserCacheFilterConfig with minCpuTime => PHP_INT_MAX |
Configured namespace, MediaWiki 1.42+ | Only that namespace loses parser-cache reuse |
| Old entries must be discarded after a change | Advance $wgCacheEpoch |
Entries older than the selected epoch | Caching continues for newer output |
| A CDN or reverse proxy serves old pages | Purge or reconfigure that intermediary | External shared cache | Depends on the intermediary’s policy |
Performance and operational trade-offs
Parser caching exists because rendering wikitext and extension output is expensive. Disabling it site-wide makes MediaWiki repeat that rendering work for page views instead of serving stored output. The cost is workload-dependent, so there is no universal benchmark figure to apply; the safe assumption is that origin CPU and response latency can rise, especially on a busy wiki or a page with expensive templates.
A selective control is therefore preferable when only one namespace, extension, parser tag, or API consumer is affected. Keep normal parser-cache hit rates for unaffected content, and use an epoch change when the issue is a one-time invalidation rather than a permanent need for uncached rendering.
Version checklist before applying a recipe
- Confirm the target MediaWiki version.
- Use
CACHE_NONEfor the site-wide ParserCache switch. - Use
$wgCachePages = falseonly when client-side page caching must also be disabled. - Replace any call to
$parser->disableCache(); it was removed in MediaWiki 1.35. - Use
$wgParserCacheFilterConfignamespace filtering only on a release that documents it, 1.42 and later. - Handle a reverse proxy or CDN separately.
- For API freshness, inspect
maxage,smaxage, login state, and the exact request URL.
A practical diagnostic sequence
- Identify whether the stale object is a normal page view, an extension special page, parser-tag output, or an API response.
- Check whether the response is being served by MediaWiki or by a reverse proxy/CDN.
- For a normal page view, inspect ParserCache configuration first.
- For browser freshness, check
$wgCachePagesand the request’s conditional-cache behavior. - For an extension or parser tag, apply its dedicated output control instead of disabling caching globally.
- For a one-time purge, advance
$wgCacheEpochrather than leaving ParserCache disabled. - Retest the same URL and request context, including logged-in versus logged-out state and API cache parameters.
Common configuration mistakes
Disabling only one layer
Setting $wgParserCacheType to CACHE_NONE does not disable browser caching, and setting $wgCachePages to false does not purge a CDN. Treat each cache layer as a separate decision.
Using a removed extension method
Examples that call $parser->disableCache() are obsolete on MediaWiki 1.35 and later. Update the extension to the parser-output expiry method instead.
Assuming invalidation equals permanent disablement
$wgCacheEpoch expires older entries; it does not turn off future caching. Conversely, CACHE_NONE is a continuing policy, not a one-time purge.
Ignoring request context
API responses can vary by cache parameters and authentication context. A logged-in response marked private follows different shared-cache rules from an anonymous GET response, so test both contexts when troubleshooting.
The Bottom Line
Use $wgParserCacheType = CACHE_NONE to stop MediaWiki’s rendered-page cache and $wgCachePages = false to disable its client-side page caching. If stale content remains, purge or reconfigure any reverse proxy/CDN, then use the narrower extension, namespace, API, or cache-epoch controls when a site-wide shutdown is unnecessary.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
