Manual talk:File cache

The following discussion has been transferred from Meta-Wiki.
Any user names refer to users of that site, who are not necessarily users of MediaWiki.org (even if they share the same username).

Invalidation does not work for me

Please help, I am trying to correct translation of wikopedia, but I have problems with invalidating the cache. I correct the cur_text field in the database, but nothing changes. I have tried to manually set the cur_touched field to current time and use $wgCacheEpoch to invalidate but nothing has worked.

Thanks for helping.

Please edit the article instead of the database. That will cause the caches to be updated. If it is in a configuration file, you can delete every file in the file cache and that will leave no choice but to create a new file. If you still have trouble, please give more details in an email to the MediaWiki mailing list. Jamesday

It would be helpful if an example of how to set $wgCacheEpoch to the current time, and also it would be helpful if more explanation of how one could go about deleting the cache. For example, where is the cache? Can I just find a cache directory on the hard drive and delete it? GregGarner

End of content from meta.wikimedia.org.
Note that the above conversation may have been edited or added to since the transfer. If in doubt, check the edit history.

need defintion for cache for less computer savy wikiusers

Need definition. 68.92.156.227 17:14, 21 December 2006 (UTC)

Help clearing article cache?

Hi all. I'm working on a tag-extension for uploaded images in which I make it possible to edit tags succesfully in image description pages without having to make changes to the article itself. I did this by sending the tags to updateArticle() when posting and then bypassing the "if ( 0 != strcmp( $text, $oldtext )" (check if anything changed in the article) by putting my function addTags() after the end of the if (and else) brackets. This way the tags are added anyway, even when the article wasn't updated.

My problem is: when an article isn't updated the cache isn't cleared, requiring a hard refresh to see the new tags. How can I make sure the cache of that particular article is cleared even when it hasn't changed? Or should I just force a change in the article? Many thanks! Litso 21:41, 30 January 2008 (UTC)

Never mind, I solved it. Calling the Title::touchArray( ); function didn't work for only one article because it isn't an array, so I just stripped the function and used $dbw->update to change the page_touched field to the current time. If anyone is interested, the following code worked for me:

$dbw->update( 'page',


array( 'page_touched' => $dbw->timestamp(); ),


array( 'page_namespace' => $this->mTitle->getNamespace(),


'page_title' => $this->mTitle->getDBkey() ),


$fname );


where of course $this->mTitle represents the article name in the function the code was placed in, I don't know if this is used consistantly throughout the code. Litso 09:24, 31 January 2008 (UTC)

removing old cache items through linux command

find /path/to/cache -type f -mtime +5 -exec rm {} \;

This will clear out all files that are older than 5 days old.

BE EXPLICIT WITH YOUR PATH. You don't want this to go wrong. You can change rm to rm -v to see what is being deleted as it is being deleted

Cached Errors

I'm running into infrequent problems where an error occurs, and it caches page with the error message. (I noticed that this is listed as a known problem -- and I've also got an open bugzilla ticket for it.)

I'm trying to figure out a way to build a hook or something to not cache these pages when an error occurs. I've looked through the hooks, but I can't figure out which one(s) I could use to accomplish this. Any ideas? --Duke33 14:38, 8 July 2009 (UTC)

It looks like these error pages are no longer cached, as part of the 1.15 release. --Duke33 19:39, 28 October 2009 (UTC)

Make robots only able to access cached content

I don't want bots (such as web crawlers and search engines) to grab content that hasn't been previously cached. To stop it from accessing non-cached content I did the following:

Edit includes/HTMLFileCache.php

add this to the begining of the function isFileCached()

      global $custom;
      if($custom->cache_only){
      if(!file_exists($this->fileCacheName())){
          echo "This page has not been cached. Only humans can see pages that are not cached.";
          exit;
      }

In your localsettings.php file check to see if the useragent is a bot that is giving you trouble, and if so, set $custom->cache_only for true when that is the user agent. —The preceding unsigned comment was added by 207.47.30.250 (talk • contribs) {{{2}}}

Bots won't know that this isn't the page's real content; you should send an HTTP status code that indicates you're not returning the requested resource (404 and 500 are the most obvious choices).

I don't think this is a very good idea in general, though, unless you have a significant long tail and lack the space to cache it. —Emufarmers^(T|C) 03:44, 24 November 2009 (UTC)

I do, I have a rather large wikifarm (http://editthis.info), and a decent percentage of wikis are dormant. I changed the message to a checkbox form, which will force it to show and cache the page. I tried a header type of 404 error, but I think at this point in the code, headers have already been sent.

Caching for registered users?

Is there a setting or a code edit I could use to make it so it caches for regular users too? I'm just using the plain file cache. The problem is that there are very few people who use my wiki anonymously, and my server doesn't have that much bandwidth or computing power. -- Spencer8ab 04:41, 11 March 2010 (UTC)

Not really, as the file cache won't play well with preferences and such. Try using object caching (See Manual:Cache) which should improve performance for logged in users. Bawolff 19:10, 24 January 2011 (UTC)

Can '$wgUseGzip = true' be used with 'gzip on;' of the nginx?

I already set gzip on in nginx conf file. Should/Can I set $wgUseGzip option to true? Will nginx recompress the compressed cached file before send it to users?

Enabling file cache doesn't turn off GZip

In my deployment (MW 1.16 on shared hosting) $wgUseFileCache = true; $wgUseGzip = false; and pages are still served as GZip (cache files are not gzipped).

category pages in cache do not get updated

Recently I upgraded from mediawiki 1.13 to 1.17 Since then, the file cache for category pages does not work correctly. When I update a page which has categories, the corresponding category pages do not get deleted from the file cache. A not logged in user sees the old copy of the related category pages. For normal pages, the file cache works correctly, i.e. after an update the cache page gets deleted, so that an anonymous user sees the fresh page.

What could be the cause of this problem?