Page MenuHomePhabricator

Moved new pages don't appear in Special:Newpages
Closed, ResolvedPublic

Description

  1. create a new page with wrong name

1a. it appears in special:newpages

  1. move it to the new name
  2. delete the wrong name (redirect page)
  3. neither of them shows up in special:newfiles

Version: unspecified
Severity: normal

Details

Reference
bz3481

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:48 PM
bzimport set Reference to bz3481.
bzimport added a subscriber: Unknown Object (MLST).

robchur wrote:

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.

h.hilker wrote:

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] ~~~~

robchur wrote:

(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.

happy_melon wrote:

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.

ayg wrote:

The correct fix here is to update the recentchanges entries, if that's considered correct. (Which seems reasonable enough to me.)