I've checked in the updates to recentmoves in case anyone is interested in basing a patch on it. It's worth noting that it is not a single query as written right now - it does some filtering of the query in procedural code. This is largely due to fields which have a format too complex to match with the SQL LIKE operator. I also haven't tested it with databases other than MySQL.

Why would NPF be a lower priority? Note that NPF intentionally lists moves.

Ah, just saw Nemo's comment; ignore me.

swalling wrote:

(In reply to comment #16)

Ugh, the way recentchanges is stored isn't the most ammenable to fixing this
bug. (Its not the most accesible to filter by what the target namespace of
the
move is).

Options:

1. Totally redo the recentchanges schema (Unlikely to happen)
2. Move Derrick's http://toolserver.org/~dcoetzee/recentmoves/ into core (aka

create a new special page, called Special:Recentmoves that lists all recent
moves)

3. As part of the page move process, retroactively change the

rc_title/rc_namespace of the creation entry in recentchanges table.

Option 3 seems rather hacky. (Especially seems hacky if one only changes the
page creation entry, and not subsequent edits. This would make all the recent
change entries change from "created page at [original title]" to "created
page
at [final title]")

None of these options seem really good fixes to the problem (Problem being
Special:newpages. I'm not familiar with newpagesfeed).

Oliver says NewPagesFeed already lists page moves. If this is the case, then we should be evangelizing use of that tool as a short term solution.

The above solution is only good for enwiki though. If it's inordinately difficult to add recent moves to Special:NewPages, then I think Option 2, and creation of a proper Special:RecentMoves, would be the ideal case for most Wikimedia wikis.

Ideally, a Special:RecentMoves would...

• Be able to be filtered by moves within any namespace
• Be able to be filtered down to cross-namespace moves

Brian, I added Dan Garry to this bug, as it seems like it's a part of Platform's remit. Dan, does that sound reasonable?

(In reply to comment #20)

Oliver says NewPagesFeed already lists page moves. If this is the case, then
we
should be evangelizing use of that tool as a short term solution.

Verified that Special:newpagesfeed does not have this bug.

Like special:newpages, special:newpagesfeed lists moved pages under their original creation date. This makes logical sense, however when I was testing examples on wikipedia, I noticed that lots of these pages were created long ago (often several months), thus in a sense these "new pages" appear at the bottom of the list, when they do appear, and hence perhaps still avoiding some scrutiny.

The above solution is only good for enwiki though. If it's inordinately
difficult to add recent moves to Special:NewPages, then I think Option 2, and
creation of a proper Special:RecentMoves, would be the ideal case for most
Wikimedia wikis.

Ideally, a Special:RecentMoves would...

• Be able to be filtered by moves within any namespace
• Be able to be filtered down to cross-namespace moves

Brian, I added Dan Garry to this bug, as it seems like it's a part of
Platform's remit. Dan, does that sound reasonable?

Hmm, I wonder what the performance implications of Select * from recentchanges inner join page on page_id = rc_cur_id where rc_new = 1 and rc_namespace != page_namespace and page_namespace = 0; Seems like that would be a bit more scary then what normally can go on 'pedia. Then again, that's probably similar to the performance of Special:Recentchangeslinked, so maybe... [Saying this without doing any testing whatsoever, probably totally wrong].

swalling wrote:

(In reply to comment #21)

The above solution is only good for enwiki though. If it's inordinately
difficult to add recent moves to Special:NewPages, then I think Option 2, and
creation of a proper Special:RecentMoves, would be the ideal case for most
Wikimedia wikis.

Ideally, a Special:RecentMoves would...

• Be able to be filtered by moves within any namespace
• Be able to be filtered down to cross-namespace moves

Brian, I added Dan Garry to this bug, as it seems like it's a part of
Platform's remit. Dan, does that sound reasonable?

Hmm, I wonder what the performance implications of Select * from
recentchanges
inner join page on page_id = rc_cur_id where rc_new = 1 and rc_namespace !=
page_namespace and page_namespace = 0; Seems like that would be a bit more
scary then what normally can go on 'pedia. Then again, that's probably
similar
to the performance of Special:Recentchangeslinked, so maybe... [Saying this
without doing any testing whatsoever, probably totally wrong].

Stupid question: since this filtering is done by the user, is it perhaps better to gather the list of all moves, then do a filter for moves where the new/target namespace is mismatched on the client side, rather than in SQL? Since nothing would prevent users without JS from viewing the list, that seems like a nice to have feature.

swalling wrote:

Poke. Any movement on this?

Just a review to ensure that I understand what is wanted:

Moves from Draft namaespace to mainspace should appear in the new pages Feed.
They should appear in the NPF chronologically on the date the move was effected.

(In reply to comment #24)

Moves from Draft namaespace to mainspace should appear in the new pages
Feed.
They should appear in the NPF chronologically on the date the move was
effected.

No. NPF is bug 36930 (I added it as a see also, not sure why it wasn't already). Also, what namespace the page is coming from shouldn't matter, it should work for any.

I still feel the same about this as I did back in Comment 4, NewPages as it's name suggest should be for NEW pages, moves aren't new pages. We should think about another log page(s) to display move actions specifically (and appropriate API queries if we don't have them) if we don't have one already.

paolobenve wrote:

Maybe nobody has thoght on that, but I'm proposing something "different":

Why can't we leave Special:NewPages as it is, and implement a Special:NewArticles page which only tracks new entries in ns0, either created or moved from nsX?

Special:MovedPages would probably be better, from the aspect that not everyone uses the "Article" terminology when referring to pages.

Then just have a couple of filters on the page for "Moved from NS X" and "Moved to NS X" a long with the standard date filters.

(In reply to comment #27)

Maybe nobody has thoght on that, but I'm proposing something "different":

It's option 2 in comment 16. Option 2 seems the easiest, but it's IMHO clear that not forcing new page patrollers to learn about another special page would be ideal. Pages moved into a namespace are "new pages" for that namespace: from the interface point of view, we would only need a checkbox, activated when a filter by namespace is selected, that also shows pages moved in that namespace.

Unless someone has ideas to discuss about option 1 or some alternatives to the hack of option 3, I think it's time for any interested dev to stop talking and just submit a patch for whatever approach they manage to create one. :)

paolobenve wrote:

I think I haven't expressed well my thoght in comment 27.

When I spoke of Special:NewArticle, different from Special:NewPages, I meant a special page which tracked all new ns0 pages, regardless of whether they are created or moved from another ns.

The idea behind recentmoves in solution 2 of comment 16 is different.

If NewArticles isn't the best denomination for this page, let's search for a better expression.

(In reply to comment #30)

I think I haven't expressed well my thoght in comment 27.

When I spoke of Special:NewArticle, different from Special:NewPages, I meant
a special page which tracked all new ns0 pages, regardless of whether they are
created or moved from another ns.

However, people will also want to know about pages that appear in other namespaces (e.g. Project or Portal). They can appear in two ways, creation and move.

I am inclined to think it should be added to NewPages.

Until someone gets to implement one of the options in comment 16, it's worth noting that one simple workaround for WMF would be to raise $wgRCMaxAge considerably. That's OT here, so if someone wants to discuss it please open another bug. :)

(To be clear, simple but not trivial to approve, and workaround but only for some part.)

paolobenve wrote:

What about creating a new special page, Special:NewArticles (perhaps a better name could be chosen)?

It could list new pages in ns0, regardless of they are created or moved from another ns.

(In reply to comment #34)

What about creating a new special page, Special:NewArticles (perhaps a better
name could be chosen)?

It could list new pages in ns0, regardless of they are created or moved from
another ns.

I don't think ns0 should have any special behavior for this use case. Special:NewPages already lets you filter by target namespace. People may be interested in other target namespaces, e.g. pages created/moved into the project namespace.

Classifying as bug. This allows pages to bypass review.

Change 148322 had a related patch set uploaded by Rohan013:
Show Page moves on Special:Newpages

https://gerrit.wikimedia.org/r/148322

Rohan's patch just gave me a (hacky) idea.

*Add an index on (rc_source, rc_log_type, rc_timestamp)
*Do the normal newpages query, taking note of the first and last timestamp returned.
*Do another query, something like: SELECT rc_title, rc_namespace, rc_params FROM recentchanges WHERE rc_source = 'mw.log' AND rc_log_type = 'move' and rc_timestamp >= $minTimestamp AND rc_timestamp <= $maxTimestamp order by rc_timestamp desc LIMIT max( 2*$whateverTheActualLimitIs, 500 )

And then in php look through rc_params for the target page filtering out those that don't match the namespace. (Originally I was thinking of doing a rc_params NOT LIKE '%:"<namespace>:' clause for each namespace, but seems more sane to do that filtering in php).

This works on the assumption that the number of moves total will be less than the normal of page creations in a given namespace for a given time period. This is mostly true for main namespace. Probably not true for others. Has a limit check for sanity which would potentially cause some page moves not to be shown if the limit is reached. I guess that's better than the current situation. Maybe we could give a warning in that case or something.

(In reply to Bawolff (Brian Wolff) from comment #38)

Rohan's patch just gave me a (hacky) idea.

*Add an index on (rc_source, rc_log_type, rc_timestamp)
*Do the normal newpages query, taking note of the first and last timestamp
returned.
*Do another query, something like: SELECT rc_title, rc_namespace, rc_params
FROM recentchanges WHERE rc_source = 'mw.log' AND rc_log_type = 'move' and
rc_timestamp >= $minTimestamp AND rc_timestamp <= $maxTimestamp order by
rc_timestamp desc LIMIT max( 2*$whateverTheActualLimitIs, 500 )

And then in php look through rc_params for the target page filtering out
those that don't match the namespace. (Originally I was thinking of doing a
rc_params NOT LIKE '%:"<namespace>:' clause for each namespace, but seems
more sane to do that filtering in php).

This works on the assumption that the number of moves total will be less
than the normal of page creations in a given namespace for a given time
period. This is mostly true for main namespace. Probably not true for
others. Has a limit check for sanity which would potentially cause some page
moves not to be shown if the limit is reached. I guess that's better than
the current situation. Maybe we could give a warning in that case or
something.

Or actually could just use logging table. Maybe add stuff to log_search table too for target look up.

So to flesh out comment 38, here's what I would suggest:

*In Title::moveToInternal, if this->getNamespace() !== $nt->getNamespace(), then do $logEntry->setRelations( array( 'new_page_helper' => sprintf( "%05d|%s", $nt->getNamespace(), $logEntry->getTimestamp() ) );

*Then we do a second query, something along the lines of "SELECT log_namespace as rc_namespace, log_title as rc_title, ... FROM log_search INNER JOIN logging ON ls_log_id = log_id where ls_field = 'new_page_helper' and ls_filed_value between " . sprintf( "%05d|%s", $targetNamespace, $firstTimestampReturnedFromMainQuery ) . " AND " . sprintf( "%05d|%s", $targetNamespace, $lastTimestampReturnedFromMainQuery ) . " ORDER BY ls_value LIMIT $limit";

Combine results using FakeResultWrapper in some manner similar to ImageListPager::combineResult.

When namespace is set to all, or an inverted namespace. Could probably just query logging table, and then join on log_search, with a ls_field_value NOT LIKE sprintf( "%05d|%', $namespace ). This would be potentially a little bit more expensive query, but still probably fine, especially because people don't look at Special:NewPages for inverted namespace all that often AFAIK. For the all namespace cases I wonder if its even appropriate to do anything, given that all moved pages already "existed" in at least one namespace, in some sense.

• Bug 69324 has been marked as a duplicate of this bug. ***

It was originally marked high because it is actively exploited by paid editors. Assuming that is still going on and the folks who check new pages for advertising have not found a good workaround, I think this should still be high.

@Qgil I have already submitted a patch for review

https://gerrit.wikimedia.org/r/#/c/148322/

Change 148322 had a related patch set uploaded (by He7d3r):
Show Page moves on Special:Newpages

https://gerrit.wikimedia.org/r/148322

Patch-For-Review

Related bug T86491

Patch needs rework, see Gerrit. - @rohan013: Do you plan to rework your patch?

The cross namespace autotag of T73236 might help solve the performance issues. In the mean time, I think I'll also introduce a 'move into mainspace' autotag so we can have this done in recentchanges at least.

Change 190656 had a related patch set uploaded (by Cenarium):
Allow patrolling of tagged changes with minimalist RC patrol

https://gerrit.wikimedia.org/r/190656

Not just moves accross namespaces are an issue, see this recent discussion.
I think we need something like Special:NewMoves and move patrol (T98617).

Change 251794 had a related patch set uploaded (by Cenarium; owner: Cenarium):
Implement Special:Newmoves and allow patrol of moves

https://gerrit.wikimedia.org/r/251794

I'm a bit concerned as to why this is being referred to as Special:NewPages. The correct default New Page Patrol GUI is at Special:NewPagesFeed. Perhaps I'm missing something.

In T14363#4302118, @Kudpung wrote:

I'm a bit concerned as to why this is being referred to as Special:NewPages. The correct default New Page Patrol GUI is at Special:NewPagesFeed. Perhaps I'm missing something.

The MediaWiki default is Special:NewPages. English Wikipedia uses an extension called PageTriage which creates the Special:NewPagesFeed patrol tool. I do not know if Special:NewPagesFeed has the same bug as Special:NewPages.

Presently,

• in Special:NewPages a page moved from User or User talk to the main space will be displayed on NewPages when all option is selected or, of course, if the namespace of creation is selected. There is the info about the page being moved:

• Special:NewPagesFeed allows to filter by Article and User namespaces, and 'Article for creation' option addresses Draft namespace.

Not implemented: the proposed improvement in the following comment, some

A simple solution [...] would be to display any pagemove into mainspace alongside mainspace creations in Special:Newpages.

and a suggestion from T183439

"Creation date" for this articles will be a move date.

In ruwiki, a page moved from User or User talk to the main space isn't displayed on NewPages when "all" option is selected or if the namespace of creation is selected, see

https://ru.wikipedia.org/w/index.php?title=Test1&action=history

https://ru.wikipedia.org/wiki/special:newpages?namespace=all

https://ru.wikipedia.org/wiki/special:newpages?namespace=2

https://ru.wikipedia.org/wiki/special:newpages?namespace=0