Last modified: 2012-11-06 07:30:45 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T6196, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 4196 - New user-specific variable (magic word, parser function) giving {{USERNAME}} ({{CURRENTUSER}} {{USER}})
New user-specific variable (magic word, parser function) giving {{USERNAME}} ...
Status: RESOLVED LATER
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.16.x
All All
: Lowest enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://www.mediawiki.org/wiki/Extensi...
:
: 4725 5737 5738 7397 10202 22957 29513 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-06 18:03 UTC by Joanot Martorell
Modified: 2012-11-06 07:30 UTC (History)
18 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
patch for adding (three) new variables: CURRENTUSERNAME, CURRENTUSERMAIL and FULLPAGENAMEE (2.41 KB, patch)
2005-12-09 01:51 UTC, T. Gries
Details

Description Joanot Martorell 2005-12-06 18:03:25 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.
Comment 1 Ævar Arnfjörð Bjarmason 2005-12-06 18:04:46 UTC
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.
Comment 2 Joanot Martorell 2005-12-06 18:12:49 UTC
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.
Comment 3 T. Gries 2005-12-06 20:21:59 UTC
(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).
Comment 4 T. Gries 2005-12-06 23:19:20 UTC
(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.

Comment 5 Brion Vibber 2005-12-06 23:51:16 UTC
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.
Comment 6 T. Gries 2005-12-09 01:51:40 UTC
Created attachment 1159 [details]
patch for adding (three) new variables: CURRENTUSERNAME, CURRENTUSERMAIL and FULLPAGENAMEE
Comment 7 T. Gries 2005-12-09 02:02:44 UTC
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)
Comment 8 Rob Church 2006-01-22 22:16:33 UTC
*** Bug 4725 has been marked as a duplicate of this bug. ***
Comment 9 Peter Halasz 2006-03-09 03:10:16 UTC
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.
Comment 10 Rob Church 2006-04-27 23:21:04 UTC
*** Bug 5738 has been marked as a duplicate of this bug. ***
Comment 11 lɛʁi לערי ריינהארט 2006-04-27 23:49:48 UTC
*** Bug 5737 has been marked as a duplicate of this bug. ***
Comment 12 giesler 2006-04-30 15:39:41 UTC
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?
Comment 13 Rob Church 2006-10-02 01:09:53 UTC
*** Bug 7397 has been marked as a duplicate of this bug. ***
Comment 14 Peter Halasz 2007-02-11 00:56:46 UTC
Just a note that Uncyclopedia has created a workaround for this using Javascript
to substitute the username:

http://uncyclopedia.org/wiki/Template:USERNAME
Comment 15 Rob Church 2007-06-08 19:28:08 UTC
*** Bug 10202 has been marked as a duplicate of this bug. ***
Comment 16 とある白い猫 2008-04-24 10:35:26 UTC
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.
Comment 17 Brion Vibber 2008-04-24 21:16:12 UTC
See bug 10336 for that.
Comment 18 Anon Sricharoenchai 2009-03-02 06:01:26 UTC
(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?
Comment 19 Splarka 2009-07-11 03:00:41 UTC
big dupe target, adding spammy aliases to summary
Comment 20 T. Gries 2010-02-13 19:31:06 UTC
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).
Comment 21 Niklas Laxström 2010-02-13 19:36:13 UTC
(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.
Comment 22 T. Gries 2010-02-13 20:50:51 UTC
I hereby apply to become a maintainer.
Comment 23 T. Gries 2010-02-15 07:29:18 UTC
Proposal to add this extension to the MediaWiki SVN
Comment 24 Max Semenik 2010-02-15 07:35:07 UTC
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.
Comment 25 Alexandre Emsenhuber [IAlex] 2010-03-26 07:32:03 UTC
*** Bug 22957 has been marked as a duplicate of this bug. ***
Comment 26 This, that and the other (TTO) 2010-03-26 09:28:43 UTC
(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.
Comment 27 Roan Kattouw 2010-03-26 19:13:35 UTC
(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.
Comment 28 Anon Sricharoenchai 2010-03-27 16:22:45 UTC
(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.
Comment 29 Chad H. 2010-03-27 16:25:50 UTC
(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.
Comment 30 Sam Reed (reedy) 2011-06-21 15:36:01 UTC
*** Bug 29513 has been marked as a duplicate of this bug. ***
Comment 31 Gustronico 2011-08-26 15:28:22 UTC
*** Bug 27364 has been marked as a duplicate of this bug. ***
Comment 32 Daniel Friesen 2012-11-06 07:30:45 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links