Wikimedia Bugzilla is closed!

Changed component to "RecentChanges"

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

More recently, some users on enwiki have been subverting new page patrol by taking articles submitted at Articles for Creation which were declined (not accepted for publishing in mainspace), and moving them into mainspace anyway. One user has proposed move-protecting these pages to avoid the problem (see https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Articles_for_creation#Arbitrary_section_break), but clearly moves from user sandboxes, Wikiproject drafts in project space, etc. are just as dangerous in their potential for avoiding scrutiny. This proposed feature is the right way to deal with the problem.

In my opinion the way this feature should work is, when viewing new pages in any particular namespace, it should include moves into that namespace from other namespaces (since they are "new" to that namespace). Newpages over all namespaces should work the same as it does now. This would help it to be more generally useful. This could be made a checkbox option, if there is some reason this behavior is not always desirable.

I'm in the feeling that this should a wontfix, NewPages as the page name suggests should only list new page creations which pages moves aren't.

+1 Derrick Coetzee!

Actually in wikipedia and most of other mediawiki project, ns0 is higher rank than other ns, it's not the same thing to create a page in some namespace and to create an article.

I think that the new pages feature should address principally article creations, and so moving a page to an article should be reported in special:Newpages

(In reply to comment #4)
> I'm in the feeling that this should a wontfix, NewPages as the page name
> suggests should only list new page creations which pages moves aren't.

I partially disagree.  Page moves within main space are not new page creations, but page moves from a different namespace into main space are most definitely new page creations and need to be patrolled.

For now, I've implemented a tool on Toolserver called "Recent moves" to address this problem:

http://toolserver.org/~dcoetzee/recentmoves/

I hope I can encourage people to start patrolling it.

ok, but it "solves" the problem for wikipedia, not for all other mediawiki installation...

I agree that this should be fixed in Mediawiki eventually. But I know that will take time, so the tool is a temporary stopgap measure.

This is currently being actively exploited on a large scale by a group of paid editors on ENWP to get their pages in to article space without having them scrutinized. More details about their activities available via email request, but their activity is significant enough to make this worth fixing quickly. (Also in email communication with Dan about this, who I'll add to the CC list fi I can figure out how.)

This bug may be being actively misused on the English Wikipedia. We need to get this fixed.

CCing Fabrice Florin, the product manager for page curation, to get his input.

(In reply to comment #11)
> This bug may be being actively misused on the English Wikipedia. We need to
> get
> this fixed.
> 
> CCing Fabrice Florin, the product manager for page curation, to get his
> input.

Just to clarify, the original request was for 
Special:newpages not special:newpagesfeed. Are you saying this is an issue/you want this fixed for both?

(In reply to comment #12)
> Just to clarify, the original request was for 
> Special:newpages not special:newpagesfeed. Are you saying this is an
> issue/you
> want this fixed for both?

That would be a separate bug. I'd focus on Special:NewPages, among other reasons because it's more used (https://toolserver.org/~dartar/pc/).

I'm not sure if the same issue applies to newpagesfeed, but I would agree with Nemo that getting newpages fixed would be a higher priority.  If the same issue does apply with newpagesfeed, it should be fixed there as well, but it would be a lower priority.

Just a heads up, at least for enwiki, http://toolserver.org/~dcoetzee/recentmoves/ is operational again (it was broken by MW1.19 changes to log_params field and I didn't notice until now). However I still consider this to be an important issue to resolve in MW.

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

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.

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

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

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.

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. :)

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

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