cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Go to solution
Helper III
Helper III

Solution: Primary Domain in Sub-folder

NOTE:  Read all instructions!!!

Please backup your database and files BEFORE attempting this solution in case you need to restore.  The solution works if you cover all points.

 

Sub-folders

If only GoDaddy would allow you to install your primary domain in a sub-folder rather then in the root directory for cPanel hosting accounts…  You crave organization but have a mess. 

 

Business Hosting

Well there is one solution that works with Business Hosting (cPanel).  The solution should also work with Shared Hosting (cPanel) but has not been confirmed.

 

WordPress Websites

The solution is designed for WordPress websites; however I see no reason the redirect method should not work with any type of website.  The redirect logic is the same.

 

Giving WordPress its Own Directory
Recommended method by WordPress.
https://wordpress.org/support/article/giving-wordpress-its-own-directory/

  1. Install WordPress in the root directory of your primary domain used to setup the cPanel account
  2. Copy all files WordPress installed in the root directory to your new sub-folder
    /domain.com
  3. Recommend using cPanels File Manager to copy, rather than FTP for these reasons:
    1. Ten times quicker
    2. All files are copied (FTP can fail to upload)
    3. File permissions are retained correctly
  4. Place the following new .htaccess file in the root directory
  5. The new .htaccess file then automatically redirects all queries for the primary domain to the new sub-folder, without any change in website URL structure, just like magic
  6. For safety keep a copy of the original root directory files in a backup folder in case you need to revert the move

 

# REDIRECT WORDPRESS FROM ROOT TO SUB-FOLDER
<IfModule mod_rewrite.c>
RewriteCond %{HTTP_HOST} ^(www.)?domain.com$
RewriteCond %{REQUEST_URI} !^/domain.com/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /domain.com/$1
RewriteCond %{HTTP_HOST} ^(www.)?domain.com$
RewriteRule ^(/)?$ domain.com/index.php [L]
</IfModule>

 

 

You have your primary domain now living in a sub-folder and behaving just how it used to when living in the root folder. 

 

Google Analytics

Google analytics sees and reports the URLs just the same as they always were.

 

WordPress Admin Login Redirect Loop

This was the hardest problem to figure out.  When logging into WordPress administrator using:  www.domain.com/wp-admin

 

If you use the wp-admin.php administrator login URL, you entered an endless redirection loop, where the username & password were asked for over and over. 

 

The problem was the new .htaccess redirect rules were adding the sub-folder address to the login URL causing the looping. 

 

There are two solutions:

  1. Use wp-login.php instead of wp-admin then there are no redirects it just works

   www.domain.com/wp-login

 

  1. Modify the new .htaccess file to include some additional rewrite logic, that puts things back to how things used to work, removing the sub-folder from the URL
  2. The new rules in the .htaccess conditions must come above the other rules or it won’t work

 

# REDIRECT WORDPRESS WP-ADMIN TO ROOT DOMAIN (STRIPS OUT SUB-FOLDER FROM URL ON LOGIN REDIRECT)
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www.domain.com$ [OR]
RewriteCond %{HTTP_HOST} ^domain.com$
RewriteRule ^wp-admin$ "https\:\/\/www\.domain\.com\/wp-login\.php\?redirect_to=https\:\/\/www\.domain\.com\/wp-admin\/&reauth=1" [R=301,L]

# REDIRECT WORDPRESS FROM ROOT TO SUB-FOLDER
RewriteCond %{HTTP_HOST} ^(www.)?domain.com$
RewriteCond %{REQUEST_URI} !^/domain.com/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /domain.com/$1
RewriteCond %{HTTP_HOST} ^(www.)?domain.com$
RewriteRule ^(/)?$ domain.com/index.php [L]
</IfModule>

 

Sub-folder Permissions

 

Add-on domain sub-folders are normally automatically given the file access permissions of 0750


For example:

/anothersite1.com  -  0750
/anothersite2.com  -  0750
/anothersite3.com  -  0750

 

When you manually create the new sub-folder for the primary domain it needs different permissions to work.  Use cPanel’s File Manager to set these permissions easily.

 

/domain.com  -  0755

 

Without the extra global access permissions, the apache server blocks access to the files, throwing a browser access permission denied error. 

 

Inside of the sub-folder the WordPress files retain their original reduced access permissions, usually 0644 settings, just leave them as they were.

 

Things to Watch

After the move, some of my plugins had problems.

 

W3Total Cache

Needed all caches purged from within the plugin plus the cache folder physically deleted to clear things properly.

 

/domain.com/wp-content/cache  (delete this cache folder)

 

Reinstalled the plugin for good measure.  The plugin settings were kept alive in the folder and automatically repopulated:

 

/domain/wp-content/w3tc-config

 

To be safe you should also export your settings, using W3Total Cache export, before uninstalling the plugin, so you can import them again after the reinstall if they don’t automatically repopulate.

 

Rebuilding the cache inside W3Total Cache, then allowed for all pages to then be displayed correctly.

 

WordFence

Edit user.ini in the new /domain.com sub-directory, adding in the new location to your home directory path.  Where xxxxxxxxxx is your unique home directory name shown inside cPanel.

 

 

; Wordfence WAF
auto_prepend_file = '/home/xxxxxxxxxxx/public_html/domain.com/wordfence-waf.php'; END Wordfence WAF

 

 

Without this change WordFence will fail to load wordfence-waf.php so the firewall will not activate and work.

 

WordFence also said it did not have privileges to write to a couple of its log files:

 /domain.com/wp-content/wflogs

 

Reinstalling the plugin fixed this directory permissions issue.

 

Installatron

If you installed WordPress using Installatron, the install directory location is now wrong (behind the scenes).  To avoid any future update issues, I disassociated the WordPress install from Installatron control under its advanced settings.

 

Then edited /domain.com/wp-config.php   /*commenting out*/   Installatron’s update control entry.

 

 

/* define('AUTOMATIC_UPDATER_DISABLED', true); */

 

 

WordPress then updates on its own as needed, minor versions.  This wp-config.php entry had previously disabled WordPress from updating itself when Installatron took care of all updates.

 

Clone

Installatron did recommend using its built-in advanced clone feature to move the database from one folder to another but I did not try that method.  This likely would work, just as well as a manual file move, plus keep Installatron in charge of updating WordPress, if that’s what you want.

 

Works Like Magic

After moving the files, setting permissions, fixing the plugins and creating the new .htaccess file in the root directory, then everything works like magic, just how it always did.

 

End Result

Let’s say you setup the cPanel account using a primary domain you owned called domain.com installed in the root directory “/”.

 

Then you added a bunch of add-on domains:
anothersite1.com
anothersite2.com
anothersite3.com

 

These live-in sub-directories off the root directory.

Sub-directories:
/anothersite1.com
/anothersite2.com
/anothersite3.com

 

Now you can have the primary domain into a sub-directory and your organizational life is good.

 

Sub-directories:
/domain.com
/anothersite1.com
/anothersite2.com
/anothersite3.com

 

Please remember this move is done at your own risk and I doubt supported officially by GoDaddy.  Please backup before attempting and be careful.

 

Hope this helps someone. 

 

Aly 😊

1 ACCEPTED SOLUTION
Helper III
Helper III

Cron Jobs - Sub-folder

If you have any cron jobs configured using cPanel Cron Jobs (crontab) and these referenced the folder where the primary domain used to live, you need to update the cron job to reflect the new sub-folder location.

 

For example:

Original Root Location

usr/local/bin/php -q /home/xxxxxxxxxxx/public_html/wp-cron.php

New Sub-folder Location (/domain.com)

usr/local/bin/php -q /home/xxxxxxxxxxx/public_html/domain.com/wp-cron.php

 

Manual Cron Jobs

The above cron job manually fires the WordPress internal wp-cron.php queue.  Just add in your new sub-folder to the cron job after moving the primary domain's location.

 

Disabling Automatic Cron Jobs

You might use such a cron job if you have disabled the WordPress wp-cron from automatically running whenever a visitor hits the website, the default WordPress behavior. 

 

The wp-cron is now manually called via the cPanel cron job, precisely controlling when its run. The benefit being if you have a heavily trafficked website to reduce and better control server load timing.

 

define('DISABLE_WP_CRON', 'true');

 

Cron Job - WGET

Alternatively if you use a command such as WGET to externally fire the job (via the URL), then nothing needs to change as the public URL structure hasn't altered with the sub-folder move.

 

wget -q -O /dev/null http://www.domain.com/wp-cron.php

 

Hopefully that's everything you need to cover.

 

Aly 🙂

View solution in original post

3 REPLIES 3
Helper III
Helper III

Just a couple of extra thoughts when moving domains.

 

Firewall / CDN (Sucuri)

Putting the primary domain into a sub-folder causes no issues with Sucuri's firewall and CDN (Content Delivery Network) as the IP address of the cPanel hosting server does not change.  So nothing to do here, the moved primary domain works as normal with the firewall & CDN.

 

Cascade Benefits (.htaccess)

There are some benefits for placing every domain in its own sub-folder, due to how .htaccess rules typically cascade rule settings down from a higher level folder/directory into a lower sub-folder/sub-directory.  How cascading works depends on how the server policy is setup.  With shared hosting you have no control of server policy.

 

Separate Rules / No Cascade

Once you put every domain into its own sub-folder then any issues caused by cascading are removed.  You can set the rules you want for every domain in an individual .htaccess file in that domains sub-folder.  With each sub-folder not effecting any other sub-folder rules.

 

/  -  .htaccess   (rules can cascade downwards to sub-folders)

/anothersite1  -  .htaccess   (own set of rules)

/anothersite2  -  .htaccess   (own set of rules)

/anothersite3  -  .htaccess   (own set of rules)

 

Header Example

One problem I had encountered was in setting headers for my root installed domain.

 

If you use an appended header value, it could compound (add together) underneath.  In this case the value SAMEORIGIN would duplicate for another website in another sub-folder, if that value was set again.  One workaround was to unset the header then reset the header in the sub-folder but it was not an elegant solution.

 

Duplicate header values can cause web browsers problems so are discouraged.  This is just an example, you don't have to add these to your website .htaccess file.

 

# START - SECURITY HEADERS
<IfModule mod_headers.c>
	Header always unset "X-Powered-By"
	Header set X-Content-Type-Options nosniff
	Header set X-XSS-Protection "1; mode=block"
	Header always append X-Frame-Options SAMEORIGIN
	Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS
	Header always set Content-Security-Policy "upgrade-insecure-requests;"
	Header always set Referrer-Policy: "no-referrer-when-downgrade"
</IfModule>
# END - SECURITY HEADERS

 

A great place to see your website header is this website https://securityheaders.com/ you can use them to improve your website's security.

 

Cascading Can Work

Sometimes cascading of rules can be to your advantage but I found it was causing problems when setting headers.

 

Aly 🙂

SSL Certificates

SSL certificates are fine as well, they don't need to be re-keyed as the domain they are associated with has not changed.

 

Clear Sucuri's Cache

Forgot to mention you may need to clear Sucuri's cache after the move.

Helper III
Helper III

Cron Jobs - Sub-folder

If you have any cron jobs configured using cPanel Cron Jobs (crontab) and these referenced the folder where the primary domain used to live, you need to update the cron job to reflect the new sub-folder location.

 

For example:

Original Root Location

usr/local/bin/php -q /home/xxxxxxxxxxx/public_html/wp-cron.php

New Sub-folder Location (/domain.com)

usr/local/bin/php -q /home/xxxxxxxxxxx/public_html/domain.com/wp-cron.php

 

Manual Cron Jobs

The above cron job manually fires the WordPress internal wp-cron.php queue.  Just add in your new sub-folder to the cron job after moving the primary domain's location.

 

Disabling Automatic Cron Jobs

You might use such a cron job if you have disabled the WordPress wp-cron from automatically running whenever a visitor hits the website, the default WordPress behavior. 

 

The wp-cron is now manually called via the cPanel cron job, precisely controlling when its run. The benefit being if you have a heavily trafficked website to reduce and better control server load timing.

 

define('DISABLE_WP_CRON', 'true');

 

Cron Job - WGET

Alternatively if you use a command such as WGET to externally fire the job (via the URL), then nothing needs to change as the public URL structure hasn't altered with the sub-folder move.

 

wget -q -O /dev/null http://www.domain.com/wp-cron.php

 

Hopefully that's everything you need to cover.

 

Aly 🙂

View solution in original post