Author: hardy
Description:
After an edit, as of a day or two ago, one sees the
page as it appeared BEFORE the edit. Only after
reloading, sometimes several times, does the newly
current version of the page appear.
Version: unspecified
Severity: normal
Happened a long time ago and now fixed, or happens currently?
Exactly where are you editing that you see this?
Are you logged in at the time?
With what browser, version, OS?
Wiki.Melancholie wrote:
@Michael Hardy: Pages on wikis using MediaWiki, especially on Wikimedia wikis,
are cached to reduce server load. If you should need to see the current revision
immediately you could have a look on the diff of the last change, or you could
add ?action=purge (respectively &action=purge) to the URL field in your browser.
As this is a very common cache effect, that (in all likelihood) is intended, I
close this bug now.
hardy wrote:
You say "in all likelihood". That implies uncertainty.
This started happening only about 48 hours ago. Can't
you find out how it changed at that time before drawing
a conclusion about the intent?
Melancholie: pages are cached, but when they are edited the cache is cleared, and is
supposed to be cleared *immediately*. Please don't provide misinformation. Thanks.
Michael: happens only on one computer or on many? Can you answer the questions
above?
Wiki.Melancholie wrote:
I know that those effects got worse in the last days, but I also know that such
effects appear regularly, particularly when Wikipedia is slow because of
overstressed servers. I reopen this bug now; Brion knows better whether this is
intended or *not*. But I know this effect since years now! When I change an
article, log out, clear my browser cache and watch the article again, I see a
old revision pretty often! And it doesn't matter which OS or browser I use. And
this happens for the time I am contributing to Wikipedia (~2 years), so I wonder
that this finally is a BUG!
Wiki.Melancholie wrote:
Oh: When I log in again, the current revision is shown, by the way. But logged
out and with a purged browser cache the previous revision is shown.
@brion: Almost every active user must have experienced this effect, I would say
(I often have a look on the help pages and the village pumps of several wikis,
where this is described regularly), so I wonder why you never heard from this
effect.
Wiki.Melancholie wrote:
Because it seems that this is *not* intended, see also Bug 2388 (the effect
there is well known, too; has that problem there the same reason?).
Of *course* that's a bug. If that *ever* happens it's a bug.
Under the current system, you should *never* see it happen when logged in. If you do
see it, I need some details.
When logged out, lag or bugs in the proxy chain would make it rather more likely
that you could see an incorrectly cached version.
Wiki.Melancholie wrote:
Details when this appeared while being *logged in*: At least with Firefox and
Opera (under Linux, and as far as I can remeber under Windows as well). It
happens in all namespaces. The last time this happened: Today, at least two times.
Details when this appeared while being *logged out*: At least with Firefox and
Opera (under Linux and Windows). At the time the Alemannic Wikipedia was visited
not very often, the main page there sometimes lagged two days. As more people
visit a page as faster the cached version of the page is up-to-date. You can
watch this effect on every main page of smaller wikis (where the "article of the
day" template often lags for many hours; for example even -> wikt:de)
Wiki.Melancholie wrote:
As more people visit a page as faster the cached version of the page is
up-to-date.
Fix >> The more people visit a page, the faster the cached version of the page
is up-to-date.
And I think the problem described at bug 2388 is the worst case of this problem.
Wiki.Melancholie wrote:
@Michael Hardy: Have you been logged in at the time that occured; see comment #1.?
Just to clarify: For me this effect never took more than some minutes when being
logged in. When being logged out, Michael's description is pretty familiar to me.
hardy wrote:
I was logged in when it happened.
It's happening less frequently today. But it
just recurred a few minutes ago.
hardy wrote:
It happened after I edited [[Chinese restaurant process]]
a few minutes ago. After a few minutes, a reload showed the
newly edited version, but then I clicked on the edit history,
and my latest edit does not appear in the history at all,
despite the fact that I see the material I added when I view
the page.
Taking a peek:
at http://en.wikipedia.org/wiki/Chinese_restaurant_process :
This page was last modified 03:28, March 24, 2006.
at http://en.wikipedia.org/w/index.php?title=Chinese_restaurant_process&action=history :
(cur) (last) 03:28, March 24, 2006 Michael Hardy
Had you loaded the history before that check that showed it to be missing?
Had you loaded the history before the edit?
Did you try reloading the history?
Did you try a force-reload of the history? (w/ ctrl and/or shift)
alexis wrote:
Hi guys,
I ran in the same problem with mediawiki-1.10.1 in Aug 20, 2007.
I'm running Apache 2.x on a Ubuntu Linux fully up to date with PHP 5.x and Postgresql 8.1.
I solved the problem using the following change in my LocalSettings.php file:
$wgEnableParserCache = false;
$wgCachePages = false;
which I found on this page:
http://meta.wikimedia.org/wiki/MediaWiki_FAQ#How_do_I_completely_disable_caching.3F
The caching problem (Me, I'll call it a bug, but you can call that a feature, of course) is in mediawiki.
Note that being logged or not makes no difference. Several people experienced the problem with our wiki so it is not the browser, it is the mediawiki cache management.
If you think you have a fix in 1 year or so, let me know.
Thank you.
mike.lifeguard+bugs wrote:
This has happened to me a number of times today (and a few others have reported similar issues), so this is still an ongoing problem. However this seems to affect page creations moreso than edits.
(In reply to comment #18)
Seems like this has to be a bug with squid purging
Or slave lag...
This is still an issue on WMF wikis (currently running r45489).
It can happen after simple editing or after submitting a new page (the user is redirected to the "no article with this title" text.
Experiencing the issue after a simple edit is bad enough, but seeing the "no article" text after submitting a new page is much worse. Any poking into this would be much appreciated.
Tim suggested this could be squid-related or local parser cache-related.
It's unlikely to be squid related if it happens with new pages, the new page would have to be cached despite cache suppression headers. It's not what I said on IRC about parser cache configuration, that only potentially explains comment 15.
The important point I was trying to make is that this is a failure mode, not a bug. It can be caused by lots of different things, including local site configuration. It might be better if this was a tracking bug, like bug 4899, instead of a report that's continually reopened each time someone sees it, and reclosed when the issue relevant to the report at hand is resolved.
The issue as per comment 17 and 20 appears to be slave lag, exposed by the disabling of ChronologyProtector via a live patch. Article::getID() gets its page_id from the slave and then Article::view() uses that information to decide whether to show the page.
hardy wrote:
I'm going to try this with a few different browsers and a few different computers, and maybe change my Wikipedia preferences and see if it works differently. Hopefully that will tell us whether the problem is with MathJax or something else.