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

skeleton directory for addon and sub domains

Nathan Lierbo shared this idea 8 years ago
Open Discussion

Whenever a hosting customer creates a subdomain or addon domain, a plethora of errors appear in the Apache error logs because favicon.ico, robots.txt and 404.shtml do not exist by default. This causes an unnnecessarily large error log file even with custom logging.


Since hosting providers solve this issue for primary domains by using skeleton directories, it is proposed that we use that same skeleton directory for addon and sub domains. This lets hosting providers just solve these problems or go a step further with a "Website coming soon, here's how you upload" page and other brandings they build.


There is no need to have a separate skeleton directory for this, so let's use the same skeleton directory used for that account (the skeleton directory of the reseller/root user that owns that account).


The strong reasoning used for justifying skeleton directories in the first place is being used here for justiifying sekeleton directories for addon domains and subdomains.


Original thread: http://forums.cpanel.net/f145/case-48382-skeleton-directory-addon-sub-domains-146569.html

Comments (6)

photo
1

The sooner the better, on busy servers it generate loads of unnecessary errors.

photo
2

Yes, that's a must!

Please cPanel, do consider and implement this.

Any chance we could get it any time soon? When?

Thanks,

photo
1

We are starting development on a feature we've provisionally called 'Starter Sites' which provides the means for end-users to create, well, starter sites from site templates. If these Site Templates include template favicon.ico, robots.txt and 404.shtml files... in addition to template index.html files and the related IMG, CSS or JS assets...would that resolve the problem for you?

photo
1

It would only help IF the customer, after adding the Add-on domain, then proceeded to use the new Starter Site feature. So, it will help in some cases. The real solution, though, is to simply use the same hook that Create Account uses to fill the main public_html with skeleton files... to fill the new Add-on / Sub Directory with the same skeleton files (perhaps it would check to be sure that matching files don't exist... so it doesn't overwrite anything existing).

photo
1

As a thought...we could create a 'Default Site Template' to be rendered into all new Add-on domain or Subdomains only at the moment of creation. That would, in effect, be the equivalent of a skeleton directory in behavior. Additionally this 'Default Site Template' would be configurable by resellers or root in the same way other Site Templates would be.

photo
1

Agreed... although you already have a "Default Site Template" -- it is called the Directory Skeleton. I'd highly suggest just using what exists already. Just tweak it so it's used not only for Create Account, but also for Create Add-on and Create Subdomain. My two cents. :-)

photo
1

The directory skeleton ( /root/cpanel3-skel ) applies to the home-directories of new accounts. It currently contains the public_html and public_ftp directories and only applies when new accounts are created. I'm not sure changes or iterations of this directory would be the most appropriate for Starter Sites since we're talking about domains specifically...rather than the whole Account.


Other than the primary domain, add-on or subdomains aren't guaranteed to exist at the moment the Account is created. We'll need to use a different mechanism than /root/cpanel3-skel because of that.


All that being said, we will certainly respect this directory and whatever contents customers put in it on account creation. Nothing should change there.

photo
4

Hi Adam. In my opinion, this feature request doesn't really have anything to do with the upcoming Starter Sites feature. We may need to carry this over to a new thread or feature request. The feature request at hand is simply asking for the ability to put some files into any Apache root directory, so that our logs don't fill up with 404's on robots.txt, favicon.ico... and it also gives hosting providers an opportunity to "brand" any new site with a "coming soon" page. We can do this today with brand new cPanel hosting accounts, since putting skeleton files into public_html is part of the new account script. We are asking for cPanel to extend this functionality to Add-on Domains and Sub-Domains.

photo
photo
1

Any update on this? Just got started using cPanel and this is something we'd really like to see. Seems like it would be an easy fix.

photo
1

This has also caused issues for us with .htaccess. When a user already has an install of software in public_html that has mod-rewrite rules, depending on the ruleset (I've noticed not all software does this but a popular package with our client base does) subfolders will throw a 500 error if they don't have their own .htaccess file with RewriteEngine On.

photo
2

I simply want my custom skel files from /root/cpanel3-skel (I have a set including custom index.html , blank robots.txt , generic favicons, and my custom 400.shtml thru 500.shtml files) to be automatically populated into any Addon Domains that user's create, just like it does for the public_html when I create a new hosting account. Will this ever become possible cPanel?

photo
1

There's very little likelihood this would get picked up without significant community pressure since this is achievable with the use of standard hooks. We might potentially put together a guide on how to achieve this functionality specifically, but we haven't yet. If that happens, we'll be sure to share a link here!

photo
2

I'm waiting with baited breath for the link/guide. :-)

photo
2

I too would really appreciate a guide, as I'm not a developer and have never done anything with standard or custom hooks. I tend to avoid attempting to customize cPanel functions (the "if not broken, don't fix" mindset) for fear that I might make a mistake. Thank you for the response Benny.

photo