Last modified: 2008-09-16 13:29:11 UTC
1. create a new page with wrong name 1a. it appears in special:newpages 2. move it to the new name 3. delete the wrong name (redirect page) 4. neither of them shows up in special:newfiles
Testing with current trunk, the previous page (redirect) seems to be retained in Special:Newpages. The new page still doesn't show up, but that's bug 5189.
The same problem occurs with the watchlist: if you create a new page which is on your watchlist and you move the article, the article disappears from your watchlist. This happened to me several times in the [http://nl.wikipedia.org dutch wikipedia] ~~~~
(In reply to comment #2) > The same problem occurs with the watchlist: if you create a new page which is > on your watchlist and you move the article, the article disappears from your > watchlist. This happened to me several times in the [http://nl.wikipedia.org > dutch wikipedia] ~~~~ This is bug 5546.
Having read bug 5109, I agree that that's not a good solution. However, is it too much to ask that, when a page is moved, its entry in [[Special:NewPages]], if there is one, is moved with it? This would seem to be both a simple solution and a logical expectation: surely the event of "being created", which is what NewPages tracks, should remain attached to the ''content'', not to a particular title?
You know, this actually looks pretty trivial to fix. NewPagesPager::getQueryInfo() is already doing a join on the recentchanges and page tables; just changing the code to use page_title and page_namespace fields instead of rc_title and rc_namespace ought to do it.
In fact, just committed a fix as r36938.
Reverted by Domas in r39941. No revert reason given.
broke index usage, forced full scan and resorting of all new pages logged in recentchanges.
Ah. Would simply always using the rc_timestamp index fix it? And if so, is there any reason to keep the new_name_timestamp around at all any more? (And is there a reason why the index has to be explicitly specified anyway?)
no, it would not fit, because new_name_timestamp was used both for selection of records, and for actual sorting. and the index has to be specified, because otherwise database engine may chose not to use it.
The correct fix here is to update the recentchanges entries, if that's considered correct. (Which seems reasonable enough to me.)
Fixed in r40912
