Stop creating public_html symlinks from April 2023

[edwinbalani]

I think public_html symlinks in (private) homedirs are causing more confusion than they're worth: users delete them expecting to delete their website content, then are confused when their website (a) doesn't go away and (b) no longer responds to changes made when they reinstate public_html (as a directory).

We first created this symlink as a convenience when we created the /public hierarchy due to GDPR, which was in May 2018. It's been 5 years: we may as well go all-in on /public for it to be clear that public_html lives in a user's "public space" rather than their private "home directory".

These changes are coded with date-specific logic so that docs can be updated in the next few days with wording along the lines of "accounts created before April 2023 had this symlink" and remain accurate. (Obviously we'll have to deploy the change before April)

[edwinbalani]

There's also a spin-off argument that arises: in favour of scrapping symlinks to group account homedirs, on the basis that a symlink from one's homedir to the group's homedir doesn't grant 'equity' to the group's pubdir, which gets no symlink¹.

I don't know if that's too bold a move. As far as interaction with the filesystem goes, the heavily trodden path for group account admins is to manage website content, e.g. installing WordPress via SFTP², and having two symlinks to lead you there is convenient. However at the same time I think an understanding of the homedir/pubdir distinction (and the personal/group file space distinction, on an orthogonal axis) is something to encourage, or almost force, because it has implications for the visibility of account data³ and we can't abstract it away entirely.

Footnotes

1. save for the transitive personal homedir -> group homedir -[ public_html symlink ]-> group public_html path ↩

2. this is anecdotal, I have no evidence ↩

3. we value privacy by default ↩

[rsa33]

I am in favour of dropping both ~/public_html and ~user/group symlinks, and we may as well do both at the same time.

I'm not sure the convenience of having access to either of these from a home directory is worth the headaches of users deleting and recreating them incorrectly (which for the former at least seems to happen surprisingly often), the change means users have to use the paths we show in the docs (a consistency win), and I concur with making the private/public and user/group distinctions more obvious.

[CHTJonas]

+1 this would eliminate a lot of support toil, but more importantly it would benefit beginner users who aren't aware of the subtleties of softlinks. Advanced users are free to create them as they see fit - we could even add a tutorial about it to the docs site.

[CHTJonas]

Given we're now in April, the timebomb in the code probably wants updating!