Transfer the site to an own domain
Written 3 years 20 weeks ago by SharmWeb. Last edit 1 year 1 day ago.
Drupal website development often gets done on a subdomain. When we want a site to go live on it's own domain, basicly we have three options. The preferred option is keeping it running under the Drupal installation you made it under. You might have special settings, made tweaks to modules and simply know that this one is working well. It's a common mistake to think an own domain name has to run under another Drupal installation. You can simply rename the directory name of your "prototype" proposal and off you go (method 1).
If you experiment a lot on the Drupal installation you made your proposal on, you might prefer to setup a seperate installation but leaving it on the same hosting account (method 2). You risk less this way and copying files is very quick using the file manager from the cPanel on the server.
In other cases you might prefer to put the new site on another hosting account. It might be the client already has an existing website at another host or your existing account is simply full (method 3).
Method 1: Transfering a sub-domain to an own domain leaving it under the same Drupal installation.
Method 2:Transfering a sub-domain to another Drupal installation, but on the same hosting account.
Make sure that from the start it's clear to your customer this option costs something extra and has some disadvantages:
Published in
- Printer-friendly version
- 128 reads
Drupal website development often gets done on a subdomain. When we want a site to go live on it's own domain, basicly we have three options. The preferred option is keeping it running under the Drupal installation you made it under. You might have special settings, made tweaks to modules and simply know that this one is working well. It's a common mistake to think an own domain name has to run under another Drupal installation. You can simply rename the directory name of your "prototype" proposal and off you go (method 1).If you experiment a lot on the Drupal installation you made your proposal on, you might prefer to setup a seperate installation but leaving it on the same hosting account (method 2). You risk less this way and copying files is very quick using the file manager from the cPanel on the server.
In other cases you might prefer to put the new site on another hosting account. It might be the client already has an existing website at another host or your existing account is simply full (method 3).
Method 1: Transfering a sub-domain to an own domain leaving it under the same Drupal installation.
- Register a domain and assign it to cPanel as an Addon domain with the domain manager. Point it to the same folder of the Drupal installation the subdomain is working under. This is an existing folder, not the new one that gets proposed by default, based on the domain name.
- Copy the subdomain folder (the one that also contains settings.php and the files folder) somewhere else, rename it to the same name as the domain name you created before, and move it back. The original subdomain folder has to stay intact. It might contain images or other files that are in an absolute path somewhere on the new site.
- Try the new domain in your browser. If gives you the main Drupal installation website instead of the right one, check if the settings.php file is present. It might not have been copied due to permissions (set to 644 temporarily).
- Now. Set up a redirect through the cPanel Option. The subdomain (with AND without www) should redirect to the new domain (with OR without www). Check the wildcard option.
- What you just did, modified the htaccess file of the Drupal installation. Open it with the cPanel editor and you'll see it added a set of Rewrite rules to the bottom. If you leave it like that you'll see that except for the home page, it will put index.php behind every path, leading to a Page Not Found message.
- Remove index.php from one of the last lines of the original file: RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
Add some backslashes and slashes \/:
RewriteCond %{HTTP_HOST} ^www.newdomain.com$
RewriteRule ^(.*)$ "http\:\/\/newdomain\.com\/$1" [R=301,L]
RewriteCond %{HTTP_HOST} ^sub.domain.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.sub.domain.com$
RewriteRule ^(.*)$ "http\:\/\/newdomain\.com\/$1" [R=301,L]
- Register a domain and assign it to cPanel as an Addon domain with the domain manager.
- Make a copy of the database first in gzip format with phpMyAdmin.
- Create a Drupal installation with SimpleScripts.
- Copy all directories from /sites in subdomain to /sites in the new domain. You might have to change permissions temporarily of either the directory being copied or the directory to copy to.
- Copy the php.ini file to the root of the new domain. Check the PHP memory limit in the Drupal status report.
- Check also if clean URLs are supported in the Site configuration options.
- Open pphpMyAdmin and drop all the tables in the relevant database of the new site. Before doing so, check well the database name in the new settings.php file. Make also sure the database prefix is set like in the sub-domain settings file (probably no prefix: $db_prefix = '';). Change permissions before and after making any changes. Drop only the tables (check all at the bottom), but not the database itself.
- Import the gzip file and be patient. Some tool like Netmeter to see your upload activity can be useful to verify progress.
- Run yoursite.com/update.php
- Test the new site. If no absolute URLs where used in the sub-domain, everything should be fine. If not manual correction should be made.
- Enable the themes that where active before.
- Check if clean URLs is enabled.
- Activate the secure site module on the old sub-domain and set permissions and configuration. This way it will not be found by the search engines and avoids being penalized for having duplicates on the same server. If development takes a longer time span, you can even decide do do this in an earlier stage.
Make sure that from the start it's clear to your customer this option costs something extra and has some disadvantages:
- Drupal and it's modules have to be updated seperately. All seperate maintenance means extra work. Updating, backups, fixing bugs, etc. can only be offered at low cost or even free of charge, included in the service, if more websites share one common Drupal installation.
- The cost of the hosting account is not shared with others. 99 out of 100 websites use only a fraction of the available resources of an account. Sharing isn't problematic. Make sure your customer is the owner of the website domain name. That can take away some psycological barriers.
- The cost of some scripts can be divided if shared. Extra services can be offered easier.
- Set up a Drupal installation on the new account of the same version as the one you have your proposal site running under. Recommended is the use of Simple Scripts (if not available Fantastico). This makes upgrading the site later easier, although not necessary.
- Copy the existing directories under the "sites" directory to the new one. Sometimes permissions on the new directories have to be changed (755) temporarily. If you move directories on the same account the Legacy File Manager might work better than the normal File Manager. The directories are "files", "modules" and "themes". Personally I have an extra directory "plugins" for any third party non-Drupal scripts.
- Many of the elements that apply on updating, apply also here. Savest is always to disable all modules before transfering and go to a standard theme. Leave the original proposal site intact for the time being. You never know. So copy instead of moving.
- Export the database in PHPmyAdmin (I prefer gzip format). Import it in the new installation.



