Get the Files Ready

Before transferring anything, make a master copy of the site. ZIP up and store the exact version of the drupal directory that you send across.

At the moment, the target URL for the Drupal index page will be T

something like: http://www.domain_name.com/drupal/. If you want it to be http://www.domain_name.com/, then ZIP the les without the parent directory so that les are extracted directly to the public_html folder on the live site. I

While we are on the subject, you may as well clean up the Drupal le system properly, so that you don't end up saving erroneous les.

Access your site from a browser and perform the following four important tasks:

1. Disable all caching and clear all caches—hopefully, these haven't been enabled during development anyway.

2. Disable clean URLs - in case the new server isn't set up correctly. You can enable it later.

3. Set any logging options (such as database logging) to small values and run cron—to clear out old log les that are no longer needed and cut down on transfer size.

4. Remove redundant posts—try not to transfer over a whole lot of stuff that will be deleted anyway.

Next, focus on the actual le system. If you're like me, then you probably create backups of all the modified les as you work. As far as Windows machines go, these are denoted by . bak, and placed in the same folder as the original file. Make a backup of your drupal folder before deleting anything, just to be safe. Then, remove all backup les from the drupal folders.

Deployment

While it might seem a bit excessive to do this at the moment, there are a couple of good reasons for it. First, having any sort of unused les lying around on your host le system is poor security practice. Second, why clutter up a brand-new installation with les you don't need? Working on a lot of les over the course of the development phase, adding and removing functionality, and so on, adds a lot of unnecessary size to the upload if you don't trim away what isn't needed.

Now, open up the configuration file, settings .php, and remove the username and password. The current database name and password will change to the ones set when you created a new database on the host, but there is no point in transferring any type of sensitive information like this—especially because people often prefer to use the same username and password for a variety of things.

Once this is done, you have to wait until the next section to add one more le, and you can then make a master, zipped copy of your Drupal site—call it RTP (Release to Public) or something similar to distinguish it from other versions.

If you are working on a Linux box, you can tar and gzip your les instead—doing so will help with the upload time. If you are developing on Windows, then you might want to make sure that your host can unzip . z ip les because they will more than likely be using a Linux server—there shouldn't be a problem, however. In the unlikely event that there is, the best thing to do is download and install a gzip utility for Windows at http://www .gzip. org/, which you can then use to ZIP up les in the . gz format.

0 0

Post a comment