Manual talk:Cache

Why is my edit
Why is my edit to this page still pending after 6 days? The information on the current revision about the required version of eAccelerator is wrong. Are there not enough people to review pending changes? That would be a pretty convincing argument to disable Flagged Revisions. Also, I've got a long history of editing on this wiki. Why aren't my edits automatically approved? --Cneubauer 12:42, 21 April 2011 (UTC)


 * I've made you a reviewer. —Emufarmers(T 01:10, 22 April 2011 (UTC)

Don't cache transclusions?
The default behavior seems to be building a cache copy of a requested page by statically including transcluded pages. The end result is that changing the transcluded page does not expire the cache copy of the pages that use it. Those pages therefore become stale. Is there a way to configure MW so that it caches each page without pre-parsing transclusions? This otherwise makes it very difficult to support real-time content (data feeds). Users have to manually purge pages to keep them up to date, or otherwise disable caching completely. 65.87.26.122 19:36, 2 March 2012 (UTC)

Actually I'm not sure if it is transclusion specifically or dynamic content in general (ParserFunctions). 65.87.26.122 19:40, 2 March 2012 (UTC)

Object cache on windows
Has anyone experienced problems with caching on windows? I've tried eaccelerator, apc and xcache on thread safe PHP 5.2.17 and 5.3.13. None of them worked, in all of them MW 1.18 refused to recognize the existence of the cache extension, even though I see it in php info Osishkin (talk) 04:33, 19 July 2012 (UTC)

File Caching
Might be an idea to mention file caching on this page in the introductory paragraph. I just spent a couple of hours trying to enable memory caching on my shared host (bluehost) for a small to medium sized wiki. Then discovered file caching and that solved all the issues right away. Maybe others will be in the same situation. So much simpler, if your host doesn't have memory caching already enabled. I know it is listed under performance if you follow the link, can find it there now but easy to miss when you don't know the option exists. Manual:File_cache

Any difference between purge vs "null edit"?
Hi. w:Help:Dummy edit says that a purge does not update category pages, but a null edit (= pressing an edit button without any change) does. Is it true? Manual:Purge nor w:Wikipedia:Purge don't say any. --Ahora (talk) 06:19, 26 November 2012 (UTC)
 * As far as I tested several times, this statement seems correct. --Ahora (talk) 12:49, 11 December 2012 (UTC)

Using caching breaks password resets?
Hi.

I have APC installed and $wgMainCacheType = CACHE_ACCEL set on a number of wikis (versions 1.17.3 - 1.19.4). I have noticed that password reset is not working in these instances. The user requests a new password and gets emailed a new password, but when they enter it they are informed it is the wrong password. If I restart apache then the new password then works.

If I turn off caching then password resets work as expected. If this is indeed the case, surely this is a major flaw?

--Mitchelln (talk) 10:37, 6 February 2013 (UTC)


 * I can't reproduce this. Check whether it still happens if you set $wgMainCacheType = CACHE_DB;. —Emufarmers(T 13:26, 6 February 2013 (UTC)


 * Hello. I can reproduce this. When using XCache and enabling VAR Caching with  the newly E-mailed password is not accepted by MediaWiki. Only after disabling VAR Caching with   the new password is accepted. MW-1.21.0, PHP 5.4.16, XCache 3.0.3. --Jongfeli (talk) 10:01, 7 August 2013 (UTC)


 * Works for me. I'm running latest version of MediaWiki from git, and i've set  (after installing xcache 3.0.3) and restarted apache. I've created a new account with password, logged out, login with the "forget password?" link and put my new created account. I received an email with the temporary password, logged in with it and MediaWiki detected it was a temporary password and forced me to pick a new one. I've done so and I'm now logged in again. --Ciencia Al Poder (talk) 16:36, 7 August 2013 (UTC)


 * Hello Ciencia Al Poder. When I use use your setup for XCache all works just fine when resetting passwords, thanks for that. The only thing to do now is to get the documentation correct. As far as I can see your setup, when using  is not documented. I can only find a "hint" on Manual:$wgObjectCaches but it does not tell you how to set this up in localsettings.php. On Manual:$wgMainCacheType, Manual:$wgMessageCacheType and Manual:$wgParserCacheType there is no reference. But before I jump to any conclusions I will test is again tomorrow, just to make sure. Regards --Jongfeli (talk) 18:43, 7 August 2013 (UTC)


 * Well, I've used  to force the use of xcache, since I had also APC, to be sure xcache is being used and not APC, although when testing I had to disable APC from php.ini because having both enabled caused segfaults on apache. As you can see in $wgObjectCaches, it's listed there. CACHE_ACCEL just calls a function that determines what cache use based on the presence of api functions of each cache type. Since xcache is the second option when determining the opcode cache to use, and apache won't work if both APC and xcache are enabled, it shouldn't make any difference. Maybe the problem you had was that the temp password already expired. --Ciencia Al Poder (talk) 09:34, 8 August 2013 (UTC)


 * I figured out what goes wrong here. Some users do not have a valid Email address, when they forget there password we need to reset this in CLI with:

We run a Semantic Wiki that updates every night with a script, it runs in php CLI and because XCache VAR Caching does not work in CLI mode we put this in LocalSettings.php:


 * Now the Semantic update runs just fine but a password reset via CLI does not. The new password does not work. To make it work you first need to use the old password to login which brings you to the login screen again and then you can use the new password. Problem is that you do not have the old password because it was forgotten. Only option is to Clear the Var Data and then you can login. It seems that a password reset via CLI could get you into problems when you are not able to either clear the Var Cache or restart Apache completely. --Jongfeli (talk) 09:24, 12 August 2013 (UTC)

APC installed on server but MediaWiki can't find it !
Hi, in my LocalSettings.php file, i have $wgMainCacheType   = CACHE_ACCEL; and when i run maintenance scripts, such as 'runJobs.php' i get this error: '''the CACHE_ACCEL requested but no suitable object cache is present. You may want to istall APC.''' APC is installed and working, on my PHP	5.3.24

mw_objectcache growing in spite of wgMainCacheType = CACHE_NONE
Hi,

My mw_objectcache table continues to grow - it's now several tens of thousands of rows and growing - in spite of the fact that caching is disabled. What is creating these rows? How can I make it stop?

Thanks,

Dave.


 * I think that it's caused by the parser cache, which seems to be independent from the main cache type. Try setting Manual:$wgEnableParserCache to false. --Ciencia Al Poder (talk) 09:36, 25 April 2014 (UTC)

Possible to make CACHE_ACCEL work with Opcache?
I know it doesn't right now, I was wondering if it's technically possible in the future. XCache has gone the way of the dinosaur with PHP 5.6, something I didn't realize before I upgraded, so I had to use Opcache instead to get my wiki up and running immediately and CACHE_ACCEL does not work with it (though it did with XCache). So, is it technically possible or is the interface to Opcache not there? 98.210.209.147 18:27, 25 September 2014 (UTC)


 * There's a feature request for it: --Ciencia Al Poder (talk) 19:57, 25 September 2014 (UTC)
 * Actually, it can't work because it's an opcache, not an object cache, so MediaWiki can't store arbitrary values on it. The bug has been closed as invalid. --Ciencia Al Poder (talk) 20:10, 25 September 2014 (UTC)


 * When moving to PHP 5.5.13 on our Wiki server (Windows Server 2008 x64) we tested the performance between Xcache and Zend Opcache. On our case the Zend Opcache solution without object cache on the wiki is faster then Xcache with object cache enabled on the wiki. I don't have the numbers anymore but with Zend Opcache, working on the wiki is noticeably faster. What increases performance even more is setting up Apache modules  and   but that does not work reliable yet. It seems we keep loosing the wiki's style "css" files after X time. I am not sure yet what is going on there but I think this is more Apache related then MediaWiki and is of topic :) Regards --Felipe (talk) 06:52, 26 September 2014 (UTC)


 * Same problem here. I just updated PHP for OPcache because APC made major problems. Because of the new PHP version I need to update MW and the web installer threw the error that "APC, XCache or WinCache" are not found. What do I need to do? Sounds like I can set $wgMainCacheType to NONE and it will be fine too? --Subfader (talk) 20:12, 30 September 2014 (UTC)


 * It's better if you simply comment your modifications of $wgMainCacheType so it uses the default one, that's CACHE_ANYTHING, so it can cache something in database. NONE will cache nothing! --Ciencia Al Poder (talk) 09:22, 1 October 2014 (UTC)


 * Ok, but what if I want to use memcached additionally? $wgMainCacheType = CACHE_MEMCACHED? --Subfader (talk) 09:37, 1 October 2014 (UTC)


 * Yes --Ciencia Al Poder (talk) 09:32, 2 October 2014 (UTC)


 * You might look into the APCu PECL extension, which is basically the user data caching portion of APC. GreenReaper (talk) 01:07, 6 August 2015 (UTC)