Newness isn't currently tracked in the revision table.

snoutwood wrote:

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

marco wrote:

That would be a nice job to do, but most nicest would be when it is possible to
make a whole page out of the data.

robchur wrote:

That would be one bloody nasty query. I pity the bugger who writes that.

avarab wrote:

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

rick.denatale wrote:

Bug 4597 is NOT a duplicate, it is asking for a way to filter
Special:Contributions to only show contributions which are the latest editions
of an article.

THIS bug is asking for something different, it asks for NEW articles (i.e.
created by the contributor) to be distinguished.

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

ayg wrote:

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

dto wrote:

patch for r16149 SpecialContributions.php to show page creations

Attached patch gets information about page creations from recent changes, so
only recently created pages will get an "N" next to them. I'm hoping this will
be enough for dealing with vandalism.

Finding all page creations, even if they have been deleted from recent changes,
would either require tracking "newness", which, as Brion points out, isn't done
yet, or it would require a relatively expensive (I think?) GROUP BY query.

Attached:

robchur wrote:

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

ayg wrote:

The patch is outdated and can't be applied as-is, since SpecialContributions has been rewritten since it was created. Also, the modification to the query is unacceptable: it joins each revision to *every* row corresponding to it in recentchanges, causing many extra rows to be returned. That makes even the recentchanges solution somewhat nontrivial, or at least no way of avoiding that efficiently comes immediately to mind. There probably is some way, but I can't think of it . . .

(In reply to comment #11)

The patch is outdated and can't be applied as-is, since SpecialContributions
has been rewritten since it was created. Also, the modification to the query
is unacceptable: it joins each revision to *every* row corresponding to it in
recentchanges, causing many extra rows to be returned. That makes even the
recentchanges solution somewhat nontrivial, or at least no way of avoiding that
efficiently comes immediately to mind. There probably is some way, but I can't
think of it . . .

Hmm, isn't there a user_text, timestamp index for recentchanges? Perhaps that can be to limit the row scanning needed for the join. Then the rc_this_oldid and rc_type condition can be checked on like 1-2 rows.

Actually, why not start with RC and join on revision?

Joining to recentchanges is going to limit you to activity within the $wgRCmaxage limit. If you want this to be more generally useful, it's probably necessary to extend the fields in the revision table.

In theory you could just check for empty rev_parent_id, but this field is still unused afaik. :(

(In reply to comment #14)

Joining to recentchanges is going to limit you to activity within the
$wgRCmaxage limit. If you want this to be more generally useful, it's probably
necessary to extend the fields in the revision table.

In theory you could just check for empty rev_parent_id, but this field is still
unused afaik. :(

A few changes to the Revision code, and it can be populated. I may whip up a maintenance script if someone cares (which would assume first=new). I thought about doing this before but always thought roman would come back and finish...didn't happen ;)