Last modified: 2013-10-03 22:42:57 UTC
The API is giving completely wrong results for new pages listings. The URL given gives the following result (currently) for [[Life in Technicolor II]]: <rc type="new" ns="0" title="Life in Technicolor II" rcid="262418754" pageid="20557392" revid="256059474" old_revid="0" user="I need a name" timestamp="2008-12-05T16:07:45Z" /> except: *The article was not created by the given user *The article had no edits within several minutes of the given timestamp *The article was patrolled under its original title - http://en.wikipedia.org/w/index.php?title=Special%3ALog&type=patrol&page=+Life+in+Technicolor+ii *The pageid is wrong, not the pageid for either the current or previous title (its a non-existent page according to the API) other entries seem to have similar problems. AFICT, the similarity between them is that they were all moved to a new title. Special:Newpages is giving correct results, so the problem seems to be in the API.
I suspect that what is happening is that the recentchanges entry for the creation of a page (as a redirect) is not being deleted when the target page is moved over the redirect. Can someone verify the following (using MySQL): 1. Create a page, Test A. 2. Create a page, Test B, as a redirect to Test A. 3. Check the recentchanges API call, to verify that the entries for Test A and Test B both show up. 4. Move Test A to Test B over the redirect. 5. Check the recentchanges API call again. The entry for the creation of Test B will still be there.
(In reply to comment #1) > I suspect that what is happening is that the recentchanges entry for the > creation of a page (as a redirect) is not being deleted when the target page is > moved over the redirect. Can someone verify the following (using MySQL): > > 1. Create a page, Test A. > 2. Create a page, Test B, as a redirect to Test A. > 3. Check the recentchanges API call, to verify that the entries for Test A and > Test B both show up. > 4. Move Test A to Test B over the redirect. > 5. Check the recentchanges API call again. The entry for the creation of Test B > will still be there. Tried this locally with r45406. After doing the above, an API recentchanges query gives me 'new' entries for both Test A and Test B. Special:Newpages, on the other hand, lists only Test A, regardless of whether 'show redirects' is selected.
How about Special:RecentChanges?
(In reply to comment #3) > How about Special:RecentChanges? Same as the API -- lists 'new' entries for Test A and Test B (plus a log entry for the move).
Closing this bug as INVALID as I don't see how the API (or any other part of MW for that matter) is at fault here. First, list=recentchanges lists the stuff Special:Recentchanges lists, and filters it by the given criteria. The fact that some people use rctype=new to mimick Special:Newpages behavior doesn't mean that rctype=new should behave like Special:Newpages. Second, while the data in a list=recentchanges entry was accurate at the time the entry was created, that doesn't mean it still is. All the entry quoted in comment #0 means that the specified user created a page with the specified title (which at that moment had the specified page ID) at the specified time, which is fully correct. When moving a title, the page ID doesn't change, so that's your best bet when trying to identify the current title of the page in question. If the page ID is non-existent, the only explanation is that someone deleted the page, possibly after it was moved. Also, the deleted page could have been recreated.
If a page is deleted, its removed from the RC table, the same should be true for a page moved over a redirect, as the original redirect is essentially deleted before the move (the redirect revision is actually completely inaccessible, that might also be considered a bug). Reopened and summary updated. When moving a page over a redirect, it should remove the RC entry for the original page creation if it still exists, and its possibly skipping other things that normal deletion does.
Changed component to "RecentChanges"
Filed bug 19871 for the disappearing revision issue.
Fixed in r53659.
