Last modified: 2014-11-17 09:21:25 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 12363 - Page moves into mainspace should appear on Special:Newpages for patrol
Page moves into mainspace should appear on Special:Newpages for patrol
Status: PATCH_TO_REVIEW
Product: MediaWiki
Classification: Unclassified
Recent changes (Other open bugs)
1.22.0
All All
: High normal with 10 votes (vote)
: ---
Assigned To: Rohan Rawat
:
: 28431 69324 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-20 05:05 UTC by blah
Modified: 2014-11-17 09:21 UTC (History)
24 users (show)

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


Attachments

Description blah 2007-12-20 05:05:58 UTC
New articles are sorted by namespace on Special:Newpages, by default displaying only mainspace creations.  From personal experience and by observing the the marking of articles as "patrolled" it would appear that articles created in userspace are generally not observed by Newpage Patrollers.  And while moving an article into mainspace will still show up in recent changes, I presume they remain quite unlikely to be patrolled soon after creation.  Thus, creating articles in userspace before moving them into mainspace seems to me a sneaky way of avoiding scrutiny from newpage patrollers.  An simple solution (in concept, perhaps not in actual implementation, I have no idea on that part) would be to display any pagemove into mainspace alongside mainspace creations in Special:Newpages. Thank you.
Comment 1 Siebrand Mazeland 2009-02-02 13:32:37 UTC
Changed component to "RecentChanges"
Comment 2 Chad H. 2011-04-05 23:56:14 UTC
*** Bug 28431 has been marked as a duplicate of this bug. ***
Comment 3 Derrick Coetzee 2012-01-13 07:10:44 UTC
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.
Comment 4 p858snake 2012-01-13 10:55:41 UTC
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.
Comment 5 Paolo Benvenuto 2012-01-13 11:58:18 UTC
+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
Comment 6 Snottywong 2012-01-13 14:46:49 UTC
(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.
Comment 7 Derrick Coetzee 2012-01-14 10:16:07 UTC
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.
Comment 8 Paolo Benvenuto 2012-01-14 13:07:42 UTC
ok, but it "solves" the problem for wikipedia, not for all other mediawiki installation...
Comment 9 Derrick Coetzee 2012-01-14 14:11:22 UTC
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.
Comment 10 Kevin Gorman 2013-10-01 21:57:28 UTC
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.)
Comment 11 Dan Garry 2013-10-02 15:31:57 UTC
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.
Comment 12 Bawolff (Brian Wolff) 2013-10-02 23:14:16 UTC
(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?
Comment 13 Nemo 2013-10-03 05:03:38 UTC
(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/).
Comment 14 Kevin Gorman 2013-10-05 22:44:17 UTC
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.
Comment 15 Derrick Coetzee 2013-10-06 17:53:58 UTC
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.
Comment 16 Bawolff (Brian Wolff) 2013-10-09 17:42:49 UTC
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).
Comment 17 Derrick Coetzee 2013-10-09 18:24:58 UTC
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.
Comment 18 Oliver Keyes 2013-10-11 00:26:28 UTC
Why would NPF be a lower priority? Note that NPF intentionally lists moves.
Comment 19 Oliver Keyes 2013-10-11 00:26:59 UTC
Ah, just saw Nemo's comment; ignore me.
Comment 20 Steven Walling 2013-10-11 01:05:53 UTC
(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?
Comment 21 Bawolff (Brian Wolff) 2013-10-16 15:22:57 UTC
(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].
Comment 22 Steven Walling 2013-10-16 21:58:00 UTC
(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.
Comment 23 Steven Walling 2013-12-12 00:47:14 UTC
Poke. Any movement on this?
Comment 24 cs 2013-12-21 02:34:42 UTC
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.
Comment 25 Kunal Mehta (Legoktm) 2013-12-21 06:00:19 UTC
(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.
Comment 26 p858snake 2013-12-21 06:30:41 UTC
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.
Comment 27 Paolo Benvenuto 2013-12-21 06:48:45 UTC
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?
Comment 28 p858snake 2013-12-21 06:55:34 UTC
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.
Comment 29 Nemo 2013-12-21 08:43:55 UTC
(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. :)
Comment 30 Paolo Benvenuto 2013-12-21 12:06:27 UTC
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.
Comment 31 Matthew Flaschen 2013-12-24 06:35:59 UTC
(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.
Comment 32 Nemo 2014-01-23 07:25:54 UTC
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. :)
Comment 33 Nemo 2014-01-23 07:27:33 UTC
(To be clear, simple but not trivial to approve, and workaround but only for some part.)
Comment 34 Paolo Benvenuto 2014-01-23 08:07:47 UTC
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.
Comment 35 Matthew Flaschen 2014-01-28 06:42:51 UTC
(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.
Comment 36 Krinkle 2014-06-05 09:45:36 UTC
Classifying as bug. This allows pages to bypass review.
Comment 37 Gerrit Notification Bot 2014-07-22 06:33:43 UTC
Change 148322 had a related patch set uploaded by Rohan013:
Show Page moves on Special:Newpages

https://gerrit.wikimedia.org/r/148322
Comment 38 Bawolff (Brian Wolff) 2014-07-24 04:30:19 UTC
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.
Comment 39 Bawolff (Brian Wolff) 2014-07-24 18:55:02 UTC
(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.
Comment 40 Bawolff (Brian Wolff) 2014-07-27 18:36:28 UTC
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.
Comment 41 Bawolff (Brian Wolff) 2014-08-09 16:41:46 UTC
*** Bug 69324 has been marked as a duplicate of this bug. ***

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


Navigation
Links