Page MenuHomePhabricator

Enable Extension:Editcount to be used on commons.wikimedia
Open, Stalled, LowestPublic

Description

It would be useful to be able to put {{Special:Editcount/fooUser}} on a page.

Right now https://commons.wikimedia.org/wiki/Special:Editcount/fooUser gives "No such special page" so I am assuming the extension is not enabled.

https://www.mediawiki.org/wiki/Extension:Editcount

Event Timeline

McZusatz raised the priority of this task from to Needs Triage.
McZusatz updated the task description. (Show Details)
McZusatz added a subscriber: McZusatz.
Restricted Application added subscribers: Steinsplitter, Aklapper. · View Herald TranscriptSep 20 2015, 10:22 AM
Restricted Application added a subscriber: Matanya. · View Herald TranscriptSep 20 2015, 10:35 AM
Steinsplitter moved this task from Incoming to Backlog on the Commons board.Sep 20 2015, 10:36 AM
TTO updated the task description. (Show Details)Sep 20 2015, 10:41 AM
TTO added a project: Wikimedia-Extension-setup.
TTO added a subscriber: TTO.

Extension is not yet in use on WMF cluster, thus requires security and architecture review.

Ricordisamoa added a subscriber: Ricordisamoa.
Reedy added a subscriber: Reedy.Sep 20 2015, 12:02 PM

Why would it be useful? Is there consensus to do so?

Why would it be useful?

It can be used to make templates more intelligent.

Is there consensus to do so?

No, but there seems to exist some interest in it because right now this magic word is faked by a bot every 24 hours: E.g. https://commons.wikimedia.org/w/index.php?title=User:-revi/edit_count&action=history
It's good to have the bot but in the long run this does not scale as good as I expect the extension to scale.

Although I don't see any obvious calls at the moment, an extension like that that is putting non static data through, really would need to be disabling the parsercache. So it's questionable if it'll actually even work properly on WMF sites in its current form. And even then, is a big perf no no, even more so as usage of it increases

That aside, the code needs dragging upto date in more ways than one

TTO added a comment.EditedSep 21 2015, 1:15 AM

The performance impact doesn't look serious, it's only looking up the user_editcount field in the DB. I would think the parser caching is a non-issue - people could simply purge the page if they wanted to refresh the data. On the whole, it doesn't pose any new issues not already present in other transcludable special pages.

The per-namespace functionality would almost certainly need to be disabled on the WMF cluster though.

As an additional comment I'd rather see this implemented as a magic word instead of a transcluded special page. Something like {{editcount:UserName}}.

Glaisher triaged this task as Lowest priority.Sep 21 2015, 3:42 PM
Glaisher removed a project: Wikimedia-Site-requests.

The performance impact doesn't look serious, it's only looking up the user_editcount field in the DB. I would think the parser caching is a non-issue - people could simply purge the page if they wanted to refresh the data. On the whole, it doesn't pose any new issues not already present in other transcludable special pages.
The per-namespace functionality would almost certainly need to be disabled on the WMF cluster though.
As an additional comment I'd rather see this implemented as a magic word instead of a transcluded special page. Something like {{editcount:UserName}}.

Yes please. Transcluding special pages auto disables parser cache which is sucky.

Id also like to see some discusion on commons. Seems very editcountist.

Restricted Application added a subscriber: jeblad. · View Herald TranscriptAug 25 2017, 8:44 PM
MaxSem changed the task status from Open to Stalled.Dec 14 2018, 7:35 AM
MaxSem added a subscriber: MaxSem.

I'm afraid that in its present state, this extension is not ready for Wikimedia deployment:

  • Edits in namespace counting functions (editsByNs() and editsInNs()) are using queries that are too slow - counting edits for users who have made a lot of them would be unacceptably slow.
    • And why does it join with user anyway?
  • As mentioned above, instead of making the special page includable, it should implement a parser function.
    • And what about cacheability? Either users will complain that pages are displaying outdated information, or insufficient caching or lack thereof will make things slower for everyone. Adding features that reduce parser cache hit ratio should not be taken lightly, and serious evidence that such features are direly needed by a significant number of users should be required to make this happen, IMO.
  • Inline styles (<table border='1' style='background-color: #fff; border: 1px #aaa solid; border-collapse: collapse;'>) should be replaced with CSS.