avarab wrote:

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.

joanot.martorell wrote:

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
patch for adding (three) new variables: CURRENTUSERNAME, CURRENTUSERMAIL and FULLPAGENAMEE

attachment bugzilla.diff ignored as obsolete

Comment on attachment 1159
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)

robchur wrote:

*** 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.

robchur wrote:

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

gangleri wrote:

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

giesler wrote:

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?

robchur wrote:

*** 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

robchur wrote:

*** 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.

anon.hui wrote:

(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?

herd wrote:

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.

anon.hui wrote:

(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.

This may or may not constitute an argument against this functionality depending on your perspective, but I've always found it incredibly creepy whenever I've come across one of the JS implementations on some wiki. Contrary to the people above talking about how it would be useful for linking to user pages or adding your username to emails and so forth, in practice I've only seen this used specifically to make the reader feel creeped out or unnerved, and I don't see any reason MediaWiki should support features where that's the primary use-case; even if caching weren't an issue, therefore, I'd personally be against adding this functionality.

+1 support for this feature. Would be very, very useful for <s>scripts</s> templates and modules, especially those that make calls to external APIs.

Edit:Clarified reasoning/terms.

@Headbomb Is there a reason existing methods for getting the current user's name via Javascript are insufficient for those uses?

@Dinoguy1000 To my knowledge, JavaScripts need to be installed, which means templates can't make use of them.

See https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#CURRENTUSER_magicword/variable%3F

Aah, so by "scripts" you meant Lua modules and wikitext templates.

Yes, clarified the original post, although I'm sure there would be uses for JavaScripts as well.

As was pointed out in https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&diff=856639028&oldid=856636613, this functionality would be a significant privacy violation: simply embed {{USERNAME}}/{{CURRENTUSER}}/whatever-the-variable-would-be in a URL to an external service, and that service gets the username and IP address of any reader who clicks the link, along with whatever other information can be gleaned from the referrer data. Even if the caching issues were nonexistent, I would argue that this problem makes the requested functionality a complete nonstarter.

That's rather trivial to prevent with edit filters.

@Headbomb, I think you're asking the wrong question. You want to be able to pass the current user's username to an external tool. Instead, the external tool should use OAuth to authenticate the user and fetch their username.

Can't do that dynamically AFAICT, that requires loading a second tool and we lose the one-click functionality.

Guess we'll just have to live without.

In T6196#4533147, @Headbomb wrote:

That's rather trivial to prevent with edit filters.

Edit filters are fragile for this purpose, and depend on having the extension installed (not a concern for WMF wikis, but very much so for third-party wikis) and having an editor with the technical ability to write and maintain the necessary filters (potentially a concern for any wiki without a large and well-established editing community, including a very large number of WMF wikis). In addition, this still requires you to trust whoever runs the whitelisted services to not do anything nefarious with the information they could be collecting, which is basically impossible to police. This seems to me like a can of worms better left unopened.