alois wrote:

I check my backup server which is still running MW 1.13. The problem is the same on that version, I just had never noticed it. A user pointed it only out after the update to MW 1.17
My current workaround is a cron command to clean all Category: and (German) Kategorie: pages from file cache avery few hours.

What are your MediaWiki job queue settings?

alois wrote:

used to be 1 (as in Defaultsettings), but since today it is
$wgJobRunRate = 10;
because I had a huge queue due to a macro update. Queue length now is down to 0 again. It was never any large value on the wiki where the problem resides.
I run 3 wikis on one server, differentiated by table name prefixes.

alois wrote:

PS: you can look at my Version info here
German wiki: http://wiki.astro.com/astrowiki/de/Spezial:Version
English Wiki: http://wiki.astro.com/astrowiki/en/Special:Version

alois wrote:

I have now upgraded my wikis to mw 1.18.
The problem persists.
To describe it a bit more precisely:
When I add a new category in a page, the category page gets updated (I assume deleted in the file cache, so that a non-logged in user sees a fresh page).
But when I delete a category from a wiki page, the corresponding category page
does not get updated in the file cache, i.e. the old file cache page does not get deleted.

arjunaraoc wrote:

I too am facing the problem in Telugu Wiki Example page
http://te.wikipedia.org/wiki/%E0%B0%97%E0%B1%81%E0%B0%82%E0%B0%9F%E0%B1%82%E0%B0%B0%E0%B1%81
Note: Transliterated text used in the following to refer to page title
Here the page Gunturu was originally redirected to Gunturu zilla (meaning Guntur district) and then restored back to Guntur after a separate page is created for Guntur Zilla. This page shows its old categories although relevant entries were removed more than a month back. We have four other pages with similar problem.

The bugs needs a high priority, as category system is critical for navigation and updation in Mediawiki

arjunaraoc wrote:

I found the cause for the problem as hidden categories added by a template, which did not undergo the required changes when the article is changed from district to a town. After fixing the same, I found the category updates to be happening properly.

info wrote:

I'm running MediaWiki 1.19.0 and I have the same problem. My main page doesn't change too, but that kinda makes sense because it doesn't get edited, the changes are just made through template rotation.

I'm gonna add a shell script (which deletes the category files and the main page from the file cache) to crontab.

(In reply to comment #6)

I too am facing the problem in Telugu Wiki Example page
http://te.wikipedia.org/wiki/%E0%B0%97%E0%B1%81%E0%B0%82%E0%B0%9F%E0%B1%82%E0%B0%B0%E0%B1%81
Note: Transliterated text used in the following to refer to page title
Here the page Gunturu was originally redirected to Gunturu zilla (meaning
Guntur district) and then restored back to Guntur after a separate page is
created for Guntur Zilla. This page shows its old categories although relevant
entries were removed more than a month back. We have four other pages with
similar problem.

The bugs needs a high priority, as category system is critical for navigation
and updation in Mediawiki

Note that is a separate bug. (This bug is complaining about file cache not being updated. File cache is a feature that is not used by Wikipedia, so this bug cannot affect Wikipedia). However, it seems you managed to solve your issue.

The file cache is cleared in the same places that any squid cache is cleared. Since WMF doesn't have these problems, then that means there might be some clearFileCache() calls that don't work. It could also mean that the job queue on the wiki is broken. It might also be that not enough pages where invalidated to use the job queue, so the purge calls where made on the spot, but did nothing due to the "$wgUseFileCache = false;" line in WikiPage.php.

info wrote:

(In reply to comment #10)

The file cache is cleared in the same places that any squid cache is cleared.
Since WMF doesn't have these problems, then that means there might be some
clearFileCache() calls that don't work. It could also mean that the job queue
on the wiki is broken. It might also be that not enough pages where invalidated
to use the job queue, so the purge calls where made on the spot, but did
nothing due to the "$wgUseFileCache = false;" line in WikiPage.php.

Thanks for your reply! I just realized that now, after about two days, the category has been updated. It's perfectly okay for me now, because I don't need the category to be instantly updated, as long as it gets updated from time to time. For the main page, I have my cronjob now, so everything's fine here now :)

info wrote:

I checked again and the category change I made a few hours ago is already visible. Maybe it has something to do with me setting up a cron job a few minutes ago executing runJobs.php --maxjobs 1000 every 5 minutes.

I use 1.24.1 and I have the same issue. File caching is on and works, edits on pages are immediately seen correctly by anonymous viewers. However, when a category is added OR removed, the category page is outdated for anonymous viewers, and up-to-date for logged in ones (who don't see file caching).

I tried different things for hours and set up the localsettings file completely anew, to no avail. Seems like a very severe bug to me. And I have no way of working around it. showjobs.php shows nothing and runjobs.php makes no difference (I used it via the maintenance extension, since I dont have shell access).

I could configure a cronjob to work around this silly bug, but I since runjobs.php doesnt matter I dont see how I could make things work that way...

I believe neither squid nor file cache is cleared on category update (at least that used to be the case) if so this is a good first task bug to fix for a newcomer.

So what's the fix? I am not a web developer and am busy enough with another Open Source project already. So i can't really look into this.

My comment was just to add it to the easy category in order to perhaps attract more developers. As a user there's not really anything you can do at this point (sorry).