Last modified: 2011-10-05 22:01:24 UTC

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
One sees a page as it appeared BEFORE an edit
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
All All
: Low normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: 14072 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2006-03-21 22:30 UTC by Michael Hardy
Modified: 2011-10-05 22:01 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description 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.
Comment 1 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?
Comment 2 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.
Comment 3 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?

Comment 4 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 
Comment 5 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!
Comment 6 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
Comment 7 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?).
Comment 8 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.
Comment 9 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)
Comment 10 Melancholie 2006-03-22 04:47:56 UTC
> As more people visit a page as faster the cached version of the page is
 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.
Comment 11 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.
Comment 12 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.
Comment 13 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.

Comment 14 Brion Vibber 2006-03-24 07:06:36 UTC
Taking a peek:

at :
This page was last modified 03:28, March 24, 2006.

at :
(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)
Comment 15 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:

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.
Comment 16 Aaron Schulz 2008-05-10 23:07:55 UTC
*** Bug 14072 has been marked as a duplicate of this bug. ***
Comment 17 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.
Comment 18 Aaron Schulz 2009-01-13 22:43:12 UTC
Seems like this has to be a bug with squid purging
Comment 19 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...
Comment 20 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.
Comment 21 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.
Comment 22 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.
Comment 23 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.