Subdomain & Add-on Directory Structure - Design Flaw

SpiderDog

Registered
May 18, 2006
1
0
151
Mountain View, CA
Hi Everyone,

I have a shared server account with my hosting company, and I would like to have some flexibility with the directory structure as to where folders are created when I create sub-domains and add-on domains. It seems however that this is not possible with cPanel. I would like to request that this be evaluated as a design flaw and resolved.

A serious consequence of this is that the directory structure of public_html does not allow the creation of the same subdomain name for different add-on domains. I would like to suggest that the user, with non-root access, should be able create add-on domains in a subfolder under the top-level folder, public_html. Shared users, for example, are not allowed to edit: /etc/httpd/conf/httpd.conf.

Let me illustrate the issue in the code box below. Let's say you register with your hosting provider using 'www.my_site.com'. All folders and files will reside in the public_html folder. Now suppose you want to create add-on domains, 'addon1' and 'addon2'. Then you want to create sub-domains under each of the addon domains. Logical analysis, and standard file system convention, suggests that you should be able to create 'subdomain1' and 'subdomain2' under each of your two add-on domains. cPanel, with it's current design limitations, however, does not allow this.

Your directory structure remains 'flat', meaning all your add-on and sub-domains will reside in 'public_html'. This tends to create a virtual 'mess' if you have more that three or four addon domains with a couple subdomains in each!

What the design should allow, ideally, is the following:
Code:
public_html
     addon-domains
            addon1
                   subdomain1
                   subdomain2
            addon2
                   subdomain1
                   subdomain2
      folder1
      folder2
      ...
This requires that you be able to specify the folder into which to place each of your add-on and sub-domains. cPanel does not let you do that, however.

What Cpanel does instead is put everything in the 'public_html' folder:
Code:
public_html
      addon1
      addon2
      folder1
      folder2
      subdomain1
      subdomain2
      ...
There is a cPanel convention coming up this Summer and I hope these issues will be introduced and resolved.

Related Posts:
Addon Domains.
Subdomain Directory Structure.
Creating Subdomains with Same Name.

cPanel's Training Seminar will be held on June 7th and 8th, 2006, in Houstin, TX.
They will also be attending the HostingCon.com conference in Las Vegas, July 17-19, 2006.

Thank you very much.
 
Last edited:

electric

Well-Known Member
Nov 5, 2001
790
11
318
It's a good suggestion, and your proposed folder structure is good (better).

The problem is that the current system "works", albeit with some serious limitations (as you described).

These limitations, however, are not enough to justify the major amount of work that would be required to reprogram the existing system. Plus, once any new system is created.. then all existing folder structures would need to be converted.

And that... would be a nightmare for cpanel support.

I predict that in the year 2020, this feature request will still not be implemented.

I don't know why the cpanel people don't just close 3/4 of the feature requests in the system where they know 100% they will never be implemented. Seems silly to have a feature request/bug system where things are submitted and then sit there for years in "new" status... :rolleyes:
 

SoftDux

Well-Known Member
May 27, 2006
1,023
5
168
Johannesburg, South Africa
cPanel Access Level
Root Administrator
I have to agree with SpiderDog, this is a design flaw, and it's becoming a pain in the neck to support as well.

Here's the problem.

Let's say we have a main domain for the comapny: www.companyabc.com, with some remote branches, companyabcbranch1.com, companyabcbranch2.com, companyabcbranch3.com

This will create something like:

Code:
/home
         public_html
                     branch1
                     branch2
                     branch3
Now, let's say there's a support department in each branch, so you want:

support.companyabc.com
support.companyabcbranch1.com
support.companyabcbranch2.com
support.companyabcbranch3.com

This doesn't work with the current design.