This PR merges the account.html and profile.html pages into a single page. A user now has to visit their profile page to make edits to their profile, instead of their account page.
/account now redirects to /user/<UID> for logged-in users, and to /login for logged out users.
Stylistically, a logged-in user's profile page appears almost identical to viewing the non-logged-in profile, except for text wrapping in the status field. The input box does not wrap (not possible - maybe possible with js), but the view-only text box does wrap. Thus, changing your status to be longer than the allotted width will require horizontal scrolling within the input text box, but to another user/third party it will wrap nicely. Not sure how to fix this, but it might be in a later PR.
As of now, there is no way through a user's profile to change their email or password - this is because we are currently passing only the public user data to profile.html and not the private user data. I'm holding off from making that change until I know it can be done in a safe way. Alternatively, we could resurrect the account.html page for setting these private values only. I can't decide which feels more or less clean to me, so we'll figure that out in a later PR.
This PR merges the
account.html
andprofile.html
pages into a single page. A user now has to visit their profile page to make edits to their profile, instead of their account page./account
now redirects to/user/<UID>
for logged-in users, and to/login
for logged out users.Stylistically, a logged-in user's profile page appears almost identical to viewing the non-logged-in profile, except for text wrapping in the
status
field. The input box does not wrap (not possible - maybe possible with js), but the view-only text box does wrap. Thus, changing your status to be longer than the allotted width will require horizontal scrolling within the input text box, but to another user/third party it will wrap nicely. Not sure how to fix this, but it might be in a later PR.As of now, there is no way through a user's profile to change their email or password - this is because we are currently passing only the public user data to
profile.html
and not the private user data. I'm holding off from making that change until I know it can be done in a safe way. Alternatively, we could resurrect theaccount.html
page for setting these private values only. I can't decide which feels more or less clean to me, so we'll figure that out in a later PR.