Last modified: 2011-10-05 22:01:24 UTC
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.
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?
@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.
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?
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!
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.
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.
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)
> 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.
@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.
I was logged in when it happened. It's happening less frequently today. But it just recurred a few minutes ago.
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)
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.
*** Bug 14072 has been marked as a duplicate of this bug. ***
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.
Seems like this has to be a bug with squid purging
(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.
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.
