cPanel & WHM Version 84 has been released, and brings a slew of great updates. Take a look at what is included, and then upgrade today!
 

Main Domain to use a subfolder like addon domains

Feature Importer shared this idea 7 years ago
Planned

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:

http://forums.cpanel.net/f145/true-multi-domain-support-allow-multiple-ssl-certificates-ips-per-account-138917.html

Comments (43)

photo
4

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.

photo
15

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

photo
4

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.

photo
3

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.

photo
2

Marcus Lindström wrote:

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

Well done, this is also a good point. Why bother with the main-domain!

photo
2

Alex K wrote:

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.

You can already do this. Just pick a folder under public_html, it works.

photo
2

This is really a basic thing that must be implemented asap. cPanel currently have a complete mess with main/addon domain with subdomain concept.

photo
3

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.

photo
2

I find this feature to be very important.

photo
2

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.

photo
2

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

photo
2

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.

photo
2

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.

photo
2

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.

photo
2

That is a must! Thanks for sharing!

Please cPanel, do consider this.

Any chance we could get it? When?

Thanks,

photo
1

This is needed! If not, All other sub domains or add-on domains will get thrown in the same directory as the primary domain.

photo
2

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.

photo
3

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.

photo
1

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...

photo
1

Alex K wrote:

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.

You can setup your subdomain outside of the public_html folder, for e.g., we tell clients to set them up as /public_html_domain1-com /public_html_domain2-com and so on. It helps reduce the mess, but we're missing an important part here.


The main issues with this messy cPanel default of placing the add on domains under public_html are:

  • Security, there are some known cross domain attacks that could actually take advantage of this;
  • Clients delete information they don't want to delete: Most of clients are dumb, and eventually they forget they had that other website also under public_html and they delete everything and waste time at the support.
  • Clients don't know where websites are: Yes that happened before...

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:

  1. Change the default place of add on domains to /public_html_domain-name-here instead of the current mess (or multiple folders inside public_html one for each domain...);
  2. Implement true multi domain support and drop the alias thing with subdomains.

Thank you.

photo
1

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.

photo
1

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.

photo
1

This needs to be added. The current way is just idiotic.

photo
1

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.

photo
1

My method (above) still seems to be working fine, all my domains neatly in their own folders alongside the main domain and no pesky addon/subdomain folders or links in or to the main domain folder.

photo
1

Yes even a regular big shared host I was with recommended this method. Still convoluted way of doing this and really needs to be fixed system wide. Support requests about this issue can be ridiculous because this is not the behavior people expect.

photo
photo
1

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?

photo
1

Except for the obvious answer - to buy a cheapest dummy domain (mytrash.cls.kr), to be associated with hosting account without ever really using it, and then treat all domains ass addons.

photo
photo
1

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.

photo
1

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.

photo
1

Hi Terry, What are some of your concerns with this change?

photo
1

it is making cPanel more line DirectAdmin and making the main domain account into a subfolder, this is one of the main reason i don't like DA and decided to use cPanel.


Also this will make it easier for client who pay for charged hosting to create more addon domains on their accounts rather than taking out reseller hosting.

If a user wants to use more domains then get a reseller account so each domain will have their own control panel.

If this is made available then it should be the choice of cPanel users if they want to use this feature or not and not forced onto all users like paper lantern

photo
1

Could you explain how this makes it easier to create addon domains? We're not talking about making things less restrictive, only changing the location of the primary domain.

photo
1

It makes no difference at all to the scenario you're on about Terry. All of that is possible with things as they are now, this does not change any of that.

photo
1

so change the location of primary domain, so all my sites and clients sites that have scripts set in the default public_html will all have to be changed, so are cpanel going to do this or pay for my time in doing it when all my clients complain to me.


why do this when it works perfect the way it is just to please less than 1% of cpanel clientbase.

photo
2

I highly doubt that we will make this change for any existing accounts, only for new accounts that are created. It makes things cleaner, easier, and in a programmatic sense, it makes things a whole lot easier when talking about Apache, languages, etc. We wouldn't change any existing accounts.

photo
1

'We wouldn't change any existing accounts.' thats what they said when Paper Lantern was first brought to light, but then they now make it default even when clients dont want it, and the only way around this is for clients to spend time in making changes to x3.

photo
2

This feature request is about changing the primary domains location, not Paper Lantern. So far, you haven't really provided any reasons why this shouldn't happen. Can you advise what's going on?

photo
1

Terry,

cPanel isn't stupid people - they most likely won't change it for existing accounts but only new (There's a big difference between a change of a theme and a change where files might be heavily relying on this path).


It make sense to change the path, I personally hate that primary domains even exist - you should just have the concept of domains.


Then I wouldn't have to fiddle around with what folder is for what site.

Just relax, and see that it will all work nicely :)

photo
1

its about forcing a feature on all clients when its not needed as they system works fine without it. only 98 people say they want this out of how many direct clients does cpanel have.


If its not Broken then why fix it, Direct Admin uses this method and its the main reason i wont use DA. the main domain should be in the default public_html folder and sub domains go into sub folders.


some scripts will only work if in the main public_html of an account, so you will be telling users they cant use these scripts. dont ask me to name the scripts as their is many out their.

photo
1

I understand Terry's worry that he would have to update paths, but as long as the default behavior uses domain subfolders like addon domains I don't see how this would affect him as that would just be the "default" behavior. I currently modify the default behavior and am already using primary domains as folder names instead of public_html by editing the userdata files directly (annoying).


Also public_html just doesn't describe things correctly. Do you only have HTML inside that folder? I am guessing you have much more than HTML in there. I personally hope this change happens, would work better for git setups, working with multiple domains, and managing accounts.

photo
1

There are a few things that don't quite work 'properly' with our current setup. Doing this will bring in quite a few advancements:


1> No need for subdomains for addon domains (technically this could be done outside the scope of this request, but I'd prefer it to be done at the same time)

2> EA4 turns into a pure 'System Default' model without having to worry about inheritance

3> Cleaner integration and structure


We won't be forcing anything, simply changing the default to the structure for new accounts only. Old accounts will continue to function without worry. We definitely don't want to change that.


As for scripts requiring public_html, I have not heard of this before. Fantastico and some other script installers might require public_html, but they will be updated once this change happens. If an actual web application requires public_html, they are only hurting themselves as they are forcing themselves to only work on cPanel systems, and no where else. I can't think of any scripts that do this. If you want to provide an example, I'm sure we could reach out to them to update their stuff.


From my point of view, I think the pros outweighs the cons for this feature request. I haven't really heard anything else besides the fact yet.

photo
1

I disagree Terry. We need this. It is quite a bit of work for me to constantly have to go into the /var/cpanel/userdata directories to modify the system to work better with multiple domains for my clients.


Also how would this negatively affect you if this is just the default behavior? This shouldn't affect any of the websites you already have setup. It would only be for new domains you setup. So your paths wouldn't be messed up for older sites you have already setup. For any new sites you would have to set paths anyway, so I don't see how this makes anything worse for you? It would greatly help me though.


Having a folder called public_html just makes no sense. Do you just have HTML in there?

photo
1

i dont like the addon domain feature and have it set to 0 for all plans as especially with shared accounts it allows a shared account to be abused and shared users to sell space with others from their account. to me if a users wants to add another domain then they get another shared account or a reseller account.


what about cpanel users who have paid for custom scripts to work that rely on public_html, these will then have to pay for these scripts to be changed.


So yes these changes will have issues for a lot of users as it seems only a minut few say they want this feature.

photo
2

"what about cpanel users who have paid for custom scripts to work that rely on public_html, these will then have to pay for these scripts to be changed."


Again, we won't be forcing existing accounts to change, so this won't be a problem.

photo
2

"some scripts will only work if in the main public_html of an account, so you will be telling users they cant use these scripts. dont ask me to name the scripts as their is many out their."


In 16 years of hosting, I've yet to find a 3rd party script that cares what folder it is installed in, only some that don't like being installed in the root of a domain, or some that don't like being in folders on a domain, but not a single one that cares if the folder it is installed in on the filesystem is called public_html. If someone has developed a script that relies on that, then they've created a broken system from the off, if they've paid for a script then they want to be asking for a refund.


Terry - You don't like multiple domains per account, we get it. Others do, this change will have no effect on you, but will bring many benefits to cPanel going forwards and those of us that do make use of multiple domains per account.


The simple solution of course is that cPanel just symlink public_html to the folder of what is considered the primary domain on the account for users that want to stay with the legacy way of working.

photo
1

it seems only 98 cpanel users want this, so then why not make it a feature that can be turned on or off, so it is not forced onto users that like the way the system is now.

just like the backup system has 2 options

photo
1

Terry Robertson said "i dont like the addon domain feature and have it set to 0 for all plans

as especially with shared accounts it allows a shared account to be

abused and shared users to sell space with others from their account. to

me if a users wants to add another domain then they get another shared

account or a reseller account."


I'm relatively new to cPanel but not programming. I've taught myself PHP and was delighted to discover cPanel after using a couple of other systems. In setting up 3 small websites on my account, the main thing I'd love to see changed was that the primary account could go into a sub directory, just like all the other domains, to produce a more structured and intuitive setup. With it, as it stands, I had to do much more jiggery pokery with error handling etc than I expected, much or all of which would disappear if the primary domain was in a sub directory. As somebody said further up, why treat one domain on the account any differently to the others?


I wouldn't call wanting to host a couple of sites from one account 'abuse'. My hosting company want 10x the price of a single domain to have a reseller account. For me that's out of the question. I already pay above the odds for hosting but thats the price of supporting local companies with predictable service.


So I for one will be delighted to see cPanel enabled to place all the domains into sub directories.

photo
1

""some scripts will only work if in the main public_html of an account" this is complete BS. Even if there are scripts using the public_html path in some way they should be rewritten. We can't just kill a very useful update in cPanel just because there's a potential case where people will get mad.

This is the same level of problems we had with PHP, it took *a really long time* for the community to wake up and decide that old stuff from PHP <5.4 needed to go.

photo
1

A lot of others bits and pieces rely on this being fixed and tie in to it, like multiple SSL support etc. and it saves maintaining a hack that should have died out 10 years ago.


The problem with making bits like this a selectable feature is you end up with two code forks as you need to make anything that depends on it work in two different ways.


The simplest way is to symlink public_html to the directory for the main domain, if it's done by default then I doubt you or your users would even notice - that way you have no problems with any hard coded scripts, and the mistakes of the past start to be erased and cPanel don't have old legacy code to support or two forks to maintain.

photo
1

@Karl I disagree with your symlink stand. This is a serious problem software should evolve, we should not hold ourselves to potentially insecure and old solutions just because someone might get hurt on an upgrade. Optional features are a problem as you said, it should be mandatory. cPanel really needs to be "fixed" there are a lot of underlaying basic problems like this one.

photo
1

Yes, but that doesn't mean it should break things outright for millions of existing users - it also doesn't mean such a symlink should live forever either. Yes it has been broken for a long time (who do you think kicked off these feature requests for fixing it? I've been on at them since at least 2004 to sort it), but that doesn't mean there shouldn't be a transition period for people to get their house in order.

photo
1

@Karl we're probably talking about hundreds not millions. Your symlink ideia is good, if it doesn't live for ever. Them problem is that we both know how the cPanel team works. They will just create the crappy symlink for every new account. Ideally this symlink situation could only be done for existing accounts, but the cPanel team will not had enough common sense for an implementation like this...


About "getting the house in order" why don't we just break it (by changing the public_html) folder and then tell people that they can fix it by creating a symlink themselves? I know most clients need to call tech support for this but I guess it's much more reasonable because it won't be creating any symlinks on the future...

photo
1

I think you're being a touch unfair to the guys/girls at cPanel. Things have changed a lot over the last 2-3 years, it's not the same attitude to development and the product that it was before then, it's very different now.


It's just a simple case of, don't add the symlink routine in to the code for the main account creation routine. Add it to a hook, but only on servers that pre-dated the new functionality. Sorted. That way if others want that functionality on new servers, they can put the hook in place themselves as well.

photo
1

The hook ideia is great. Let's see if they do it right (this time).

About my "unfairness":


  • Let's encrypt support: we've dozens of people asking for it, nothing happened in the past months. Why? There's 3rd party extension and a lot of examples on the forum on how to set it up. Any good sysadmin could do it in a few hours. What about the cPanel team? Not a single line of code on this;
  • CalDav / CardDav: it took years to get to this feature, however if you try to use it... I sucks, it's filled with bugs and issues (can't create groups for eg.) here and there. The "implementation" isn't even real, they took on the old horde to handle CalDav / CardDav. Horde shouldn't even be on cPanel in 2016, it's old and has issues. Why didn't they took a good implementation like Sabre/Dav and used it?


So, in what ways was I unfair? On delaying a simple UI change and a minor script or still maintaining horde on cPanel and forcing people to enable it to take advantage of CalDav/CardDav. Oh wait, almost forgot, when they *finally* "implemented" CalDav/CardDav it didn't work because the firewall profile (the default one) wasn't updated to include the ports that are needed for those services.

photo
photo
1

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.

photo
1

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.

photo
1

So, what the requestor (and many of us want) is that the concept of "primary domain" completely disappears, and all you have is domains - but as an initial step is to move the (current) primary domain to a sub-directory so you would have:


public_html/domain1.com

public_html/domain2.com

public_html/.... etc


Sure then you can debate if it should be actually called public_html, or just call it 'sites' or 'domains' instead, but hey, all can be fixed with symlinks (like www is a symlink to public_html)


The reason why this would make sense is because you don't mix files of different websites.

Sure you as a cPanel user can still change the document_root to become public_html/ if you want to for any domain, and in the ideal world changing it for the primary domain (which in the ideal world wouldn't exist).


I do believe that requiring a domain for a cPanel account is bad, in the end it's just a webspace, if you don't want to attach a domain to it it should be possible, and just use the username and password, and access your cPanel / FTP via the server hostname (maybe you run cPanel to offer FTP backup, so you suddenly don't care about the domain).


At some point I would like that domains are domains, you're not having a difference between main and addon domains, you add a domain and that should be it.

photo
1

this to me is fine. fits my second scenario..

photo
photo
4

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.

photo
1

Good point! - having a public_html (or www, whatever people prefer), per domain could indeed be nice specially because of laravel/symfony and just the possibility to have stuff outside your webroot but still being separated into each domains own directory.

photo
1

Seem redundant this way to me.. no real need for multiple public_html imho.. but I would be open

photo
photo
1

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.

photo
1

Location doesn't really matter - and how many actually uses Hsphere still?

There's also the way many other systems does it, which is basically having sites/ or domains/ or anything - it's just a directory name.

photo
1

Hsphere. Is that even available. Didn't Parallels buy them is there a new version out?

photo
1

The public_html confuses most people, it's a legacy of the past.

photo
photo
1

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

photo
1

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)

photo
1

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.

photo
1

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.

photo
1

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).

photo
3

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.

photo
3

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.

photo
1

Thanks for the thoughts, but our research is showing this to be much bigger than just adjusting the templates, unfortunately. There are lots of different parts of the code that take for granted the path of the primary domain, which makes this particular feature too much of a wild card to easily pick up at this point. We would love to be able to implement it, though! Hopefully we'll be able to take another look at it soon.

photo
1

The amount of changes needed to make cPanel a bit suitable for application hosting are irrelevant to the importance of it right? In my opinion cPanel is not serving the power users well enough here, resulting in them leaving cPanel because configuring boxes for application hosting involves way too much config file hacking.

photo
photo
1

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.

photo
1

Our customers just symlink their public_html directory to the application's public directory.


So, for example with Laravel, their home directory looks like this:


/website

/website/app

/website/public

/public_html => /website/public

photo
1

Why would they mess about like that? It's a simple .htaccess fix to send traffic to Laravels public folder or Symfony's web folder Yes you can argue that Apache's processing of .htaccess may break and expose the other folders - but chances are if Apache's .htaccess processing is broken, you've got way bigger issues to worry about.

photo
1

We also have a combination of ~80 aliases / addon domains / subdomains for serving four code bases. Involved quite some hacking to keep all of them maintainable, not even to mention making ENV parameters available to them.

photo
photo
2

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.

photo
1

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!

photo
2

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!

photo
3

We definitely agree that we'd like to get it resolved! It hasn't been assigned to a version yet, but we're working toward this adjustment!

photo