SSI functions -- $member_name?

[Alonessix]

Hello all,
I'm creating a personal addon for my forum and site and I'm in need of getting the user data for members who aren't the current user. I've Googled this, and found this topic. It started to guide me in the right direction. However, I'm mostly a newbie to coding with SMF and its SSI functions, and so I'm not sure if the $member_name variable is hard-coded into SMF or if it is a variable defined by the user who posted that code (Vitti). I'd like some clarification on this. I'm fairly sure that it's a user-defined one, but I don't want to mess up website by doing something wrong. Thank you!

Also, I'm very new, so I've got another question: is this the right place for this type of post? or should I have made the topic somewhere else?

[Arantor]

It would kind of help to understand your use case - how are you trying to use this information? Where is it coming from?

[Alonessix]

I'm trying to use the member info for a game creator I'm making, using the SMF authorization system. An example is that the user 'George' goes to play a game by a user whose display name is 'Ulysses', but whose username is 'Hiram'. The PHP on the game page (which would be something like 'www.site.com/gamecreator/hiram/game-name/') should display Ulysses as the creator's name instead of Hiram, and if the user Hiram gets his display name changed again then the information on the page should be updated as well. (I'm using file writing functions in PHP to create the game pages.) This, among other things, is one of the things I'd like to do with it.

Sorry if I'm not making sense, I'm a bit disoriented today and I'm not sure if my post is understandable.

[Arantor]

It's understandable but it's wrong on a number of levels.

Firstly, don't use the username except for display purposes. Use the member id. You can always find the member name from the member id, provided the account hasn't been deleted. (In which case you might store both just in case, like SMF does with posts; the user id and name are both stored and if an account is removed, the name will be left behind)

Secondly, actually writing files for things is rarely a good idea when you need to include dynamic content in it, which you almost certainly will.

Thirdly... what's the intended behaviour if a user changes their display name? Are the paths supposed to change? This is also, incidentally, why using files for dynamic content is not a good idea.


To answer your original question - and now to explain why it's so important to make sense of this - $membername doesn't exist in SMF. The current user's name is loaded but ALL other instances are loaded on demand either synchronously with other data or asynchronously (e.g. in the topic view, the data for all members who've posted in a given page is loaded together, separately from loading the actual messages)


EDIT: Another consideration is that there is actually a security benefit in keeping a different username to displayed name. You can't log in with a displayed name, only the real user name. My username on this forum is not Arantor, so you'll never be able to brute force my account with that.

[Alonessix]

@Arantor: I can understand that. The paths, in the beginning, wouldn't change. I was planning on using files and folders for simplicity - it's much easier to remember a URL like 'domain/gamecreator/user/game-name' than it is to remember one like 'domain/gamecreator/index.php?gameid=1'. Anyway, not meaning to be a help vampire here, but how would I get the creator's data? And is there any alternative to using query strings if I'm not using files? If I need more help with URLs and such than this then I'll break it into a separate topic.

Anyway, thanks for your help.

[Arantor]

There's always rewrites to get from /user/game-name to index.php?user=1&game=2

If you know the user id, loadMemberData() in Load.php (which is always available) will load that for you. There's always doing table joins from your tables to the main SMF tables to get data, just like SMF itself does. Hard to tell much more than that without knowing your database structure, assuming you *are* using a database.

If you only have a user *name*, loadMemberData can still do it but it's at least an order of magnitude slower than using the user id. There's a reason that even XenForo and IPB include numbers in the URLs even the 'friendly' ones