Why is an addon domain connected to a subdomain?

The process of adding an addon domain involves the creation of the corresponding subdomain. In terms of Apache VirtualHost entries, an addon is a parked domain on that subdomain.

There is no way to add an addon without a subdomain being created, this is the fundamental principle of cPanel architecture. Nevertheless, it is a common desire to make the links - addon.maindomain.com and maindomain.com/addon unavailable.

 solution


Setting Up a 301 Redirect

Instead of having to bother with a plethora of settings in cPanel itself, I came up with the following to stick at the top of .htaccess. A quick look around on the Internet brought up Fayaz Miraz’s blog, but while the solution suggestion was close, it misses one crucial aspect: it only redirects from the main page as far as I can tell. This is fixed easily by the addition of $1 (i.e. everything that was added after the main page).

<IfModule mod_rewrite.c>
RewriteEngine On

RewriteCond %{HTTP_HOST} !^example\.com$
RewriteRule ^(.*)$ http://example.com/$1 [R=301,L]

</IfModule>

Simply put, it matches all possible routes of approach (whether through www or through a subdomain of another domain) and if it’s not example.com, it will 301 redirect to example.com. The L means no further rewriting will occur after that rule. Mostly because it would just be inefficient, and partially because something else further down the line might mess things up.
Preventing .htaccess Hell

Another problem is that cPanel automatically creates a /public_html/addondomain directory. This is bad, because /public_html already contains a .htaccess file for the main domain. When accessing /public_html/addondomain, it would first parse the .htaccess file in /public_html before moving on and overriding it in /public_html/addondomain, and that’s assuming none of the rules in /public_html make anything go awry!

To prevent this kind of nightmare from occurring I took the simple precaution of creating a new directory /domains. This domain is contained in /domains/example.com, for instance, and any other add-on or subdomains can reside in their own /domains/domain.com directory to prevent any added load from needlessly parsing .htaccess files.

Was this answer helpful? 0 Users Found This Useful (4 Votes)