Addon Domain and Subdomain System Problems

skyrant

Member
Feb 11, 2020
17
2
3
Germany
cPanel Access Level
DataCenter Provider
Example.

Customer with 5 domains: one.de, one.com, one.eu, two.de, two.com

Account is created with one.com
User creates one.de as addon domain
System suggests to use subdomain (why?) with the name "one" which results in: "one.one.com".
System suggests [home]/public_html/one.de

User creates one.eu as addon domain
System fails because it again suggests "one" as subdomain. BLOCKER
User is smart and changes subdomain to "one.eu" which results in: "one.eu.one.com"
System suggests [home]/public_html/one.eu

User creates two.de as addon domain
System suggests "two" as subdomain which results in: "two.one.com"
System suggests [home]/public_html/two.de

User creates two.com as addon domain
System fails because it again suggests "two" as subdomain. BLOCKER
User is smart and changes subdomain to "two.com" which results in: "two.com.one.com"
System suggests [home]/public_html/two.com


Multiple things wrong with this approach:
  1. The system should suggest FQDN as subdomain to avoid the ERROR. Has this been tested?
  2. Why is a subdomain even needed in the first place. This is a completely independent domain.
  3. The user can not change this subdomain after creation so it should be hidden from the user on creation.
  4. Why is the main directory the root directory of the account domain? Every domain and subdomain should have their own unique directory for obvious reasons.
  5. The subdomain naming is also reflected in the log files ("two.com.one.com-ssl_log-%M%-%YYYY") which makes them equally ridiculous to maintain and use.
  6. If you create a new email it shows all the weirdly named subdomains. Does the user really need to see "mycooldomain.com.myfirstcooldomain.com"?
  7. These subdomains show up everywhere in the interface and just clutter it up and cause user errors. It's frankly ridiculous.

Solutions/Suggestions

  1. Don't show the subdomain option and instead use the FQDN. This removes errors and it is something the user should NOT be bothered with if he can not change it after the fact without completely deleting the addon domain (which results in possible data loss). It's bad UX, leads to confusion and support cases.
  2. Enable the user to change the subdomain in the addon domain window just like he can change redirection and document root.
  3. Why does the system even need a subdomain for addon domains? This is a seperate domain. Baffling decision to convolute and over complicate a simple issue.
  4. Creating the subdomains and addon domains as directories in the root of the main domain is insecure and error prone. I don't think i need to go into detail how completely ridiculous this is from a security and maintenance standpoint. Not to mention issues with .htaccess, user errors and much more.
  5. All domains should have their own isolated directory. See example for a reasonable and maintainable structure below:
[USER_HOME]/domains/[FQDN]/public_html

I know there is an option in tweak settings to remove the restriction of document roots to public_html, this does help but this opens another can of worms with the user being able to use existing directories like "log" or "mail". Ideally there would be an option to restrict roots

Restrict document roots to: [ ]

WHM Root can then control where the user creates these subdirectories. if possible include variables that get expanded like %domain%, %home% etc.

The same pretty much applies to actual subdomains.

Thanks.
 
Last edited:

cPanelLauren

Product Owner
Staff member
Nov 14, 2017
13,297
1,251
313
Houston
This is a valid complaint and I'm not going to spend a ton of time justifying it because we *are* moving away from this way of setting up domains. Right now all addon domains are actually created *AS* aliases of subdomains of the primary domain which is why you see the behavior you do. We are moving away from this and will be changing the whole way this is looked at/done in the future. The domains interface at cPanel>>Domains>>Domains is what will eventually take place of the others.


There are a bunch of feature requests for this but it is already a planned item.


since we're changing this whole way of doing things these are most likely void but I thought they'd be worth taking a look at:
https://features.cpanel.net/topic/remove-requirement-for-a-subdomain-when-creating-an-addon-domain


Also along with these changes will be further ability to change/customize document root related items but it's not beneficial to get into that until this is changed.
 

cPanelLauren

Product Owner
Staff member
Nov 14, 2017
13,297
1,251
313
Houston
It's an iterative process, the first steps have already begun. I don't have a firm date on when this will be completely done, but I do believe in v88 some significant changes will be present to this portion of the UI as well as how this data is stored.