As a Systems Administrator, I would like the ability to specify the Primary Domains Document root within the users /home/$user folder during the Create an Account function
Main Domain to use a subfolder like addon domains
Open Discussion
As a Website Owner, I would like my Main Domain to use a subfolder like addon domains, so that I can have better Multi-Domain setups.
In the True Multi-Domain Paradigm:
- Any domain can be parked on any other domain in an account
- Adding a domain DOES NOT also result in a subdomain being created
- Any domain can be assigned a static IP
- Because any domain can be assigned a static IP multiple SSL certificates can exist in a single hosting account
This is a feature that has been migrated over from the cPanel Forums. All previous comments and discussions concerning this feature can be located at:
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
The SSL services per-domain instead of per-user are probably the most important one of the issues listed here, but the others are cool too.
Also, the subdomain thing is really confusing even for our support team.
The SSL services per-domain instead of per-user are probably the most important one of the issues listed here, but the others are cool too.
Also, the subdomain thing is really confusing even for our support team.
I would prefer main domain removed completely. There is no need for a main domain on an account. This is an old thinking that has since cPanels start been with us. It only causes problems. All domains should be handled as "Addon Domains" with separate folders.
Also the way cPanels keep track of addons/parked domains with subdomains of main domains is completely fail. This would have to be re-done, in a more correct way.
/Marcus
I would prefer main domain removed completely. There is no need for a main domain on an account. This is an old thinking that has since cPanels start been with us. It only causes problems. All domains should be handled as "Addon Domains" with separate folders.
Also the way cPanels keep track of addons/parked domains with subdomains of main domains is completely fail. This would have to be re-done, in a more correct way.
/Marcus
Marcus has a point here, main domain should be removed completely. I can't even count with my hands how many clients of mine have changed domains and receive an error screen when trying to log into cpanel with their expired domain.
Marcus has a point here, main domain should be removed completely. I can't even count with my hands how many clients of mine have changed domains and receive an error screen when trying to log into cpanel with their expired domain.
I don't like my addon-domain.com
to be accessed like www.main-domain.com/addon-domain.com
imagine one clients website can load under another client website and Google can also cache this !!!!
I strongly suggest the main domain and
Add-on domain each should have their own folder.
And let the user to decide which folder
to point the main domain.
At the moment things are messy.
I don't like my addon-domain.com
to be accessed like www.main-domain.com/addon-domain.com
imagine one clients website can load under another client website and Google can also cache this !!!!
I strongly suggest the main domain and
Add-on domain each should have their own folder.
And let the user to decide which folder
to point the main domain.
At the moment things are messy.
This is really a basic thing that must be implemented asap. cPanel currently have a complete mess with main/addon domain with subdomain concept.
This is really a basic thing that must be implemented asap. cPanel currently have a complete mess with main/addon domain with subdomain concept.
I agree 100% this should be done NOW.
This is the Main Reason holding me back from purchasing a license and using it.
I need structure and organization.
I like the idea of throwing it in its own folder (which can be specified)
But making the whole idea of a main domain for an account go away would be nice. Just have an "account" and then add domains etc as needed or remove.
I agree 100% this should be done NOW.
This is the Main Reason holding me back from purchasing a license and using it.
I need structure and organization.
I like the idea of throwing it in its own folder (which can be specified)
But making the whole idea of a main domain for an account go away would be nice. Just have an "account" and then add domains etc as needed or remove.
I find this feature to be very important.
I find this feature to be very important.
We deploy in an academic environment where we do not control DNS - our parent IT org does. For expediency (it can take days to weeks for tickets to process for domain requests) we have built custom WHM hooks to write custom configs that accomplish exactly this. Essentially, upon account creation ___.college.edu resolves to college.edu/____ and includes are landed in Apache and in the respective account that allow suphp, etc to work appropriately.
I agree with others that de-coupling the idea of sub/main domains from accounts would be HUGELY beneficial. It would certainly allow us to finally retire a massive amount of jury-rigged solutions.
Now, it should also be said that cPanel's robust API/hook functionality is what allows our solution to work in the first place, and the cPanel devs are to be commended for building such a hugely flexible product.
We deploy in an academic environment where we do not control DNS - our parent IT org does. For expediency (it can take days to weeks for tickets to process for domain requests) we have built custom WHM hooks to write custom configs that accomplish exactly this. Essentially, upon account creation ___.college.edu resolves to college.edu/____ and includes are landed in Apache and in the respective account that allow suphp, etc to work appropriately.
I agree with others that de-coupling the idea of sub/main domains from accounts would be HUGELY beneficial. It would certainly allow us to finally retire a massive amount of jury-rigged solutions.
Now, it should also be said that cPanel's robust API/hook functionality is what allows our solution to work in the first place, and the cPanel devs are to be commended for building such a hugely flexible product.
I also find this is very important. They say www is implicit, but I found several posts in forums asking how to setup an htaccess file redirect to workaround that missing option in cPanel.
There are several people, that like me, have several subdomains, and like to have each site on its own separate folder, as a matter of organization !
I hope they add this feature !! This seems small thing but it's definetly not !
[]s
I also find this is very important. They say www is implicit, but I found several posts in forums asking how to setup an htaccess file redirect to workaround that missing option in cPanel.
There are several people, that like me, have several subdomains, and like to have each site on its own separate folder, as a matter of organization !
I hope they add this feature !! This seems small thing but it's definetly not !
[]s
You can work around it by adding the account on a subdomain in whm. Then add your "main domain" and any number of domains as addon domains on any root folder in cPanel . The domains will then not be related (example.com/example2.com) and you can move/change/shift domains and folders as you please.
Well, not the SSL part, but it solves some of the problems with a main domain holding up the account.
You can work around it by adding the account on a subdomain in whm. Then add your "main domain" and any number of domains as addon domains on any root folder in cPanel . The domains will then not be related (example.com/example2.com) and you can move/change/shift domains and folders as you please.
Well, not the SSL part, but it solves some of the problems with a main domain holding up the account.
this would require a new account system and old account system, because you cannot move current accounts (many have absolute paths in scrips etc) so maybe on new account creation the domains could each have a private folder totally separate and only for them, it is quite a feat to acomplish this migration if not impossible. i only see it as a "new account system" and "old account system" and migration tools or options that new accounts are created with multi domain option
also script installers need to be adapted to work with this too so i do not see it as a 2 week iteration :) however with such an upgrade many other things would need to be addressed as well.
this would require a new account system and old account system, because you cannot move current accounts (many have absolute paths in scrips etc) so maybe on new account creation the domains could each have a private folder totally separate and only for them, it is quite a feat to acomplish this migration if not impossible. i only see it as a "new account system" and "old account system" and migration tools or options that new accounts are created with multi domain option
also script installers need to be adapted to work with this too so i do not see it as a 2 week iteration :) however with such an upgrade many other things would need to be addressed as well.
The main domain points to the public_html folder and i want to change it
to something like public_html/maindomain. I want to do this so i can
get a better and more organized folder structure. Like so:
public_html/maindomain
public_html/addondomain1
public_html/addondomain2
etc...
This is also more secure and error-free because when you ftp to your
main domain you have direct access to the addon domains folders and its
very easy to mess up like accidentally add, overwrite or delete some
file or folder.
The main domain points to the public_html folder and i want to change it
to something like public_html/maindomain. I want to do this so i can
get a better and more organized folder structure. Like so:
public_html/maindomain
public_html/addondomain1
public_html/addondomain2
etc...
This is also more secure and error-free because when you ftp to your
main domain you have direct access to the addon domains folders and its
very easy to mess up like accidentally add, overwrite or delete some
file or folder.
That is a must! Thanks for sharing!
Please cPanel, do consider this.
Any chance we could get it? When?
Thanks,
That is a must! Thanks for sharing!
Please cPanel, do consider this.
Any chance we could get it? When?
Thanks,
This is needed! If not, All other sub domains or add-on domains will get thrown in the same directory as the primary domain.
This is needed! If not, All other sub domains or add-on domains will get thrown in the same directory as the primary domain.
Didn't find a separate request for it but I think the default doc root for the primary should also be moved to a directory under public_html as well. Much cleaner to have all the domains as their own top level directory, and easier to manage rewrite paths. Many people don't get how a domain in a subdirectory is able to function as a separate domain still as well.
Didn't find a separate request for it but I think the default doc root for the primary should also be moved to a directory under public_html as well. Much cleaner to have all the domains as their own top level directory, and easier to manage rewrite paths. Many people don't get how a domain in a subdirectory is able to function as a separate domain still as well.
This is a must IMO. Working at a large web host I see a lot of problems caused by the decision to put Addons etc under the web root for the main domain.
It doesn't make any sense to do it this way.
This is a must IMO. Working at a large web host I see a lot of problems caused by the decision to put Addons etc under the web root for the main domain.
It doesn't make any sense to do it this way.
I agree with this, specially the part where the OP says:
Adding a domain DOES NOT also result in a subdomain being created
cPanel does a hell of a mess in order to keep up with the domains, by creating an array of subdomains, FTP accounts and a lot of other settings that will only slow down or machines. As said before, can you guys rethink the way domains work? It should be clean...
I agree with this, specially the part where the OP says:
Adding a domain DOES NOT also result in a subdomain being created
cPanel does a hell of a mess in order to keep up with the domains, by creating an array of subdomains, FTP accounts and a lot of other settings that will only slow down or machines. As said before, can you guys rethink the way domains work? It should be clean...
The main issues with this messy cPanel default of placing the add on domains under public_html are:
So I really hope guys from cPanel take a look at this issues and remake the domain system. The best option would be to completely drop the concept of main domain from the accounts. I know this will make some issues like how should users be named etc but I guess they're not that hard to solve...Really for now I would be be happy if cPanel did this:
Thank you.
The main issues with this messy cPanel default of placing the add on domains under public_html are:
So I really hope guys from cPanel take a look at this issues and remake the domain system. The best option would be to completely drop the concept of main domain from the accounts. I know this will make some issues like how should users be named etc but I guess they're not that hard to solve...Really for now I would be be happy if cPanel did this:
Thank you.
I'm relatively new to cPanel but enjoying its more useful interface than the one I came from. However the thing that seems quite illogical about it is the main domain and user domain setup like so many here have mentioned. It would be great to see a 'flat' model.
I'm relatively new to cPanel but enjoying its more useful interface than the one I came from. However the thing that seems quite illogical about it is the main domain and user domain setup like so many here have mentioned. It would be great to see a 'flat' model.
I'm no expert, and correct me if my method is flawed in some way, but I figured out a while ago that this whole Addon domain business was a complete mess what with it wanting to put everything in the main domain's public_html folder and it also created a ton of mess with phantom subdomains that appear in other lists like email setup, filters, or wherever (I forget exactly where).
NB: IGNORE ANY "http://" you see added below by the forum software - I can't stop it showing!
Anyway, this is what I do, in cPanel Addon domains:
1) Enter the new domain name, for this example I'll use "mynewdomain.com"
2) Click in the next box down and stuff autofills in this box and in the next box down. You need to change these to something that works for you, but I'll show what I use.
3) For Subdomain or FTP Username (NB that really ought to be "and" not "or" because both are created) enter "z-mynewdomaincom" (the box here wont accept "." (dots) and I like to add the whole domain name to avoid confusion between similar domain names). It can actually be named anything you like, the "z-" will keep this alphabetically listed and out of the way at the bottom of other cPanel setting lists. So this could be "z-mndcom" or "z-idontcarecom" but it makes sense to keep it as something you'll recognise and associate with the domain later.
4) For the next box down, Document Root, this is the important one to get right, if you leave it as is it will put the Addon domain in the main domain's public_html folder - you don't want that!. What you actually want to do is put it at the same level in the directory structure as the public_html folder. So, delete what's already in there and I add exactly the name of my domain complete with the dots and the www plus a folder I want the website files to be in (e.g. the Addon domain's very own public_html folder). So in this case I'd enter "http://www.mynewdomain.com/public_html" (NB ignore/don't enter http://), this works well in two ways, one because I'm never going to get confused about what domain I'm dealing with and secondly, all the Addon domains stay nicely together amongst all the other stuff in that main account's "home" folder. Adding the public_html folder on the end ensures you have some storage space above the website's folder that can't e accessed from the outside world and keeps it all tidy away from the main parental home folder. It could actually be called anything you like but I just keep it as public_html for the sake of ease.
5) That's it, create a password and click "Add Domain", your new site is now sitting at the same level as the main domain's public_html folder instead of messing it all up.
6) When you create another Addon domain, just do the same, rename the Subdomain/FTP box to z-anotherdomaincom, and the Document root to http://www.anotherdomain.com/public_html (NB ignore/don't enter http://)
There was one last set of steps I noted I could do, because of all the extra flipping (unrequired) subdomains that get created (now all usefully with "z-" as a prefix). The process seems to create a bunch of extraneous entries in your main domain's (account's) Advanced DNS Zone Editor entries. I just deleted the ones that had a "z-" on the front (one with www and the other without) that had A Records (with an IP address) associated, and that all seemed to be okay to do. (You may want to verify this last step, I did it last year on one of my cPanel accounts and it hasn't bitten me yet!)
If I want to create a "real" subdomain outside of any public_html folder (and alongside the Addon domains I do the same as above but add on the subdomain at the end (to keep things in nice, easy to spot, sort order), so my subdomain might look like this: "http://www.mynewdomain.com_newsubdomain" (NB ignore/don't enter http://), that too created with its own public_html folder.
The only things that's really left to do after all that is set up your emails, filters and other things and you'll soon start to see the benefits of naming all those pesky "fake" subdomains with a "z-" because they'll no longer be mixed in with your real domains what with all their fancy extra long confusing names that join the Addon domain to the main domain name giving entries like "z-mynewdomaincom.mymaindomain.com"
As for why cPanel do all this domain configuration this awful convoluted and messy way, I can only think it's historic and really difficult to unpick and make better. All the same, if my method works, then it's fairly easy to setup and redo if you have already set things up the bad-old way (just delete the old entries, do the above and move/copy the site folders across (My folder didn't get deleted so it was easy to move but BACKUP FIRST). When I moved a couple Addon domains recently, I thought I'd wiped an email account (it disappeared from the list) but it popped back once I'd recreated the Addon domain in it's new place (be warned, may not happen for you like that. Backup, backup, backup.).
Hope that helps someone. Not guaranteeing I'm absolutely right with all this, it's working for me I think and has done for about a year.
I'm no expert, and correct me if my method is flawed in some way, but I figured out a while ago that this whole Addon domain business was a complete mess what with it wanting to put everything in the main domain's public_html folder and it also created a ton of mess with phantom subdomains that appear in other lists like email setup, filters, or wherever (I forget exactly where).
NB: IGNORE ANY "http://" you see added below by the forum software - I can't stop it showing!
Anyway, this is what I do, in cPanel Addon domains:
1) Enter the new domain name, for this example I'll use "mynewdomain.com"
2) Click in the next box down and stuff autofills in this box and in the next box down. You need to change these to something that works for you, but I'll show what I use.
3) For Subdomain or FTP Username (NB that really ought to be "and" not "or" because both are created) enter "z-mynewdomaincom" (the box here wont accept "." (dots) and I like to add the whole domain name to avoid confusion between similar domain names). It can actually be named anything you like, the "z-" will keep this alphabetically listed and out of the way at the bottom of other cPanel setting lists. So this could be "z-mndcom" or "z-idontcarecom" but it makes sense to keep it as something you'll recognise and associate with the domain later.
4) For the next box down, Document Root, this is the important one to get right, if you leave it as is it will put the Addon domain in the main domain's public_html folder - you don't want that!. What you actually want to do is put it at the same level in the directory structure as the public_html folder. So, delete what's already in there and I add exactly the name of my domain complete with the dots and the www plus a folder I want the website files to be in (e.g. the Addon domain's very own public_html folder). So in this case I'd enter "http://www.mynewdomain.com/public_html" (NB ignore/don't enter http://), this works well in two ways, one because I'm never going to get confused about what domain I'm dealing with and secondly, all the Addon domains stay nicely together amongst all the other stuff in that main account's "home" folder. Adding the public_html folder on the end ensures you have some storage space above the website's folder that can't e accessed from the outside world and keeps it all tidy away from the main parental home folder. It could actually be called anything you like but I just keep it as public_html for the sake of ease.
5) That's it, create a password and click "Add Domain", your new site is now sitting at the same level as the main domain's public_html folder instead of messing it all up.
6) When you create another Addon domain, just do the same, rename the Subdomain/FTP box to z-anotherdomaincom, and the Document root to http://www.anotherdomain.com/public_html (NB ignore/don't enter http://)
There was one last set of steps I noted I could do, because of all the extra flipping (unrequired) subdomains that get created (now all usefully with "z-" as a prefix). The process seems to create a bunch of extraneous entries in your main domain's (account's) Advanced DNS Zone Editor entries. I just deleted the ones that had a "z-" on the front (one with www and the other without) that had A Records (with an IP address) associated, and that all seemed to be okay to do. (You may want to verify this last step, I did it last year on one of my cPanel accounts and it hasn't bitten me yet!)
If I want to create a "real" subdomain outside of any public_html folder (and alongside the Addon domains I do the same as above but add on the subdomain at the end (to keep things in nice, easy to spot, sort order), so my subdomain might look like this: "http://www.mynewdomain.com_newsubdomain" (NB ignore/don't enter http://), that too created with its own public_html folder.
The only things that's really left to do after all that is set up your emails, filters and other things and you'll soon start to see the benefits of naming all those pesky "fake" subdomains with a "z-" because they'll no longer be mixed in with your real domains what with all their fancy extra long confusing names that join the Addon domain to the main domain name giving entries like "z-mynewdomaincom.mymaindomain.com"
As for why cPanel do all this domain configuration this awful convoluted and messy way, I can only think it's historic and really difficult to unpick and make better. All the same, if my method works, then it's fairly easy to setup and redo if you have already set things up the bad-old way (just delete the old entries, do the above and move/copy the site folders across (My folder didn't get deleted so it was easy to move but BACKUP FIRST). When I moved a couple Addon domains recently, I thought I'd wiped an email account (it disappeared from the list) but it popped back once I'd recreated the Addon domain in it's new place (be warned, may not happen for you like that. Backup, backup, backup.).
Hope that helps someone. Not guaranteeing I'm absolutely right with all this, it's working for me I think and has done for about a year.
This needs to be added. The current way is just idiotic.
This needs to be added. The current way is just idiotic.
This issue really needs to be fixed as it does create a bunch of headache. Especially in regards to relative paths and scripts in general. One domain one folder. One subdomain, one subdomain folder. One primary domain, one main folder. All folders should be the same level mapping each virtual host, with the document root for that user being public_html. Please fix it, especially before EasyApache 4 comes out to fix a broken paradigm that has been in cPanel way too long.
This issue really needs to be fixed as it does create a bunch of headache. Especially in regards to relative paths and scripts in general. One domain one folder. One subdomain, one subdomain folder. One primary domain, one main folder. All folders should be the same level mapping each virtual host, with the document root for that user being public_html. Please fix it, especially before EasyApache 4 comes out to fix a broken paradigm that has been in cPanel way too long.
Is there any way to split hosting account and domains? To have a master FTP to enter public_html that would be associated with hosting account, and have separate folders and FTP users to be associated with each domain?
Is there any way to split hosting account and domains? To have a master FTP to enter public_html that would be associated with hosting account, and have separate folders and FTP users to be associated with each domain?
Big +1 on this, especially given the fact that is is really easy to change it for "addon domains", which in fact makes that a workaroud.
Big +1 on this, especially given the fact that is is really easy to change it for "addon domains", which in fact makes that a workaroud.
what a load of rubbish, why should everyone have to have this system due to a few wanting this. I hope cpanel make this opt in/opt out.
cPanel need to take into consideration ALL their customers.
what a load of rubbish, why should everyone have to have this system due to a few wanting this. I hope cpanel make this opt in/opt out.
cPanel need to take into consideration ALL their customers.
This request should have: https://features.cpanel.net/topic/true-multi-domain-support-multiple-certificates-ips-per-acct merged in with it really. As they are both talking about the same thing.
This request should have: https://features.cpanel.net/topic/true-multi-domain-support-multiple-certificates-ips-per-acct merged in with it really. As they are both talking about the same thing.
So I am a visual person.. Currently it is like this:
public_html/ <main site is in here.
then
public_html/Adomain.com < as a folder
public_html/Bdomain.com < as a folder
public_html/Cdomain.com < as a folder
Correct?
I think all that is being asked its to make it more like:
public_html/Maindomain.com < as a folder
public_html/Adomain.com < as a folder
public_html/Bdomain.com < as a folder
public_html/Cdomain.com < as a folder
The question with this would be what would prevent you from using
public_html/ and putting web items in there.. I see it could be come like no mans land.
But maybe I don't get the request.
So I am a visual person.. Currently it is like this:
public_html/ <main site is in here.
then
public_html/Adomain.com < as a folder
public_html/Bdomain.com < as a folder
public_html/Cdomain.com < as a folder
Correct?
I think all that is being asked its to make it more like:
public_html/Maindomain.com < as a folder
public_html/Adomain.com < as a folder
public_html/Bdomain.com < as a folder
public_html/Cdomain.com < as a folder
The question with this would be what would prevent you from using
public_html/ and putting web items in there.. I see it could be come like no mans land.
But maybe I don't get the request.
The way I saw it was being able to specify the default structure.
I would actuallay like something more like :
sites/DOMAIN1.TLD/public_html
sites/DOMAIN2.TLD/public_html
sites/DOMAIN3.TLD/public_html
as we currently already have mail so why not have a sites directory.
I think each webost should be able to specify in which directory domains are created by default, and which directory inside this directory the vhosts should point to by default
I would like to have all domains and subdomains alongside each other and for each of them to have their own public_html directory.
This way Symfony users or Laravel users can upload their application to sites/DOMAIN.TLD/ and then change the web directory to public for laravel or web pour symfony.
The way I saw it was being able to specify the default structure.
I would actuallay like something more like :
sites/DOMAIN1.TLD/public_html
sites/DOMAIN2.TLD/public_html
sites/DOMAIN3.TLD/public_html
as we currently already have mail so why not have a sites directory.
I think each webost should be able to specify in which directory domains are created by default, and which directory inside this directory the vhosts should point to by default
I would like to have all domains and subdomains alongside each other and for each of them to have their own public_html directory.
This way Symfony users or Laravel users can upload their application to sites/DOMAIN.TLD/ and then change the web directory to public for laravel or web pour symfony.
Well that wasn't my intention, the intention is that all the domain folders would sit inside the home directory rather than public_html. As a long time user of Hsphere, I can say that customers prefer that over the way cPanel does things.
Well that wasn't my intention, the intention is that all the domain folders would sit inside the home directory rather than public_html. As a long time user of Hsphere, I can say that customers prefer that over the way cPanel does things.
So @Karl you want
/user/home/maindomainusername/Maindomain.com < as a folder
~maindomainusername/Adomain.com < as a folder
~maindomainusername/Bdomain.com < as a folder
~maindomainusername/Cdomain.com < as a folder
Seems fine to. The only thing I might say is Public_html is a good identifier for users. if their domain is clienta.com
might look funny in their user panel to look at my hostsdomain.com and in there is clienta.com
So @Karl you want
/user/home/maindomainusername/Maindomain.com < as a folder
~maindomainusername/Adomain.com < as a folder
~maindomainusername/Bdomain.com < as a folder
~maindomainusername/Cdomain.com < as a folder
Seems fine to. The only thing I might say is Public_html is a good identifier for users. if their domain is clienta.com
might look funny in their user panel to look at my hostsdomain.com and in there is clienta.com
I had this Addon domain problem before I moved to a shared hosting
solution that allowed me to have a cPanel account for each domain
thereby avoiding the whole problem. Now, long gone is the Addon domain
mess, but the process I outlined above (from about 12 months ago) did
work well to keep everything more neatly arranged and without everything
being in the main domain's public_html folder behaving like
sub-domains.
I still had a public_html for the main domain, but
for all the addon domains I had them alongside that public_html folder
and not in it, and inside each of those addon domain folders I created a
public_html folder for the actual site files and therefore there was a
parent folder to keep non public files in (and at the same time avoiding
cross contamination from other users, sites and files).
Using the same principles, (apart from main account's domain) it would be
perfectly possible to create the suggested addon domain structure of:
sites/DOMAIN1.TLD/public_html
sites/DOMAIN2.TLD/public_html
sites/DOMAIN3.TLD/public_html
I just left off the "sites" folder and had them all at the same level as
the main domain's public_html folder. (NB I think it wasn't possible to
use dots in the folder naming structures so use something like
DOMAIN3-TLD instead)
I had this Addon domain problem before I moved to a shared hosting
solution that allowed me to have a cPanel account for each domain
thereby avoiding the whole problem. Now, long gone is the Addon domain
mess, but the process I outlined above (from about 12 months ago) did
work well to keep everything more neatly arranged and without everything
being in the main domain's public_html folder behaving like
sub-domains.
I still had a public_html for the main domain, but
for all the addon domains I had them alongside that public_html folder
and not in it, and inside each of those addon domain folders I created a
public_html folder for the actual site files and therefore there was a
parent folder to keep non public files in (and at the same time avoiding
cross contamination from other users, sites and files).
Using the same principles, (apart from main account's domain) it would be
perfectly possible to create the suggested addon domain structure of:
sites/DOMAIN1.TLD/public_html
sites/DOMAIN2.TLD/public_html
sites/DOMAIN3.TLD/public_html
I just left off the "sites" folder and had them all at the same level as
the main domain's public_html folder. (NB I think it wasn't possible to
use dots in the folder naming structures so use something like
DOMAIN3-TLD instead)
It's not really maindomainusername though is it? It's accountusername - it doesn't have to bear any resemblance to a domain added to the account, and I'd argue it really shouldn't in any sane system.
In this situation a domain is just a domain, there is no main domain - it's just another domain on the account, delete it if you want and add another, it doesn't matter.
It's not really maindomainusername though is it? It's accountusername - it doesn't have to bear any resemblance to a domain added to the account, and I'd argue it really shouldn't in any sane system.
In this situation a domain is just a domain, there is no main domain - it's just another domain on the account, delete it if you want and add another, it doesn't matter.
If you are using add-on domains, you might as well signup for the Malware Bandwagon. If you have more than one site, use WHM.
If you are using add-on domains, you might as well signup for the Malware Bandwagon. If you have more than one site, use WHM.
In response to the people having the discussion about the filesystem paths where all sites should be located ("sites/DOMAIN1.TLD"), please see my recommended paths in another Feature Request...
Customize default path for new subdomains
https://features.cpanel.net/topic/customize-default-path-for-new-subdomains#comment-45995
https://features.cpanel.net/topic/customize-default-path-for-new-subdomains#comment-46003
I also have a Full "Home Directory Cleanup" Feature Request, that I have not posted yet, which is partially mentioned in my 2nd reply (linked above).
In response to the people having the discussion about the filesystem paths where all sites should be located ("sites/DOMAIN1.TLD"), please see my recommended paths in another Feature Request...
Customize default path for new subdomains
https://features.cpanel.net/topic/customize-default-path-for-new-subdomains#comment-45995
https://features.cpanel.net/topic/customize-default-path-for-new-subdomains#comment-46003
I also have a Full "Home Directory Cleanup" Feature Request, that I have not posted yet, which is partially mentioned in my 2nd reply (linked above).
It definitely think this needs to be configurable.
In our point of view there are no subdomains or non subdomains so I would like all domains and subdomains to be at the same level. I do understand Anonymous's point of view and it's logical and a perfectly valid approach. It makes things more organized in exchange for an extra folder depth. I find adding an extra folder makes it a bit more complicated for beginner users and prefer to have all domains and subdomains at the same level. Some might want a specific folder called subdomains so in the end what's important is that the server admin can configure the default path.
It definitely think this needs to be configurable.
In our point of view there are no subdomains or non subdomains so I would like all domains and subdomains to be at the same level. I do understand Anonymous's point of view and it's logical and a perfectly valid approach. It makes things more organized in exchange for an extra folder depth. I find adding an extra folder makes it a bit more complicated for beginner users and prefer to have all domains and subdomains at the same level. Some might want a specific folder called subdomains so in the end what's important is that the server admin can configure the default path.
This is also related to the requests:
https://features.cpanel.net/topic/as-a-hosting-admin-i-would-prefer-to-have-user-accounts-created-at-root-as-a-id-of-some-sort
https://features.cpanel.net/topic/improve-domain-and-subdomain-directory-structure-under-public-html
This is also related to the requests:
https://features.cpanel.net/topic/as-a-hosting-admin-i-would-prefer-to-have-user-accounts-created-at-root-as-a-id-of-some-sort
https://features.cpanel.net/topic/improve-domain-and-subdomain-directory-structure-under-public-html
I am surprised this has not been worked out yet. This is one thing other panels get right. This is a literally a quick project to reconfigure the vhost templates cpanel configures for itself. To prevent backward compatibility it could be a simple setting to use top-level domain and sub-domain folders for domains. The inherited issues with folder structure are the most annoying support related questions.
I am surprised this has not been worked out yet. This is one thing other panels get right. This is a literally a quick project to reconfigure the vhost templates cpanel configures for itself. To prevent backward compatibility it could be a simple setting to use top-level domain and sub-domain folders for domains. The inherited issues with folder structure are the most annoying support related questions.
Our biggest issue at the moment is for customers with symfony or laravel who buy a whm reseller hosting account for their projects and need to supply fake domains for the accounts they create so they can add the real domains as addon domains in order to allow them to point their real domains to laravel's public folder or to symfony's web folder. It's a shame because it makes things seem more complicated then they should be.
Our biggest issue at the moment is for customers with symfony or laravel who buy a whm reseller hosting account for their projects and need to supply fake domains for the accounts they create so they can add the real domains as addon domains in order to allow them to point their real domains to laravel's public folder or to symfony's web folder. It's a shame because it makes things seem more complicated then they should be.
That is my biggest issue as well, some of our accounts don't get addon domains. I get around this for clients with Laravel by editing:
/var/cpanel/userdata/username/userdomain.com
Then changing documentroot to something like:
/home/username/userdomain.com/public
From there:
/usr/local/cpanel/scripts/rebuildhttpdconf
and everything is good for the account moving forward. Could easily be automated using a post account creation hook, but at the moment we are doing it manually.
That is my biggest issue as well, some of our accounts don't get addon domains. I get around this for clients with Laravel by editing:
/var/cpanel/userdata/username/userdomain.com
Then changing documentroot to something like:
/home/username/userdomain.com/public
From there:
/usr/local/cpanel/scripts/rebuildhttpdconf
and everything is good for the account moving forward. Could easily be automated using a post account creation hook, but at the moment we are doing it manually.
Hey all! This conversation has stepped a bit away from user-cases and questions specifically related to the feature request into implementation of the other softwares. Please try to keep the conversation focused, or take it to a discussion on the cPanel Forums. Thanks!
Hey all! This conversation has stepped a bit away from user-cases and questions specifically related to the feature request into implementation of the other softwares. Please try to keep the conversation focused, or take it to a discussion on the cPanel Forums. Thanks!
I think this legacy issue of subdomains being created for addon domains should really have been addressed a long time ago. It really confuses the customers and it's just not necessary . Also - being able to park a domain onto any other domain without it taking up an addon slot is also pretty much a basic requirement that is not being met. These two issues alone should really be a priority for cpanel to finally resolve once and for all!
I think this legacy issue of subdomains being created for addon domains should really have been addressed a long time ago. It really confuses the customers and it's just not necessary . Also - being able to park a domain onto any other domain without it taking up an addon slot is also pretty much a basic requirement that is not being met. These two issues alone should really be a priority for cpanel to finally resolve once and for all!
Hi, is this really planned? The last comment was 3 years ago :p Any chance of this idea being revived?
It'd be great to be able to organize domains and subdomains in an effective, secure and simple manner.
Hi, is this really planned? The last comment was 3 years ago :p Any chance of this idea being revived?
It'd be great to be able to organize domains and subdomains in an effective, secure and simple manner.
I'd love to see a folder structure like this:
/home/{user}/domains/{domain.com}/public_html/
/home/{user}/domains/{domain.com}/subdomains/{subdomain}
/home/{user}/domains/{other-domain.com}/public_html/
It'd be easier to maintain and keep track of websites in an account.
No, you have the possibility to host addon domains or subdomains anywhere in your home directory. That's really bad, specially because regular users don't have a clue as to where they should store their domains and subdomains. So a schema like this should help them out and encourage them to keep their account's file structure clean and tidy. More simple to maintain, and restore backups.
Also, now one may add the subdomain under /public_html/ which mixes up different websites and makes your subdomain accessible by path from your main domain. Doesn't make sense at all.
I'd love to see a folder structure like this:
/home/{user}/domains/{domain.com}/public_html/
/home/{user}/domains/{domain.com}/subdomains/{subdomain}
/home/{user}/domains/{other-domain.com}/public_html/
It'd be easier to maintain and keep track of websites in an account.
No, you have the possibility to host addon domains or subdomains anywhere in your home directory. That's really bad, specially because regular users don't have a clue as to where they should store their domains and subdomains. So a schema like this should help them out and encourage them to keep their account's file structure clean and tidy. More simple to maintain, and restore backups.
Also, now one may add the subdomain under /public_html/ which mixes up different websites and makes your subdomain accessible by path from your main domain. Doesn't make sense at all.
I really can not believe that this is not planned now.
Current cPanel domain/folder structure is very, very bad. Main domain, and parked domains only on main domain, and addon linked to subdomain on main domain, and public_html folder, and www linked to it... I don't even know what to say about all this... Everything is completely wrong here.
I was expecting improvement in development, since your huge license price increase, but instead you now give up on some basic things. Please cPanel, I know it is hard to change this structure now, because it is deeply in system organization, but we really need this improved, so please consider changing this at least for new cPanel accounts.
You can maybe create two different cPanel account types (versions) that will behave different in that segment, and maybe later add some account conversion option to help us slowly upgrade old structure accounts to new structure if someone wish to convert account to new structure.
Static IP per domain is requested 8 years ago, so that part is maybe not really needed today, but domain/folder organization is really terrible, and need to be improved.
I am more for a simple structure like this, that require the least development...
Users with Laravel can always change root to /public with rewrite in .htaccess, and prevent public access to webroot and other folders so that is not really a problem, but structure with some /public folder under domain name folder is also acceptable.
I really can not believe that this is not planned now.
Current cPanel domain/folder structure is very, very bad. Main domain, and parked domains only on main domain, and addon linked to subdomain on main domain, and public_html folder, and www linked to it... I don't even know what to say about all this... Everything is completely wrong here.
I was expecting improvement in development, since your huge license price increase, but instead you now give up on some basic things. Please cPanel, I know it is hard to change this structure now, because it is deeply in system organization, but we really need this improved, so please consider changing this at least for new cPanel accounts.
You can maybe create two different cPanel account types (versions) that will behave different in that segment, and maybe later add some account conversion option to help us slowly upgrade old structure accounts to new structure if someone wish to convert account to new structure.
Static IP per domain is requested 8 years ago, so that part is maybe not really needed today, but domain/folder organization is really terrible, and need to be improved.
I am more for a simple structure like this, that require the least development...
Users with Laravel can always change root to /public with rewrite in .htaccess, and prevent public access to webroot and other folders so that is not really a problem, but structure with some /public folder under domain name folder is also acceptable.
C panel is automatically creating a duplicate site for the add-on domain in a sub domain (under main domain), Most people in this topic know that. But I don't know what's the point with that?
It's causing so many issues, such as duplicate sites, confusing structures, seo and so on, I'm sure may find more things that are hard to solve.
My suggestion is either, do not allow to add add-on domains. or do not create sub domains and duplicate sites.
And my opinion is, its unfair to charge a huge amount every month for c panel and especially limiting accounts per package. For me, the best way to solve the main issue is, hosting one site per one c panel account. To do that we will need few more c panel accounts without paying extra for each accounts every month. The more we use, the more we have to pay,
I loved to work in c panel for last 10 years, it was my favorite.
C panel is automatically creating a duplicate site for the add-on domain in a sub domain (under main domain), Most people in this topic know that. But I don't know what's the point with that?
It's causing so many issues, such as duplicate sites, confusing structures, seo and so on, I'm sure may find more things that are hard to solve.
My suggestion is either, do not allow to add add-on domains. or do not create sub domains and duplicate sites.
And my opinion is, its unfair to charge a huge amount every month for c panel and especially limiting accounts per package. For me, the best way to solve the main issue is, hosting one site per one c panel account. To do that we will need few more c panel accounts without paying extra for each accounts every month. The more we use, the more we have to pay,
I loved to work in c panel for last 10 years, it was my favorite.
Replies have been locked on this page!