Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
To disable MediaWiki’s built-in page and browser caching for an entire wiki, add these two settings to LocalSettings.php:
$wgParserCacheType = CACHE_NONE;
$wgCachePages = false;$wgParserCacheType = CACHE_NONE stops MediaWiki from storing rendered page output in ParserCache. $wgCachePages = false turns off MediaWiki’s client-side page caching, so browsers are not allowed to reuse cached page responses. These settings do not purge or disable a separate reverse proxy or CDN; that layer must be changed independently.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What the two settings actually disable
MediaWiki does not have one single cache. Several layers can serve an older response, and each layer has a different control.
| Layer | What it stores or controls | Main control | Where it applies |
|---|---|---|---|
| ParserCache | Rendered HTML produced when MediaWiki parses page wikitext | $wgParserCacheType |
MediaWiki page views |
| Client-side page caching | Browser reuse of page responses and conditional requests | $wgCachePages |
Browsers and MediaWiki’s page-cache headers |
| Reverse proxy or CDN | Responses stored outside MediaWiki | Proxy/CDN policy and purge controls | Shared network caches |
| Extension output | Special-page or parser-tag responses generated by an extension | Extension-specific methods | Individual extension output |
| API HTTP caching | GET responses cached by browsers or shared proxies | maxage and smaxage |
API requests |
ParserCache is MediaWiki’s primary mechanism for serving page views. Rendering wikitext can be expensive, so disabling it globally can increase CPU use and response time. If only one extension, namespace, or API request is stale, a narrower setting usually avoids that cost.
Disable MediaWiki caching for the entire wiki
1. Edit the correct configuration file
Open the wiki’s LocalSettings.php, the file where site-specific MediaWiki configuration is stored. Make a backup before changing it so you can restore the previous cache behavior if page generation becomes too slow.
2. Add both cache settings
Place the following lines in LocalSettings.php:
$wgParserCacheType = CACHE_NONE;
$wgCachePages = false;The first line selects the no-cache backend for rendered parser output. The second disables MediaWiki’s client-side page caching. The official MediaWiki FAQ presents these two lines as the complete recipe for disabling caching at the MediaWiki site level.
3. Save the file and request a page
Save the configuration, then load a page that previously showed stale content. Test both an anonymous browser window and a logged-in session if your wiki has different behavior for those contexts. Make a small, identifiable edit so you can tell whether the newly rendered output is being served.
4. Check for caches outside MediaWiki
If the old page still appears, the remaining copy may be in a reverse proxy or CDN. The two settings above do not control that layer. Purge the affected URL or change the proxy’s caching policy using that service’s own administration tools.
Turn off browser caching but keep ParserCache
If rendered pages are correct but browsers keep showing an old response, leave ParserCache enabled and set only:
$wgCachePages = false;This preserves MediaWiki’s server-side rendered-page cache while disabling its client-side page caching behavior. It is a lower-impact option when the stale response is caused by browser reuse rather than stale parser output.
When client-side caching is enabled, MediaWiki can honor the HTTP_IF_MODIFIED_SINCE request header and return 304 Not Modified. Turning off client-side page caching prevents that page-cache behavior, but it still does not remove a copy held by a shared proxy or CDN.
Disable caching for one extension or special page
Special pages and extension-generated responses
For an extension special page that must be generated on every request, the documented pattern is:
global $wgOut;
$wgOut->enableClientCache(false);This targets client caching for that extension response rather than disabling ParserCache for the entire wiki.
Parser-tag output
For output generated by a parser tag, set the output cache expiry to zero:
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 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match$parser->getOutput()->updateCacheExpiry(0);Use this in the parser-tag implementation when the tag’s result must not remain cacheable. It affects that generated output instead of every page on the site.
Do not use the removed method
The older $parser->disableCache() method was deprecated in MediaWiki 1.28 and removed in MediaWiki 1.35. Code that still calls it must be updated to the current output-cache controls before upgrading to, or running on, MediaWiki 1.35 or later.
Disable parser caching for one namespace
MediaWiki 1.42 and later document per-namespace control through $wgParserCacheFilterConfig. In the configuration entry for the namespace, set the minCpuTime threshold to PHP_INT_MAX. That prevents parser caching for that namespace.
The same filter uses minCpuTime = 0 to always cache. This gives you a namespace-level choice between suppressing parser cache entries and retaining normal caching behavior. Because the surrounding configuration structure can vary with the MediaWiki version and the namespaces defined on your wiki, edit the existing namespace entry rather than copying an array shape from an older release.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsThis setting is available in the documented form starting with MediaWiki 1.42. On earlier versions, use a site-wide setting or an extension-level approach instead of assuming the namespace filter exists.
Expire old entries without permanently disabling caching
If you changed configuration or templates and need old entries to stop being used, but still want the performance benefit of caching, use $wgCacheEpoch. Set it to a timestamp chosen for the invalidation point. Entries older than that epoch are treated as expired.
$wgCacheEpoch invalidates older entries; it is not equivalent to disabling every cache layer. ParserCache can remain enabled, and a reverse proxy or CDN can still hold responses until its own expiry or purge policy removes them.
Control caching for API responses
MediaWiki’s API accepts the maxage and smaxage parameters on GET requests. maxage targets browsers, while smaxage targets shared proxies. Use the parameter that matches the cache you need to control rather than disabling page caching for the whole wiki.
Recommended Free Tools
- Errors are never cached.
- Responses tied to a logged-in user’s context are marked
Cache-Control: privatefor shared caches. - A request with different cache parameters produces a different URL, so it may not reuse an earlier cached response.
These controls apply to API HTTP behavior. They do not replace ParserCache settings for normal page views, and they do not purge an independent CDN’s already stored object.
Why stale pages remain after changing LocalSettings.php
The stale copy is in a reverse proxy or CDN
MediaWiki can generate fresh HTML while a proxy continues returning an older object. Purge the specific URL, invalidate the relevant path, or change the proxy’s cache policy. Changing $wgParserCacheType and $wgCachePages alone cannot reach that external cache.
The page is coming from ParserCache
If the stale content is rendered wikitext inside MediaWiki, inspect $wgParserCacheType first. A site-wide CACHE_NONE setting prevents new parser-cache storage. If you want to retain caching, use $wgCacheEpoch to expire entries older than a selected timestamp.
The response is being reused by a browser
Disable client-side page caching with $wgCachePages = false. For an extension page, use $wgOut->enableClientCache(false) so the change remains limited to that output.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →The stale output belongs to an extension or parser tag
Global settings may be broader than necessary. Apply updateCacheExpiry(0) to parser-tag output, or use the extension’s client-cache control for a special page. Check the extension’s supported MediaWiki versions before changing code, particularly if it still references the removed disableCache() method.
The API request has a different cache key
API cache parameters are part of the request URL. A request made with different maxage or smaxage values may not reuse the response from the earlier URL. Test the exact URL and parameter set used by the client that reports stale data.
Choosing the narrowest effective setting
| Your symptom or goal | Preferred control | Scope | Performance effect |
|---|---|---|---|
| Every page view must be rendered without ParserCache | $wgParserCacheType = CACHE_NONE |
Whole wiki, parser layer | Highest server-side rendering cost |
| Stop browser page reuse across the wiki | $wgCachePages = false |
Whole wiki, client layer | More requests reach MediaWiki; ParserCache can remain active |
| One special page must not be client-cached | $wgOut->enableClientCache(false) |
One extension response | Limited to that response |
| One parser tag must expire immediately | $parser->getOutput()->updateCacheExpiry(0) |
That parser-tag output | Limited to generated output |
| One namespace should bypass parser caching | minCpuTime = PHP_INT_MAX in $wgParserCacheFilterConfig |
One namespace, MediaWiki 1.42+ | Rendering cost applies to that namespace |
| Fresh content is needed after a change, but caching should remain | $wgCacheEpoch |
Older entries across the configured cache scope | Temporary invalidation rather than permanent bypass |
| Only API clients need different HTTP cache behavior | maxage and/or smaxage |
Individual GET requests | Depends on client and shared-proxy settings |
Prefer the smallest scope that fixes the problem. Parser rendering is expensive, so preserving ParserCache hit rates where possible generally gives better performance than disabling it for the whole site.
Version and compatibility notes
$parser->disableCache()was deprecated in MediaWiki 1.28 and removed in MediaWiki 1.35.- The documented per-namespace parser-cache filter using
$wgParserCacheFilterConfigis available in MediaWiki 1.42 and later. - The two-line site-wide recipe uses
$wgParserCacheType = CACHE_NONEand$wgCachePages = false; confirm the target wiki’s MediaWiki version before applying any extension or namespace-specific code.
Verification checklist
- Identify whether the stale response is a rendered page, a browser response, an API response, or a proxy/CDN object.
- Apply the setting that matches that layer instead of starting with a site-wide disable.
- Make a visible test edit and request the page in a fresh anonymous session and a logged-in session.
- If the old output remains, inspect and purge the reverse proxy or CDN separately.
- For extension code, replace any call to
disableCache()with the supported output or client-cache control for the installed MediaWiki version. - After confirming fresh output, consider restoring ParserCache or using
$wgCacheEpochso normal performance is retained.
Frequently Asked Questions
Will setting $wgParserCacheType = CACHE_NONE clear a CDN’s existing objects?
No. It prevents MediaWiki from storing rendered output in ParserCache, but a reverse proxy or CDN is outside that layer. Purge or reconfigure the external cache separately.
Can I disable browser caching without disabling ParserCache?
Yes. Set $wgCachePages = false and leave $wgParserCacheType unchanged. This targets client-side page caching while retaining server-side rendered-page caching.
What replaces $parser->disableCache()?
The method was removed in MediaWiki 1.35. For parser-tag output, use $parser->getOutput()->updateCacheExpiry(0); for an extension special page, use $wgOut->enableClientCache(false) as appropriate.
How do I bypass parser caching for only one namespace?
On MediaWiki 1.42 and later, configure that namespace in $wgParserCacheFilterConfig and set its minCpuTime threshold to PHP_INT_MAX. Set it to 0 when the namespace should always be cached.
Is $wgCacheEpoch the same as disabling caching?
No. It expires entries older than a chosen timestamp while allowing caching to continue. It does not disable browser, API, or reverse-proxy caching by itself.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →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.
