Page MenuHomePhabricator

MediaWiki namespace pages regularly fall back to an obsolete version, due to server cache effect
Closed, ResolvedPublic

Description

Author: Wiki.Melancholie

Description:
At least on alsWP, deWNews and deWikt the message MediaWiki:Sidebar regularly falls back to an totally obsolete version, due to some kind of server cache problem. Then many links are obsolete or broken on the left navigation sidebar, because of many changes towards the sidebar after the un-customisable version of [[MediaWiki:Sidebar]] had been enhanced to what we know now.

For forcing the servers to fetch the newest version, you have to edit and save [[MediaWiki:Sidebar]] as a sysop, unfortunately (for those who are reading: You do not have to change the page, just click "save" without having changed something; that's enough).

Is there a way, that [[MediaWiki:Sidebar]] does not get affected by this server cache effect? This fall back is pretty annoying, I would say! --- Best regards,
Melancholie

See Also:

Details

Reference
bz5092
Related Gerrit Patches:

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:08 PM
bzimport set Reference to bz5092.
bzimport added a subscriber: Unknown Object (MLST).

robchur wrote:

The sidebar is cached; the caching is necessary to help performance. Purge any
pages showing the old version if you come across them, but don't panic; the
cache eventually expires.

brion added a comment.Feb 26 2006, 1:26 AM

The cache shouldn't be reverting to old versions. This may be related to general
message cache problems getting frozen in the sidebar cache.

Wiki.Melancholie wrote:

Yes, I was writing about very old versions of those sidebars (outdated since
many months). Maybe it would help when deleting all older revisions of
[[MediaWiki:Sidebar]], but deleting almost the whole history actually is not in
terms of a GNU-FDL wiki ;-)

Wiki.Melancholie wrote:

I don't know for sure, but at least on alsWP the cache 'flashback' had lead to
the oldest revisions ("MediaWiki default") of MediaWiki:Sidebar two or three
times in the last two months, I think. Maybe the sidebar also falls back to
other revisions, but everytime I recognised this problem, a "MediaWiki default"
revision had been fetched, I assume. And especially those are totally outdated
on some projects ;-)

Wiki.Melancholie wrote:

OK, right now at least I do have this problem at [[als:]] again; but I am not
sure whether others will also get the old sidebar or not (check the "Aktuelle
Ereignisse" link for example)

Wiki.Melancholie wrote:

Although I deleted all older revisions of [[:als:MediaWiki:
Sidebar]] some days ago, the navigation falls back! It seems that
some kind of standard sidebar is fetched instead of the current
MediaWiki:Sidebar. Or there are still cached versions of the
already deleted revisions on the server. Maybe the sidebar even
falls back to MessagesGsw.php, is this possible?

Wiki.Melancholie wrote:

Right now it occured once more on [[:als:]]. Furthermore a user
reported, that the sidebar sometimes even falls back to an English
version!
See [[:als:Wikipedia:Stammtisch#Navigation]].

kaveh_d wrote:

This is also common on the Persian Wikipedia where it frequently falls back to
the LanguageFA.php version.

Wiki.Melancholie wrote:

BTW: When forcing a reload (Firefox: Ctrl+R) the correct version of the sidebar
is loaded sometimes (but not always).

A similar effect occurred for monobook.css today on als.WP using Firefox
1.5.0.1! The current monobook.css was not loaded (but strangely, monobook.js
was!) and so some CSS stuff was not shown. After a reload the CSS worked out,
too. Is this related to the sidebar bug?

gangleri wrote:

Hallo!

Same happened the 26th of March 2004 with
http://yi.wikipedia.org/w/index.php?title=MediaWiki:Sidebar&oldid=18693
see [[yi:user_talk:Gangleri#menu_bar_again_English]]

I did not find the time to ask at MediaWiki-General about what particular changed
caused that.

A woraround might be *only* to use LATIN characters as described at
[[yi:MediaWiki_talk:Sidebar#MediaWiki_messages_used_at_the_yi.wikipedia_Sidebar]]

Please compare with the actual version of [[yi:MediaWiki:Sidebar]].

best regards reinhardt [[user:gangleri]]

Wiki.Melancholie wrote:

*** Bug 5480 has been marked as a duplicate of this bug. ***

gangleri wrote:

(In reply to comment #10)

A woraround might be *only* to use LATIN characters as described at
[[yi:MediaWiki_talk:Sidebar#MediaWiki_messages_used_at_the_yi.wikipedia_Sidebar]]
Please compare with the actual version of [[yi:MediaWiki:Sidebar]].

*note*
[[ka:MediaWiki:Sidebar]] (what bug 5480 is about) dit never ever contain Georgian
characters. Please forget the "speculation" from comment 10.

gangleri wrote:

Looking in my browser at the sourcode for [[ka:MediaWiki:Sidebar]] I couls see:
<!-- Served by srv19 in 0.09 secs. -->
There is neither a timestamp nor other information.

*question*
What (additional comments) would be required to trace such kind of issues as the one
fom bug 5092?

Wiki.Melancholie wrote:

It happens again right now; see [[:als:Houptsyte]]!
Can you see it (compare with [[:als:MediaWiki:Sidebar]])?

Deletion of earlier versions and saving MediaWiki:Sidebar again and again (also with
little changes) did not solve this problem. Strange, isn't it?

Wiki.Melancholie wrote:

(In reply to comment #14)

...did not solve this problem...

Just to be articulate: ...did not fix the bug...

Note: If I would edit and save MediaWiki:Sidebar (even without changing something)
the correct Sidebar would be shown again (for some hours/days ;-), but I will wait
until you had a look on it.

Wiki.Melancholie wrote:

I found something weird by the way:
When I change the standard sidebar on a new wiki, the first line is shown as removed
on the diff view. See http://als.wikibooks.org/w/index.php?title=MediaWiki:
Sidebar&curid=1282&diff=3790&oldid=2716 for example.

gangleri wrote:

(In reply to comment #16)

I found something weird by the way:
When I change the standard sidebar on a new wiki, the first line is shown as

removed ...

But this did not happen at
http://als.wikiquote.org/w/index.php?title=MediaWiki%3ASidebar&diff=4570&oldid=3616

The timestamps of the "previous" messages both on 'Wikibooks' and 'Wikiquote' is
identical:
05:39, 2. Dez 2005 MediaWiki default

[[b:als:MediaWiki:Sidebar]] shows for me:
<!-- Served by humboldt in 0.196 secs. -->

[[q:als:MediaWiki:Sidebar]] shows for me:
<!-- Served by srv64 in 0.053 secs. -->

Wiki.Melancholie wrote:

(In reply to comment #17)

Yes, it did not happen at als.wikiquote, because I added an empty line at the top to
test if this might work!
If this maybe (*only maybe*) has something to do with this bug, we will see it when
comparing b:als and q:als (if this bug should occur there, too).

Did a developer see comment #14 and the effect on w:als? Note: In the meantime
MediaWiki:Sidebar has been rolled back by a sysop. This bug becomes really annoying!

gangleri wrote:

has been reported again at [[yi:project:Bugs#005]]

Wiki.Melancholie wrote:

*** Bug 5519 has been marked as a duplicate of this bug. ***

Wiki.Melancholie wrote:

Another weird effect occurred on zh.WP, see bug 5519. I think that is related to
this bug, as nothing had been changed to MediaWiki:Sidebar there, too.

beesley wrote:

The same was reported on Korean Wiktionary yesterday.

Wiki.Melancholie wrote:

BTW: The bug is still there; see [[als:Houptsyte]]!

Nux added a comment.Sep 15 2006, 9:17 PM

In case anybody was wondering it's also still there on pl-wiki. It's not so
anoying since we have a JS backup script, but could be wired for those that
don't like JS and have it turned off. Anyway you can have a peak in the source
to check it out [[pl:123456]]

Wiki.Melancholie wrote:

For those who might be interested: The mentioned JS script can be found at
[[pl:MediaWiki:Monobook.js#sidebarProceduraAwaryjna]]!

Nux added a comment.Sep 16 2006, 2:42 PM

I've just added some comments in the script. If anyone will be interested in
using this. Here's the thing you should do:

  1. Empty edit on your MediaWiki:Sidebar (this will give you proper sidebar).
  2. View source of the page and look for "p-navigation".
  3. Copy the code in the div (including header element <h5>).
  4. Paste the code in ''.
  5. Remeber to add \ on end of each line between ''.

The script is not very nice as it uses innerHTML method to insert HTML code, but
it works and it's short :).

brion added a comment.Sep 19 2006, 8:49 AM
  • Bug 7370 has been marked as a duplicate of this bug. ***

hrekkjalomur wrote:

This also happens on is.wiki.

It seems to happen on low-memory conditions on my own wiki. Especially annoying if the obsolete version gets into object cache.

  • Bug 12986 has been marked as a duplicate of this bug. ***

Aphaia wrote:

It happens on meta regularly and recently ... since this January or so, not far from the past. The default setting (not localized with [[mediawiki:Sidebar]]) appears then, we can get back our setting just purging the message, but well, it would be nice to see this bug fixed. Thanks.

Huji added a comment.Feb 18 2008, 11:48 PM

Today, I read on Persian Wikipedia that this has happened again. In Persian Wikipedia, there has been instances of Sidebar falling back to English version for a short time, and then getting fixed automatically. Just wanted to keep this bug live.

Wiki.Melancholie wrote:

This happens on all wikis, again and again (and pretty often again since 2008 > caching)!
Even on de.wikipedia this has been noticed several times now (see [[w:de:Wikipedia:Fragen_zur_Wikipedia/Archiv/2008/Woche_06#Wer_hat_denn_nun_schon_wieder_an_der_Navigationsleiste_rumgespielt.3F]] for example).

On smaller wikis the effect is worst, I guess (traffic/cache reasons?). And especially on smaller wikis it takes longer until a sysop sees it and reacts to it.

Sorry, but this bug is getting very old and *very* annoying!

Please just create individual fallback messages for [[MediaWiki:Sidebar]] (a file like SidebarDeWiktionary.php (acc. to MessagesDe.php)) and *keep them up to date* by a server-side script for example (or BetaWiki?).

Is this bug really that difficult to fix??

Wiki.Melancholie wrote:

As this bug occurs pretty often the last months, I made a JavaScript that will alert (in navigation box) any SysOp to flush the sidebar's cache (empty edit) by one click if the sidebar falls back! Saving is done automatically (with return-to-redirect) and a tally is updated automatically, too (http://tools.wikimedia.de/~daveross/feedback.php?mode=view&langs=bugzilla&wikis=wikimedia).

  • [[wikt:de:MediaWiki:If-sidebar-bug.js]] (included by Monobook.js)

You have to replace the following stuff:

  1. "n-verzeichnisse" by any ID that is not in the fallback version
  2. the German text ;-)

Wiki.Melancholie wrote:

I had to make some changes to the script from yesterday ([[wikt:de:MediaWiki:If-sidebar-bug.js]]), as the array wgUserGroups made problems if being not defined at all for IPs, or if accessed by .indexOf() with IE!

  • [[wikt:de:MediaWiki:If-sidebar-bug.js]] (included by Monobook.js; works with FF, Safari, Opera, IE)

Sorry for that!

brion added a comment.Apr 29 2008, 8:09 PM
  • Bug 13842 has been marked as a duplicate of this bug. ***

Wiki.Melancholie wrote:

Although the script was interfering with an user script on dewiktionary causing false alerts for one user (what is fixed now) the tally showed me that on [[wikt:is:]] it seems to happen rather often, so I had a look on it. As I visited *any* page but the main page the sidebar was ok. When I visited the Main_Page there, the sidebar was fallen back (but only on the main page, was not logged in)! Only after (?action=)purging the main page, the sidebar was ok. Didn't see this bug happen this way, so long. Was the Main_Page just cached in the wrong moment (implying that a edit of [[MediaWiki:Sidebar]] is not clearing page caches)?

mccormack wrote:

Since we started to get this bug on English Wikiversity a couple of weeks ago, it has been recurrent. It's definitely a server cache issue - different users on different sides of the globe get hit by it almost at the same minute. It would seem that if we update [[MediaWiki:Sidebar]], this clears the cache the reinstates the proper version of the sidebar for a day or so - perhaps a few days. But after a while an unknown trigger causes the sidebar to fall back again to the default. This has now happened repeatedly - perhaps 4 to 6 times, perhaps more, in a cycle. It definitely did not happen before about a couple of weeks ago.

Wiki.Melancholie wrote:

It seems that this happens the same time every day, see
http://tools.wikimedia.de/~daveross/feedback.php?mode=view&langs=bugzilla&wikis=wikimedia

It occurs around 20:00 o'clock UTC.

Is there maybe a periodic server process that could cause this bug?

brion added a comment.May 5 2008, 11:23 PM

By default, the message & sidebar caches each expire after 24 hours... probably some ugly interaction there.

Bryan.TongMinh wrote:

*** Bug 14061 has been marked as a duplicate of this bug. ***

Wiki.Melancholie wrote:

*** Bug 14135 has been marked as a duplicate of this bug. ***

Wiki.Melancholie wrote:

Notes of bug 14135:

  • MessagesEn.php was used as fallback for sidebar instead of MessagesKsh.php
  • action=purge helped in this case
  • lasted 25 min

Wiki.Melancholie wrote:

Bug seems fixed since 2008-05-22.
If not really, just reopen this bug again!

  • Bug 54326 has been marked as a duplicate of this bug. ***
  • Bug 52682 has been marked as a duplicate of this bug. ***

I doubt this has ever been fixed for real.

(Nikerabbit on bug 54326 comment #3)

I believe this is a known thing existing for years: when message cache (for
MediaWiki namespace) creation takes too long (usually when all caches are
empty), MediaWiki will skip it and display the default messages, which will
then get cached in the separate sidebar cache.

I'm told this is happening since yesterday's update on Meta-Wiki for MediaWiki:Ipbreason-dropdown and that purging or deleting (and restoring) didn't help for Billinghurst and Trijnstel (presumably en and nl interface respectively).

(In reply to Nemo from comment #49)

I'm told this is happening since yesterday's update on Meta-Wiki for
MediaWiki:Ipbreason-dropdown and that purging or deleting (and restoring)
didn't help for Billinghurst and Trijnstel (presumably en and nl interface
respectively).

en interface for me on meta and en-gb for billinghurst

see also bug 61945 and bug 61942

Happened for MediaWiki:Sidebar on it.wikiquote for a few days till yesterday; bug it may be bug 64230 instead.

Kronf added a subscriber: Kronf.Feb 19 2015, 5:27 PM

Happened two times on de.wiktionary recently (17.02. about 19:30 GMT and 19.02. about 16:20 GMT), lasting up to 2 hours until a sysop came around to do a null edit.

He7d3r updated the task description. (Show Details)Jan 8 2016, 3:47 PM
He7d3r set Security to None.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 8 2016, 3:47 PM
He7d3r updated the task description. (Show Details)Jan 8 2016, 3:49 PM
He7d3r removed a subscriber: wikibugs-l-list.

Change 284512 had a related patch set uploaded (by Aaron Schulz):
Make MessageCache handle lock timeouts better

https://gerrit.wikimedia.org/r/284512

Change 284512 merged by Ori.livneh:
Make MessageCache handle lock timeouts better

https://gerrit.wikimedia.org/r/284512

Change 284696 had a related patch set uploaded (by Ori.livneh):
Make MessageCache handle lock timeouts better

https://gerrit.wikimedia.org/r/284696

Change 284696 merged by Ori.livneh:
Make MessageCache handle lock timeouts better

https://gerrit.wikimedia.org/r/284696

aaron closed this task as Resolved.Apr 21 2016, 3:50 PM
aaron claimed this task.
aaron added a subscriber: aaron.

I doubt this has ever been fixed for real.
(Nikerabbit on bug 54326 comment #3)

I believe this is a known thing existing for years: when message cache (for
MediaWiki namespace) creation takes too long (usually when all caches are
empty), MediaWiki will skip it and display the default messages, which will
then get cached in the separate sidebar cache.

That cache pollution problem should be avoided from here on.