Last modified: 2012-11-06 07:30:45 UTC
Hi. It would be fine to have a variable such {{USERNAME}} wich gives the logged-in user name, in the same way as {{PAGENAME}} gives the current page name. By example, if a username called "John Doe" visits a page with the following wikicode: Hi {{USERNAME}}, welcome to Wikipedia. It would give: Hi John Doe, welcome to Wikipedia. Hi {{USERNAMEE}}, welcome to Wikipedia. It would give: Hi John_Doe, welcome to Wikipedia. Also it would be useful to some high customization of some page. By exemple, if this same user, User:John_Doe, had a page called User:John_Doe/Main_page_customize, trough an array template (i.e. "switch") it could be possible to make a customized entirelly or partially the Main_page. In the same way as {{PAGENAMEE}} (plain links), it would be also needed the variable {{USERNAMEE}}. If there's no logged in user, this variable would give empty.
WONTFIX, there's a good reason why we don't have this, it would totally kill content caching. If you need it implement it as a variable extension on your installation.
I don't agree with this reason. If it's about content caching, all others variables such {{CURRENTDAY}} would be able also to kill the cache through array templates.
(In reply to comment #0) > It would be fine to have a variable such {{USERNAME}} wich gives the logged-in > user name, in the same way as {{PAGENAME}} gives the current page name. By > example, if a username called "John Doe" visits a page with the following wikicode: By chance, I have developed independently from this bugzilla a patch to deliver {{USERNAME}} and {{USERMAILADDRESS}}. I will post this soon, patch is short and easy. The purpose of these variables is mainly and of course only for the logged-in user himself. I use it for "template" pages for business cards, routing slips and so on, which then bear the user's names and email address. The usage is admittedly very limited and mainly for private or intranet applications of MediaWiki and I can understand the developers not integrating this. Nevertheless I'll post the short patch soon here, but a WONTFIX appears to be appropriate (in the light of MediaWiki being the engine of Wikipedia).
(In reply to Brion's comment #1) > WONTFIX, there's a good reason why we don't have this... A weak argument for implementation: I think, {{USERNAME}} could be used instead of $PAGEEDITOR in the template for notification mails [[MediaWiki:enotif body]]; the corresponding code which sets $PAGEEDITOR in UserMailer.php could be dropped.
That was avar, not me. :) I was fairly sure this was already WONTFIXed months ago, but can't turn up an earlier one in bugzilla at the moment. If you find it, reopen and dupe this bug to it.
Created attachment 1159 [details] patch for adding (three) new variables: CURRENTUSERNAME, CURRENTUSERMAIL and FULLPAGENAMEE
Comment on attachment 1159 [details] patch for adding (three) new variables: CURRENTUSERNAME, CURRENTUSERMAIL and FULLPAGENAMEE (a better patch follows soon; the solution bugzilla 3997 FULLNAMEE is already committed and should not be subject of this patch for 4196, sorry)
*** Bug 4725 has been marked as a duplicate of this bug. ***
I don't know how much this is a wikipedia or wikimedia thing, but... I'd like to use {{USERNAME}} as a subst, so it would have no cache performance penalties. But first i'd need a recursive subst (which subst'd a template's templates). Using ~~~ would be good enough, except it includes [[these brackets]]. Can we have a linkless ~~~ ? perhaps called :~~~ humbug.
*** Bug 5738 has been marked as a duplicate of this bug. ***
*** Bug 5737 has been marked as a duplicate of this bug. ***
Using several PCs through a router patch works fine with 1.5.4 but I got problems with 1.6.3: In this case it seems that CURRENTUSERNAME is based upon IP address but it only would make sense if CURRENTUSERNAME is based upon session-id or cookies. Any idea?
*** Bug 7397 has been marked as a duplicate of this bug. ***
Just a note that Uncyclopedia has created a workaround for this using Javascript to substitute the username: http://uncyclopedia.org/wiki/Template:USERNAME
*** Bug 10202 has been marked as a duplicate of this bug. ***
I think there are very good reasons to have this. It can be used on license templates for example. Images uploaded with {{GFDL-self}} run into the problem of an ambiguous "I" when the file is uploaded. If the file is renamed or uploaded to commons this poses a particular problem. It can of course be manually corrected but had the original upload be done with {{self|author=[[User:{{subst:USERNAME}}]]|GFDL}} it would same a lot of time and effort. It would ease our ability to move, alter, and reuse of files.
See bug 10336 for that.
(In reply to comment #1) > WONTFIX, there's a good reason why we don't have this, it would totally kill > content caching. If you need it implement it as a variable extension on your > installation. The already implemented {{int:...}} also kill content caching?
big dupe target, adding spammy aliases to summary
Note: the extension http://www.mediawiki.org/wiki/Extension:UserFunctions reliably adds parser functions for (current) username, useremail, nickname and others. I suggest to add this light-weight extension to http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ perhaps after a rewrite to make the extension running under old and new MediaWiki versions (pre- and after 1.8 version, see url).
(In reply to comment #20) > I suggest to add this light-weight extension to In that case it should probably have a maintainer with SVN-access. > rewrite to make the extension running under old and new MediaWiki versions Imho it's not worth supporting 1.8, or rather anything < 1.14.
I hereby apply to become a maintainer.
Proposal to add this extension to the MediaWiki SVN
Apply to <http://www.mediawiki.org/wiki/Commit_access_requests>, then you could add it yourself. Be aware though that it will never be enabled on Wikimedia.
*** Bug 22957 has been marked as a duplicate of this bug. ***
(In reply to comment #24) > Be aware though that it will never be enabled on Wikimedia. For what reason? Caching was mentioned as a reason, but it is an issue with most other variables anyway, so no reason why this could not be done on WM wikis.
(In reply to comment #26) > (In reply to comment #24) > > Be aware though that it will never be enabled on Wikimedia. > > For what reason? Caching was mentioned as a reason, but it is an issue with > most other variables anyway, so no reason why this could not be done on WM > wikis. For stuff like {{CURRENTDAY}}, this is handled by reducing the cache lifetime to an hour. This means that when you view a page using {{CURRENTDAY}} between 00:00 and 01:00 UTC, it'll probably show the wrong value, but we seem to have decided that's acceptable for performance's sake. However, hourly updates are totally unacceptable for {{CURRENTUSER}}, it needs to literally change at every page view.
(In reply to comment #27) > For stuff like {{CURRENTDAY}}, this is handled by reducing the cache lifetime > to an hour. This means that when you view a page using {{CURRENTDAY}} between > 00:00 and 01:00 UTC, it'll probably show the wrong value, but we seem to have > decided that's acceptable for performance's sake. > > However, hourly updates are totally unacceptable for {{CURRENTUSER}}, it needs > to literally change at every page view. How about {{int:...}} ? It also needs to literally change for users with different interface language.
(In reply to comment #28) > (In reply to comment #27) > > For stuff like {{CURRENTDAY}}, this is handled by reducing the cache lifetime > > to an hour. This means that when you view a page using {{CURRENTDAY}} between > > 00:00 and 01:00 UTC, it'll probably show the wrong value, but we seem to have > > decided that's acceptable for performance's sake. > > > > However, hourly updates are totally unacceptable for {{CURRENTUSER}}, it needs > > to literally change at every page view. > > How about {{int:...}} ? > It also needs to literally change for users with different interface language. {{int:}} is bad and probably wouldn't be added if it were requested today for the same reasons outlined here and elsewhere. The issues with it need fixing (cf bug 14404). Maybe one day we'll get a fix for that and the caching issues. Until then, this should remain resolved LATER.
*** Bug 29513 has been marked as a duplicate of this bug. ***
*** Bug 27364 has been marked as a duplicate of this bug. ***
Note that {{int:}} only has to fragment by user lang. Which is something many users share. We have a finite number of possible values. While for {{USERNAME}} it's still 100% fragmented.
