Member profile vanity URLs / access member profiles via user name only

g0rn

Well-known member
In vBulletin, you can access user profile by either visiting /member.php?u=123456 or /member.php?username=john
As far as I can see, in Xenforo you have to know user id, not only username (you can use either /members/john.123456/ or /members/123456/ but not /members/john/).
So, I would like to have a possibility to access profile by simply substituting username to the url.
 
Upvote 19
Since in both your cases, MySQL knows it only needs to examine 1 row, the difference between them is for all intents and purposes non existant. :)
 
Since in both your cases, MySQL knows it only needs to examine 1 row, the difference between them is for all intents and purposes non existant. :)

Well yes, it would be a bit more extreme in a forum usertable scenario. Also, if someone has a non-standard character in their username, and they've made it a long-ish username. I'm not going to want to spend time trying to get their profile.
 
Since usernames are unique the url rewrite rule doesn't have to include the user id. We have a setup with vbseo without user id i.e. http://forum.domain.com/members/bob-k/ .
That is generally true, but there is still an ambiguity in the URL without the ID. Is that user "Bob K" or "Bob-K"? There are characters that can be used in names that aren't allowed in URL forms like that (/ being the obvious one).
 
That is generally true, but there is still an ambiguity in the URL without the ID. Is that user "Bob K" or "Bob-K"? There are characters that can be used in names that aren't allowed in URL forms like that (/ being the obvious one).
Yes indeed, we needed to enable a limitation on usernames at registration and make them match a regular expression. So spaces are allowed, hyphens are not.

So if XF allows the option to not use the id in profiles, then it would require an extra setting in the UCP to prevent the use of these special characters that can cause problems. I think it's a small offer to make for a better URL though.
 
[...] it would require an extra setting in the UCP to prevent the use of these special characters that can cause problems. I think it's a small offer to make for a better URL though.
An option to limit usernames by a regular expression is already present, btw. :)
 
True, however, XenForo uses user IDs to get the user data.
I can search for posts by a username, I don't have to enter a userid. The point of a relational database is that you only use userid when referring to a user, just like you only store the threadid when referring to a thread, but it's trivially easy to do a lookup to match up an ID with the actual information.

dutchbb said:
Yes indeed, we needed to enable a limitation on usernames at registration and make them match a regular expression. So spaces are allowed, hyphens are not.
This doesn't have to be a perfect scenario. I can use a URL to lookup a user, but if the username contains characters that are impossible in a URL, then this method cannot be used to look up that user. And with the availability of special characters (%20 anyone?), it's possible to specify almost any character in a URL. The fact that username=______ won't work for every forum, or every user is not an ironclad justification not to offer that feature.
 
I can search for posts by a username, I don't have to enter a userid. The point of a relational database is that you only use userid when referring to a user, just like you only store the threadid when referring to a thread, but it's trivially easy to do a lookup to match up an ID with the actual information.
Yes - but how many people constantly visit the user's profile page by URL?
 
Yes - but how many people constantly visit the user's profile page by URL?
Since the feature is not available, I'm guessing very few. ;)

Just for sake of argument, the User table is not even in the top 5 or top 10 tables in size in vBulletin, and I'm guessing this is also applicable to XenForo, depending on whether the database has been normalized.
 
Since the feature is not available, I'm guessing very few. ;)

Just for sake of argument, the User table is not even in the top 5 or top 10 tables in size in vBulletin, and I'm guessing this is also applicable to XenForo, depending on whether the database has been normalized.

Very true. Would people still try to find the user by URL? The majority of users may user the memberlist, or whatever, but the last thing they'll do is enter the username in a URL to get to the user (if the function was available).
 
This doesn't have to be a perfect scenario. I can use a URL to lookup a user, but if the username contains characters that are impossible in a URL, then this method cannot be used to look up that user. And with the availability of special characters (%20 anyone?), it's possible to specify almost any character in a URL. The fact that username=______ won't work for every forum, or every user is not an ironclad justification not to offer that feature.
I'm not sure I understand your reply correctly, but I want to state that I don't think special characters should be allowed in usernames. A-Z 0-9 and spaces (which are replaced by a hyphen) should be enough and keeps things clean.

With a vbseo enabled vB forum, when you type for example:

http://forum.domain.com/members/groundhog%20day
or
http://forum.domain.com/members/groundhog day

it automatically redirects to:

http://forum.domain.com/members/groundhog-day/

It'd be nice to see a similar behavior in XF.
 
I'd like to see this as well. I haven't look over the code yet to see if I want to get into it or not, but a way of remapping it so that either are still valid would be wonderful.
 
In the event of a username change, you won't be able to access that user's profile via their username any more (obviously).
 
So I made some tests and actually this can be easy implemented.

In the XenForo_Route_Prefix_Members change the:

PHP:
$action = $router->resolveActionWithIntegerParam($routePath, $request, 'user_id');

to

PHP:
$action = $router->resolveActionWithIntegerOrStringParam($routePath, $request, 'user_id', 'username');


Works here!
 
Top Bottom