Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 5311 - One sees a page as it appeared BEFORE an edit
 Summary: One sees a page as it appeared BEFORE an edit
 Status: Product: RESOLVED FIXED MediaWiki Unclassified Component: Page editing (Other open bugs) unspecified All All Low normal with 1 vote (vote) --- Nobody - You can work on this! (view as bug list) Show dependency tree / graph

 Reported: 2006-03-21 22:30 UTC by Michael Hardy 2011-10-05 22:01 UTC (History) 6 users (show) alexis aschulz4587 b mike.lifeguard+bugs tstarling Wiki.Melancholie --- --- ---

Attachments

 Michael Hardy 2006-03-21 22:30:34 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. Brion Vibber 2006-03-21 22:40:30 UTC 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?  Melancholie 2006-03-22 02:02:21 UTC @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. Michael Hardy 2006-03-22 02:14:44 UTC 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?  Brion Vibber 2006-03-22 02:23:34 UTC 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? Melancholie 2006-03-22 02:41:45 UTC 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! Melancholie 2006-03-22 02:51:18 UTC 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. Melancholie 2006-03-22 02:58:23 UTC 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?). Brion Vibber 2006-03-22 02:59:55 UTC 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. Melancholie 2006-03-22 04:40:10 UTC 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) Melancholie 2006-03-22 04:47:56 UTC > 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. Melancholie 2006-03-24 01:29:30 UTC @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. Michael Hardy 2006-03-24 03:22:33 UTC I was logged in when it happened. It's happening less frequently today. But it just recurred a few minutes ago. Michael Hardy 2006-03-24 03:25:36 UTC 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.  Brion Vibber 2006-03-24 07:06:36 UTC 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 Wilke 2007-08-21 07:18:40 UTC 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. Aaron Schulz 2008-05-10 23:07:55 UTC *** Bug 14072 has been marked as a duplicate of this bug. *** Mike.lifeguard 2008-10-30 05:30:21 UTC 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. Aaron Schulz 2009-01-13 22:43:12 UTC Seems like this has to be a bug with squid purging Aaron Schulz 2009-01-13 22:44:04 UTC (In reply to comment #18) > Seems like this has to be a bug with squid purging > Or slave lag... MZMcBride 2009-01-15 02:05:04 UTC 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. Tim Starling 2009-01-15 02:11:42 UTC 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. Tim Starling 2009-02-17 07:58:22 UTC 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. Michael Hardy 2011-10-05 21:04:03 UTC 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.

 Note You need to log in before you can comment on or make changes to this bug.