Last modified: 2014-06-13 12:03:05 UTC
The Teach For America page is not showing the most recent edits that I made. If I am logged in, everything shows up newly edited...if I am logged out, it does not. I thought it might be cookies so I asked others to check, they do not see the new version of the page. Link to page: http://en.wikipedia.org/wiki/Teach_for_america noted areas of discrepancy: Geographical reach Alumni Would love to know if this is something I am doing wrong when editing - but I believe all edits should go live immediately. Thanks! Bex
What you're seeing sounds like the normal result of FlaggedRevs use on Wikipedia. http://www.mediawiki.org/wiki/Extension:FlaggedRevs
The page isn't using flagged revs, (where that behaviour would be normal), so the edits should appear immediately... (see review log http://en.wikipedia.org/w/index.php?title=Special%3ALog&type=review&user=&page=Teach+For+America&year=&month=-1&tagfilter=&hide_patrol_log=1&hide_review_log=1 ) Some sort of caching issue maybe?
*** This bug has been marked as a duplicate of bug 27891 ***
Appears to be a squid cache entry that was not cleared. Can reproduce when logged out (and have cookies cleared) when viewing the redirected page [[Teach for america]] (but not the actual [[Teach For America]] page).
Thanks for tracking that bit down, Bawolff!
I was able to reproduce on testwiki. Steps to reproduce: *Create page 1 ([[test:User:Bawolff/bug29552]]) *Create page 2 redirecting to page 1 ([[test:User:Bawolff/bug29552-redir]]) *Look at both of them in a browser where you are not logged in. *Edit page 1 a couple times *Look at page 1 in the non-logged in browser. Its still the old version. page 2 is updated, and if you append a random query parameter to the url of page 1 its the new version. I believe this indicates that the squid cache is not being cleared for the redirect. Expected behaviour: Something in the job queue sends squid purge request for any page that redirects to the edited page.
So, as far as I can tell, this should be done by Article::onArticleEdit (which call's HTMLCacheUpdate, which purges squid cache of everything that redirects to the article). I have no idea why it wouldn't be happening. I don't think it should trigger the job queue since there's only a single redirect in my test case. (I don't have squid set up locally, so its kind of hard to test)
I can confirm on my local install of /branches/wmf/1.17wmf1 (with squid) and using the mediawiki config of: $wgUseSquid = true; $wgHTCPMulticastAddress = '127.0.0.1'; That HTCP purges are sent correctly, squid kills the relevant entries from cache when it gets the HTCP packet. So perhaps its something to do with Wikimedia's squid set up (Its certainly more complex than my test setup). However, that'd be weird, because it purges the direct page fine, its just the dependant redirects that don't get purged. Perhaps related to bug 28613. In any case there's not that much more I can really do to test this so unassigning from self.
bug 28613 comment 40 says the issue that I thought might be potentially causing this issue is fixed, however this issue is still present on Wikimedia (tested on test.wikipedia.org) /me really has no idea whats going on with this.
I have a question on my talkpage regarding something similar. Redirects that get re-redirected also do not seem to go to the correct target unless the cache is flushed (this is an IP editor). See http://en.wikipedia.org/w/index.php?title=User_talk:Beetstra&oldid=439412339#Homatropine.2FMethylhomatropine_wrong_redirect
*** Bug 30440 has been marked as a duplicate of this bug. ***
Moved this into Wikimedia, as per testing of Bawolff, this seems wikimedia specific.
Gerrit change #9877
It's not the issue I thought of...
I have no idea what the original cause was, but since sept 2011 see bug 38879 comment 11
I hit this issue fairly frequently on the English Wikipedia.
(In reply to comment #15) > I have no idea what the original cause was, but since sept 2011 see bug > 38879 > comment 11 job/jobs/HTMLCacheUpdateJob.php hack -> not configuration -> General/Unknown + Aaron in cc.
The hack was removed. Should verify if this is fixed.
Cannot reproduce for http://de.wikipedia.org/wiki/GNOME which received an update yesterday - also correctly showing the last version when I'm logged out (in a different browser). Is there any example or indication that this problem still exists?
Is there any example or indication that this problem still exists?
Closing as WORKSFORME as per comment 18 and comment 19. Bawolff / MZ / Liangent: If you can still reproduce (because I couldn't), please reopen this ticket.
