Last modified: 2014-05-07 20:17:11 UTC
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,
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.
The cache shouldn't be reverting to old versions. This may be related to general
message cache problems getting frozen in the sidebar cache.
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 ;-)
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 ;-)
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)
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?
Right now it occured once more on [[:als:]]. Furthermore a user
reported, that the sidebar sometimes even falls back to an English
This is also common on the Persian Wikipedia where it frequently falls back to
the LanguageFA.php version.
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
188.8.131.52! 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?
Same happened the 26th of March 2004 with
I did not find the time to ask at #mediawiki about what particular changed
A woraround might be *only* to use LATIN characters as described at
Please compare with the actual version of [[yi:MediaWiki:Sidebar]].
best regards reinhardt [[user:gangleri]]
*** Bug 5480 has been marked as a duplicate of this bug. ***
(In reply to comment #10)
> A woraround might be *only* to use LATIN characters as described at
> Please compare with the actual version of [[yi:MediaWiki:Sidebar]].
[[ka:MediaWiki:Sidebar]] (what bug 5480 is about) dit never ever contain Georgian
characters. Please forget the "speculation" from comment 10.
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.
What (additional comments) would be required to trace such kind of issues as the one
fom bug 5092?
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?
(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.
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.
(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
But this did not happen at
The timestamps of the "previous" messages both on 'Wikibooks' and 'Wikiquote' is
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. -->
(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!
has been reported again at [[yi:project:Bugs#005]]
*** Bug 5519 has been marked as a duplicate of this bug. ***
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.
The same was reported on Korean Wiktionary yesterday.
BTW: The bug is still there; see [[als:Houptsyte]]!
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]]
For those who might be interested: The mentioned JS script can be found at
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 :).
*** Bug 7370 has been marked as a duplicate of this bug. ***
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. ***
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.
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.
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??
* [[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 ;-)
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!
*** Bug 13842 has been marked as a duplicate of this bug. ***
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)?
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.
It seems that this happens the same time every day, see
It occurs around 20:00 o'clock UTC.
Is there maybe a periodic server process that could cause this bug?
By default, the message & sidebar caches each expire after 24 hours... probably some ugly interaction there.
*** Bug 14061 has been marked as a duplicate of this bug. ***
*** Bug 14135 has been marked as a duplicate of this bug. ***
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
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.
https://zh.wikipedia.org/w/index.php?title=Taeniura_meyeni&action=history - happened in autosummary just now.
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
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.