The discussion revolves around a feature request to show the full website path on user profiles, regardless of the domain. mcwumbly initiated the discussion, pointing out that when a user enters a full website path, it gets truncated to the domain level. A proposed pull request (mcwumbly) aims to address this issue.
Mittineague expressed concerns about potential abuse, such as users including referral links. They suggested a whitelist approach to mitigate this risk. However, mcwumbly argued that showing the full link would increase transparency and make it easier to police.
sam proposed a simpler solution: truncating the link after the ? character, which would prevent referral links from being displayed. mcwumbly agreed to update the pull request accordingly. It was later discovered that truncation of query parameters was already happening, and the tests were updated to reflect this (mcwumbly).
I haven’t bothered maintaining a personal website for a while. The closest thing to my ‘website’ is twitter:
But if I put twitter.com/mcwumbly in my profile, it just shows up as twitter.com:
Why not show the full path?
(If I did have a personal website, I probably wouldn’t have a deep path anyway)
I think if that change is made “Web Site” should be changed to read “URL”
And I’m not sure it’s a good idea to allow full paths.
For example allowing
..... /page?referral_id=1234
would be extremely inviting for those that think spreading their links in as many places as possible is good SEO practice.
Personally, I’d prefer that setting not be available for TL0 members, but that’s another topic
TL0 users’ links don’t actually get hyperlinked.
I’m not sure how query parameters would be displayed with this PR as-is. (There isn’t a test covering that).
We could make sure it trims those from being displayed. How would that make you feel?
That hasn’t stopped one-visit members from dropping links there.
One problem might be that some GETs are perfectly innocent eg. ....page?post=25
As soon as Web Site becomes URL a can of worms is opened requiring complex code to keep it from being abused.
I’d be more in favor of a whitelist approach vs. blacklisting. eg. allow URLs like
site.com/membername
as that is a common format. eg.
twitter.com/mcwumbly
github.com/cpradio
I can see no problem with that
gitlab.com/u/steko 
It already links to the site for basic members. Doesn’t showing the link make it more transparent? Wouldn’t that make it easier to police than it is now?
Whitelist/blacklist logic seems like it’s overkill to me until we find there is actually a problem here…
Plus, I can already put whatever I want in my “about” section…
Offtopic: Your twitter link in your about section doesn’t work.
Oops… Broke it when experimenting… Should be working again. Thanks for letting me know 
I think should a full path is fine adding referral stuff is rather rare … also we can simply truncate the UI after the ?
So: https://mysite.com/awesome?t=banana shows up as mysite.com/awesome
No need for fancy whitelisting or blacklisting here.
Happy to update the PR to truncate at ? everything after that.
Sure, go for it 
PR updated… turns out truncation of query params was already happening, so I just updated the tests to make that more explicit.
