User website format
Closed this issue · 8 comments
When a user enters their website in their profile it is not clear whether to include the http:// portion.
This causes an issue when used in hbs files unless used with some processing to add the http(s):// component.
Perhaps a placeholder is needed or a helper to add it?
@sethlilly @ErisDS is this still covered by someone? If not, are there any decisions made for how to change this?
This was initially fixed via stricter validation, but that unfortunately resulted in problems with the importer, login, and general user validation if the website hadn't been set properly previously.
This needs fixing in a different way. Either by changing the validation and then handling the cases where this can cause errors, or with a helper for outputting the value on the blog, or perhaps both.
What is the actual issue here? There is no actual description of what's wrong other than that it's not clear if you should enter http or not. If that's all it is then I would suggest simply sanitising user input. If they entered http or https, leave it, if they didn't: add it. The end result always contains http or https and is predictable.
It's a bit more involved than that because old installs have data that don't have a http:// therefore we need to
- fix it so that this can't happen moving forwards by always pre-pending
http://if it is missing and - consider fixing broken data either by running a migration or also fixing the output at the theme level.
I'm not sure that 2 is entirely necessary, if a theme doesn't work as expected I'm sure a user can figure out to go and change this themselves.
Nonetheless this was fixed with stronger validation, and then reopened during the release process because it caused too many other problems, and because we should be pre-pending the http:// not requiring the user to enter it.
so.... the next step is? That sounds like a bunch of potential suggestions but I'm sure what you're saying the course of action from here is
The next step is to make sure that http:// is injected into any urls which don't have http:// or https:// - I think this ought to be done by both the UI and the server.
If we do this on save server side as well client side, then I think we can leave doing a direct fixup of old data via a migration. Anyone who does have an old broken URL can easily go back and fix it themselves anyway, so I've changed my mind from feeling like it might be necessary to being pretty convinced it isn't.
In short, this should be pretty easy to PR.