r102624 MediaWiki - Code Review archive

Could this be made generic and work for all namespaces? There is this ambitious plan to use displaytitle prop everywhere.

In what way? This is related to usernames rather than titles, there's nothing really related to titles here.

Rather than the displaytitle prop when I tried to fix it so that IPod would display iPod throughout the entire user interface it included a schema change. The title was stored inside the database. The displaytitle really wouldn't work as a good idea outside of where it is right now.

) Actually this change might help with one of the issues I encountered in my title rewrite. getName() was being used for both comparison and display so I had issues with it. Now if we start using getDisplayName() that could be what's changed.

Sorry I can't parse your sentence. Are you saying that using display title in page_props for title display is not good idea?

Yes, outside of stuff on the page itself. Most queries don't join on page_props, and it's possible in some cases for a page prop to not be present. So using displaytitle on say Special:Allpages requires either an extra join with some potentially complicated circumstances or it'll be inefficient as page_props would have to be repeatedly queried.

I was not asking that. I was asking if there was some fundamental reason that it can't be done.

For the technical implementation we already have LinkBatch and Title::newFromRow that can be extended.

As a replacement in-core for Extension:Realnames, I think your choice of wg var is too simple. Before making my extension I looked at all the other extensions which did realname replacement (there are a few) and they all had different ways of display it. For example: Username - Realname or Realname [username] etc. Or wholesale replacement. I think you could reasily re-use the conf vars from Extension:Realnames to make a transition seamless. Of course they aren't all needed or wanted, but some of them could prove useful.

Oh... things like Dantman [Daniel Friesen] aren't going to be something simple like this rev. That's changing markup in a lot of places this is just a change to text, that's going to require a separate feature. And that's not something that'll work in a unified way. There will be places where a combined html display like that may not be simply possible.

I disagree. The more I think about it, the more getDisplayName() should actually use a mediawiki message with $ vars and replace on given elements. Username and Realname just being two. The user can then format how it outputs to their liking.

Or gut out all the "realname" stuff out of this feature complete and just add a hook for extensions to change the getDisplayName and do it themselves.

No point adding a half-baked feature.

Also, nobody is talking about making the 'Dantman' clickable and the '[Daniel Friesen]' not. Just wholesale replacement of the link text to some administrator-defined string. ala $wgRealnameStyle(s)

It already has a hook. $wgRealNameInInterface is just an extra config for the most common expected setup, a simple username to realname replacement.

My vote is to remove the $wgRealNameInInterface bit.

Your set of assumption are incorrect, the most common expected setup is 'Username — Realname' and this is what all current realname extensions currently do (except mine, which allows many different setups). This is inline with almost all public wikis where the username is meaningful, and the realname is added bonus.

The other use case (and the one the bug happens to be filed for) is likely a private wiki that is using other extensions to do external authentication (like LDAP). In this case the username is often a almost-meaningless auto-generated id, where wholesale replacement makes sense.

If you insist on providing in-core functionality, please provide as suggested a user-defined way to specify either an append or a replace (or a user defined replacement string).

Another thought is that really we should just add the ability to hook the display of a username, and then use an extension to do whatever an administrator wants. For example adding twitter or facebook icon shortcuts after names... whatever. Talk page everywhere... Although I admit a simple username -> realname or username + realname is the most likely scenario.

$this->userdisplayname ($this->username before this rev) will be null for IPs. What's the point of that entry in $personal_urls['anonuserpage'] ?

$tpl->data['userdisplayname'] may be null for IPs. $this->userdisplayname comes directly from $user->getDisplayName() it will be the ip address for anons. Of course anons don't have real names so usually there won't be any difference from $this->username, but I included it in the change in case someone decides they have a good idea for an extension that changes the display name of an anon user.