Last modified: 2008-09-16 13:29:11 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T5481, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 3481 - Moved new pages don't appear in Special:Newpages
Moved new pages don't appear in Special:Newpages
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: easy
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-16 13:47 UTC by Peter Gervai (grin)
Modified: 2008-09-16 13:29 UTC (History)
7 users (show)

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


Attachments

Description Peter Gervai (grin) 2005-09-16 13:47:47 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
Comment 1 Rob Church 2007-01-15 16:57:16 UTC
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.
Comment 2 hanhil 2007-08-23 22:00:38 UTC
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] ~~~~
Comment 3 Rob Church 2007-08-23 22:05:14 UTC
(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.
Comment 4 Happy-melon 2008-07-02 16:33:28 UTC
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?
Comment 5 Ilmari Karonen 2008-07-02 18:20:46 UTC
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.
Comment 6 Ilmari Karonen 2008-07-02 18:56:53 UTC
In fact, just committed a fix as r36938.
Comment 7 Siebrand Mazeland 2008-08-25 10:02:27 UTC
Reverted by Domas in r39941. No revert reason given.
Comment 8 Domas Mituzas 2008-08-25 10:05:08 UTC
broke index usage, forced full scan and resorting of all new pages logged in recentchanges. 
Comment 9 Ilmari Karonen 2008-08-25 10:17:48 UTC
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?)
Comment 10 Domas Mituzas 2008-08-25 11:29:48 UTC
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. 
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-08-25 14:24:18 UTC
The correct fix here is to update the recentchanges entries, if that's considered correct.  (Which seems reasonable enough to me.)
Comment 12 Aaron Schulz 2008-09-16 13:29:11 UTC
Fixed in r40912

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


Navigation
Links