Allow Server Administrators to restrict Subdomain DocumentRoot

[sparek]

I made this as a feature request on the feedback system. But that was 2 days ago and it's still sitting in moderation. Never know if anyone ever pays attention to the feature request system. Never been a huge fan of feature request features, because it doesn't seem to garner as much attention and discussion as forum posts.

A lot was made with changing the DocumentRoot for subdomains some versions back. The create a Subdomain now pops up a menu asking the user what they want to use for their Subdomain's DocumentRoot. I'm more of a fan of giving end users less options, because the more options you give them the more likely they are to mess something up.

I realize some server administrators may not feel that way and may want to give end users the most control. I just don't happen to be one.

I'd prefer an option where the server administrators can define what options they want to show to end users for subdomain DocumentRoots. Or to just remove the options entirely and set the subdomain DocumentRoot to /home/%user%/domains/%subdomain%/public_html so that the end user has no control of it.

If end users aren't given any option, then they learn to live with the option that is provided. If they must, absolutely have to have a subdomain's DocumentRoot inside another domain's DocumentRoot, they can contact us (the webhosting provider) and we'll set a symlink accordingly. But I doubt many end users will want anything different than what is provided.

I'm a big fan of Occam's Razor in the sense of giving users the least number of options that are really necessary. The issue with the current system is that end users will click anything. So they may have one subdomain set in one DocumentRoot format and another subdomain in another format. Then they get confused as to where the content is for each subdomain. Restricting this to just a single path would seem to be best.

In the interim, I'll probably just modify the virtualhost templates to always set the DocumentRoot to /home/%user%/domains/%subdomain%/public_html regardless of what option the user actually selects. Not a great solution, but it keeps things simple. And I prefer simple things for my clients.

 

[Richard G]

Or to just remove the options entirely and set the subdomain DocumentRoot to /home/%user%/domains/%subdomain%/public_html so that the end user has no control of it.

I wouldn't like that to remove it completely. Admin and reseller changable is a must imho.
It's not that difficult currently, the popup shows the default option which they can and will easily choose. Except for the exceptions ofcourse.

ut I doubt many end users will want anything different than what is provided.

In the old days we also did not have many users wanting anything else than what was provided at that time with the subdomain within the normal public_html, times change.

However it is odd that your request is moderated in the feature request site.

 

[sparek]

Well, when you go to the DirectAdmin feedback site

Upvoty

feedback.directadmin.com

and sort listing by newest.

And you see that the "newest" item is 1 month old, followed by 2 months... all the way down to 9 months before the ajax retrieves more listings. Either nobody is clearing moderation posts or the system is just not fully utilized.

That's why I'm not a huge fan of such systems.

At least with the forum you get some feedback from other DirectAdmin users.

The negative to the forum is that you're only getting feedback from a small subset of users. If you look at the forum, you're basically getting responses from 20? (I'm eyeballing) users. Probably no more than 50 users. And there's more DirectAdmin users than that.

But if the forum user activity is so low, you can only imagine how low the feedback system activity is.

 

[Richard G]

But if the forum user activity is so low, you can only imagine how low the feedback system activity is.

Correct but there are a lot of things in the feedback section waiting. Better backup has status planned.
I know they are completely rebuilding DA so every version you see new things, so my good guess is that the feedback stuff is set to a lower priority until the major changes they want to do with DA itself are done.
Otherwise they might have to change implementation of requested features in another way. I don't know just guessing.

Activity might be low if people don't need a lot. I have a look once a while, but not to often because if voted then the vote stays.

Agreed that there might be some more activity or maybe some news about the feature planning or why it's in such wait state.