Changing Document Root for main domain
I tried to follow the below article last week to change the main domains doc root but ran into problems when adding the new domain. It said that `The system could not find an IP address. Add IP addresses to this server under the Add a New IP Address heading.` However all WHM servers I run upon checking none of them have an IP where they say you should have one.
Additionally when I changed the primary domain to a placeholder domain, such as placeholder01.tld it changed all of the sub domains under that domain. The instructions do not say anything about that and also do not instruct you to change the domain back to fix this issue.
Is changing doc root on main domain a problem now?
-
Hey there! Changing the document for the main domain has always involved either modifying and restoring the account (the safe option) or the more dangerous option of manually editing several different files on the command line. Because of the risks involved with that manual procedure we have removed those instructions - if the operation isn't performed properly it can keep Apache from starting.
Can you confirm you tried this work on a version 120 machine?
0 -
Hi cPRex, I have only tried this on v110.0.39. I never got it to work though as it said my system does not have an IP which is confusing. Though the documentation(safe option) does seem incomplete by not telling you to either change the primary domain back or fix the broken sub domains. luckily when I changed it back after it failed my sub domains were restored.
With the documentation lacking this part I am reluctant to try it on a new server as we have a lot of subdomains with client apps on
0 -
Let me do some testing with this today and I'll send you an update once I have more details.
0 -
Alright - I confirmed the steps in that article will change all subdomains associated with that main domain. Since that is the case, I have removed this article.
Like I mentioned before, this can only be done by adjusting the cPanel configuration files directly on the command line, which is why we don't provide these steps.
0 -
This is a frustrating situation because I can no longer use my main domain. We recently moved from WordPress to Laravel, where the document root is within the "public" directory of the main app folder. To use
public_htmlon our main company's domain, I would need to move all of Laravel's files into the user account folder and figure out how to change Laravel's document root topublic_html.Not only would this create a mess in the user account folder, but managing a GitHub repository in that folder would also be incredibly awkward.
Is there no way for me to find out how to do this with CLI?
0 -
Unfortunately I don't have any details I can provide on this one. I know this doesn't help you right now with this issue, but I would recommend submitting a feature request over at features.cpanel.net requesting and easy way to perform that docroot change. I'll be sure that gets in front of the right team for review.
0 -
Hi cPRex,
I have sent in a feature request. Though I forgot to mention the SEO implications of this particular case.
We had to redirect everything from the main domain to a subdomain. The main domain has been registered and indexed for almost 30 years and now we've done a permanent 301 redirect on everything. it's saddening.
0 -
I did see the request come in and we'll likely talk it about it in today's meeting!
0 -
So...this was a fun discussion - and sorry for not updating on Friday.
In general, cPanel is sloooooowwwwwly trying to remove and change the concept of a domain as defined in the cPanel system. For decades we've had parks and addons and aliases and subdomains, but they were all tied to a "main" account, which leads to confusion and difficulty whenever someone wants to split these to their own account.
The cPanel team leader is working to change this (slowly, like I mentioned...it's integrated into every area of the product) and he's added this to his case of things that need to get handled as part of the change.
So far now, there isn't going to be an easy fix, but this will be part of a larger change that will happen in the future.
0 -
I'm uncertain about the future of domains within cPanel accounts based on what you've mentioned, but for now, it would be ideal to restore our main domain. It's essential that the primary company website is hosted on the main domain rather than a subdomain. Any pointers to the proper way to do this?
0 -
I wouldn't have any details on that - it would be best to make a ticket so this can be investigated and data loss avoided.
0 -
How do I create an account and not have public_html as the document root?
I did this a few months ago, and I had to overtype my original domain which I set the account up with. Now my main account has a false domain as the main domain and a new domain, so that it works.
The create an account flow is flawed unless you want public_html as your doc root?
I have a new domain and want to get this right.0 -
Ben Taylor - for the main cPanel account, you don't - it is assumed that the main domain will always be in public_html.
You do have the ability to create addon domains outside of public_html if the "Restrict document roots to public_html" option is turned Off in WHM >> Tweak Settings.
0 -
cPRex Ok. If I am creating an account that will have one domain, and that cannot be public_html, what is the best procedure?
What is the main domain anyway? The last account I created has this god awful dummy domain labeled as the Main Domain, so it all looks a bit messy.x (x)0 -
Better question - what is the specific problem you're trying to solve by not having a domain use public_html?
0 -
Just like I answered you 9 months ago....
To usepublic_htmlon my main domain, I would need to move all of Laravel's files into the user account folder and figure out how to change Laravel's document root topublic_html. This would break the use of GIT as the user directory would be part of the git repo. But, I think you know all of this already.
I really need to create an account now. I have had this domain and an application ready for it.x (x)0 -
This doesn't seem like a cPanel issue, but an easy workaround would be this:
-create a fake domain as the cPanel account. It should probably still resolve on the internet, though
-create your "real" domain as an addon domain under cPanel, and then you can make the document root just /home/username/some-other-folder instead of /home/userame/public_html.Would that work?
0 -
Of course, it would work. It is just ugly and makes no sense. This was the whole point of asking the question. It seems that cPanel, by taking away the ability to change the doc root of the main domain, has left holes in the documentation that specifies what you just said and left out anyone who does not want their user directory in a GitHub repo.
x (x)0 -
Unfortunately that's the only option I have as cPanel (and most other hosting tools) have traditionally used that directory.
You could always create a feature request at features.cpanel.net and I can bring this up with the team to see if that's something they would want to change in the future.
0 -
I'm going to leave this here as my final comment, because I think it matters for others searching for answers:
The ability to change the document root of the main domain used to be supported, even if buried. It was removed, not just deprecated, but the documentation pulled with no direct replacement.
The workaround is to create a dummy domain as the account's main domain, and then use the real domain as an addon pointing to your actual app folder. But this is ugly, confusing for SEO and client accounts, and feels like a hack.
I understand there are technical reasons tied to legacy architecture, and possibly future plans to restructure domain handling or monetize addon domains. But it's disappointing that instead of providing clear documentation and options, this functionality was quietly removed.
If you're a developer or agency relying on modern frameworks like Laravel, where public/ is the web root, you're stuck choosing between an awkward workaround or migrating off cPanel entirely.
Hopefully this saves someone else months of back-and-forth.
x (x)0 -
I created a placeholder domain (fakedomain.com) on a new account and then added the actual domain I intended to use.
When I added the new domain, the system unexpectedly created a subdomain, which has never happened before in my previous setups. Since then, I've been unable to get AutoSSL to function correctly, possibly because fakedomain.com does not resolve.
In a previous account, I was able to follow the same process without any issues, and AutoSSL worked as expected. However, on this new account, no matter what I try, AutoSSL continues to fail.
I attempted to resolve the issue by deleting the addon domain and changing the main domain to the real one. After doing that, the domain started resolving to another domain on my account, and AutoSSL still didn’t work. I reverted back to the placeholder domain, but the original issues persist.
Has the ability to configure domains this way been removed or changed recently? It seems like this workflow no longer functions as it did previously.
0 -
Creating an addon domain has always created an additional sub.maindomain.com entry, so that isn't new behavior.
I really think there has to be an easier way to configure this on the main domain like a normal website.
0 -
I really think there has to be an easier way to configure this on the main domain like a normal website.
There "was" a way to do this. Why do I get the impression you don't think there was? All my older domains have a Laravel install and public set as the main domain doc root. This feature was taken away.
x (x)0 -
A few points of clarification are needed, I suppose.
The first, is that there really wasn't ever a supported way to do this from within the cPanel interface. The original instructions you linked ended up causing issues for so many users that we removed them.
It's also worth noting that even with an addon domain with a custom document root you still have to use /home/username/some-directory - it can't just be /home/username
What I was implying was that there has to be a way in your file structure to change the document root so it works with public_html, but there isn't going to be a way to workaround this on the cPanel side.
0 -
I don't know who is behind cPRex, and I guess it is multiple people. The instructions I linked are newer than the actual cPanel setting, where you could change the doc root for the main domain just as you can now with an addon domain. I used to create an account with my intended domain (like a normal person would), then simply go to the domain settings and change the doc root. This used to be a feature within the cPanel user interface, and that is a fact. Maybe you (the person behind cPRex right now) did not work for them back then? I have no idea. But you are obviously unaware that this feature was there and was taken away.
x (x)0 -
cPRex really is just one guy that's been cPaneling for 18 years now :D
0 -
cPRex really is just one guy that's been cPaneling for 18 years now :D
Since 2007, and you imply that there was never a feature to change the doc root on the main domain in the cPanel interface? I last used the "change document root of the main domain" in 2018 when I registered a record label. It is there in my account. Main domain, document root is set to public_html/public
0 -
We're just going in circles here and missing the core issue. If you'd like to see this happen in the product, please make a feature request over at features.cpanel.net and I'll bring it up with the team. For now, there is a workaround available that we've talked about, but ultimately it would be best to fix your code/tool to work with the cPanel document root system.
0
Please sign in to leave a comment.
Comments
28 comments