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.
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
Extension is not yet in use on WMF cluster, thus requires security and architecture review.
Comment Actions
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.
Comment Actions
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
Comment Actions
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}}.
Comment Actions
Yes please. Transcluding special pages auto disables parser cache which is sucky.
Id also like to see some discusion on commons. Seems very editcountist.
Comment Actions
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.
Comment Actions
@McZusatz: Is this still wanted? If yes, then the issues in T113169#4822926 should likely be filed as separate tickets against MediaWiki-extensions-Editcount as a first step (and T173775 get fixed).
Comment Actions
Unfortunately closing this Phabricator task as no further information has been provided.
@McZusatz: After you answered the previous comment and if this is still wanted and after specific tasks first required to be resolved have been created, please set the status of this task back to "Open" via the Add Action... → Change Status dropdown. Thanks!