Someone Dropped a New Website in Your Lap, Now What?

At Aten, I tend to work on already live websites. Sometimes this means small bug fixes. Sometimes it encompasses information architecture, design work, a weeklong development sprint, and working on the front end. In most cases my work is on a site I didn't build originally and often on a site Aten didn't build. I started putting some notes together on some of the gotchas I run across when working on new-to-me sites. This will become a series of blog posts, but one always has to start at the beginning: getting the site working on your local environment. We're assuming you already have some sort of a LAMP/MAMP/WAMP stack working.

Version Control

Next, you'll need access to the code to get it into your preferred version control system. Make sure you don't commit any settings.php files, the files directory, and possibly .htaccess if it contains server-specific settings. If using Git, remember that just because you've added these files/directories to .gitignore, doing git add . will add them anyway. If the code is already in a repository this step should be as easy as git clone [PATH]. If not, you might need to use something like tar czvf ~/everything.tar.gz public_html to make a copy of the whole file structure. I've also seen cases where JavaScript libraries are maintained as separate Git repositories within the main one. If those are in .gitignore a regular git clone of the main repo will skip these. I prefer to keep everything together by removing the entries in .gitignore. Run git clone on each library, delete each library's .git folder, and finally use git add to add them to the main repository.

Database

After you have the code, you'll need to make a database export and import it. Drush sql-sync can do this, assuming [but that presumes] you have ssh keys and aliases configured and an already running site that drush can bootstrap. From the MySQL command line, create database [DATABASE_NAME]; use [DATABASE_NAME]; source ./[FILENAME.sql] always works. Don't forget to create a database user with something like: GRANT ALL ON database.* TO user@localhost IDENTIFIED BY 'someLongAndCompletelyRandomPassword'; FLUSH PRIVILEGES;.

Files

Along with the database, you'll need to deal with the files directory. If you had to tar the whole thing you've already got many megabytes of files on your hard drive. If you want to avoid that, Stage File Proxy can help by downloading images from a production website as needed on a page by page basis. While this will help, there are some images it has problems dealing with. Another possibility is using Apache rewrites to load image resources from the production site.

Domain

My final steps are to add an entry to /etc/hosts for the new local domain, and an entry or new vhosts .conf file to direct that domain to the correct web root directory. Finally, flush DNS cache and restart apache. These steps will differ slightly, depending on your specific LAMP implementation. Once we have the site up and running, it's time to make some improvements. Next time I'll discuss how to track down some specific situations when you know very little about how a site was built.