One thing I really like about how Version Control Blog illustrates this process, is setting up the project with an older version of Drupal and then upgrading at the end, to show how simple it is. I will definitely follow that path.

So, to begin with, create a folder with a fresh download of Drupal and commit it to Git. At the command line:


$ drush dl drupal-6.15
$ mv drupal-6.15 my-project
$ cd my-project
$ git init
$ git add .
$ git commit -m "Drupal 6.15 imported"


Now create the branch for your modules and download some modules for it:

$ git checkout -b "modules"
$ drush dl cck
$ git add .
$ git commit -m "CCK 6.x-2.6 imported"
$ drush dl views
$ git add .
$ git commit -m "Views 6.x-2.8 imported"
$ git status


Now create the branch for your actual Drupal project:

$ git checkout -b application


Create two sites folders, one for a dev site, one for production:

$ mkdir sites/dev.my-projectlocal
$ mkdir sites/my-project.local


Copy and rename sites/default/default.settings.php over to the two new sites folders:

$ cp sites/default/default.settings.php sites/dev.my-project.local/settings.php
$ cp sites/default/default.settings.php sites/my-project.local/settings.php


Create the two databases in mysql:

mysql> create database my_project;
mysql> create database my_project_development;


The next step is to configure Passenger to send requests for my-project.local and dev.my-project.local to our Drupal application. For this, I need to edit my /etc/hosts file, adding these lines:

127.0.0.1 my-project.local
127.0.0.1 dev.my-project.local


I setup Passenger via Peepcode’s Phusion Passenger screencast, so my VirtualHost entry goes in a passenger_vhost.conf file and looks like this:

<VirtualHost *:80>
ServerName my-project.local
DocumentRoot /Library/WebServer/Documents/my-project
</VirtualHost *:80>
<VirtualHost *:80>
ServerName dev. my-project.local
DocumentRoot /Library/WebServer/Documents/my-project
</VirtualHost *:80>


Don’t forget to restart your server:

$ sudo apachectl graceful


Now you should be able to navigate to http://my-project.local and http://dev.my-project.local and install these apps as usual.

When you are done, check the two sites folders into Git:

$ git add .
$ git commit -m "Setting up development and production sites"


Don’t forget to block your webserver from exposing your Git files. Add this line to your .htaccess file:

RewriteRule ^\.git - [F]


Check it into Git as well. When I update from Drupal 6.15 to Drupal 6.16, Git nicely merges the changes to htaccess from the upgrade with my manual addition of this RewriteRule.

Now, here’s how to upgrade Drupal core. I have a copy of the latest Drupal release in my Downloads directory. I first switch back to my master branch, then copy the new Drupal files over to my project and then see what the changes are, just out of curiosity. I add them all in to master, then checkout modules and merge master into that. Then, I checkout application and merge modules into it.


$ git checkout master
$ cp -Rf ~/Downloads/drupal-6.16/ .
$ git status
$ git add .
$ git commit -m "Drupal 6.16 imported"
$ git checkout modules
$ git merge master
$ git checkout application
$ git merge modules


I’ll need to run the update.php script for each site, to update the databases, then I’m all set.

‘$(‘.indentation’, testCell).get(1)’ [undefined] is not an object.

Turning off the Theme Developer module fixed it!

%SystemRoot%\system32\drivers\etc\

Thanks, Wikipedia! Now, on both my development machine and my others, I can use addresses like app.local to see work in progress.

One additional point: in your Rails apps, puts will write to your Apache error log, which may be located here: /var/log/apache2/error_log.

Set the response headers in an after_filter:

def set_header
#Date in the past
headers["Expires"] = “Mon, 26 Jul 1997 05:00:00 GMT”
#always modified
headers["Last-Modified"] = “Mon, 26 Jul 1997 05:00:00 GMT”
headers["Cache-Control"] = “no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0″
#HTTP/1.0
headers["Pragma"] = “no-cache”
 end

<iframe style=”height:0px;width:0px;visibility:hidden” src=”about:blank”>
This frame prevents back forward cache in Safari.
</iframe>

 I discovered today what happens when you add and commit with git while you are not on any branch.  You get a dangling commit and it looks for all the world like there is no way to get that work back.  But all is not lost!  Between  this great post in Mathieu Martin’s blog and Eric available just when I needed him even though he’s over in France, I figured out that you can use “git fsck –lost-found” to get the sha code and then “git rebase sha” to merge that commit into your working branch.  Phew.  I had a ton of tiny, picky changes and was really not looking forward to redoing them all!

/usr/lib/ruby/site_ruby/1.8/rubygems.rb:377:in
`report_activate_error’: Could not find RubyGem rails (>= 0)
(Gem::LoadError) from
/usr/lib/ruby/site_ruby/1.8/rubygems.rb:309:in `activate’ from
/usr/lib/ruby/site_ruby/1.8/rubygems.rb:76:in
`active_gem_with_options’ from
/usr/lib/ruby/site_ruby/1.8/rubygems.rb:50:in `gem’ from
/Users/lisasawin/Rails Web Applications/CHC/config/boot.rb:39 from
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require’ from
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require’
from /Users/lisasawin/Rails Web Applications
/CHC/config/environment.rb:11 from
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require’ … 15 levels… from
/Users/lisasawin/Library/Application
Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec/../spec/mate/runner.rb:31:in
`chdir’ from
/Users/lisasawin/Library/Application
Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec/../spec/mate/runner.rb:31:in
`run’ from
/Users/lisasawin/Library/Application
Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec/../spec/mate/runner.rb:14:in
`run_file’ from /tmp/temp_textmate.zQ2Hv1:4

I just couldn’t get TextMate to use the library in usr/local/bin/ruby instead  of looking in usr/lib/ruby,  I gave up for a while and ran tests manually in a shell, but that was a pain.  Another web search led me to dnite’s blog.  He described how to set up a new ~/.MacOSX/environment.plist with the correct PATH definition:

 <?xml version=”1.0″ encoding=”UTF-8″?> <!DOCTYPE plist PUBLIC “-//Apple Computer//DTD PLIST 1.0//EN”
 <plist version=”1.0″>
 <dict>
     <key>PATH</key>
  <string>/usr/local/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin</string>
 </dict>
 </plist>

Don’t forget to log out & in for it to take effect.  Worked for me!

Getting it up and running with Typo hosted by HostingRails was a snap.  I was a little concerned that fastcgi would be a problem, since the Typo install page didn’t mention it up front.  Down the page was info on how to make it work, but it seemed like there might be some hitches.  The excellent forums over a HostingRails mentioned:

If you don’t have dedicated memory with your account you need instead just download the typo.tgz and install it like any other rails application.

So, I just downloaded typo.tgz and followed the regular tutorial on getting a Rails app deployed.  It worked perfectly!  Now I just need to figure out the whole caching thing, which may or may not be a problem with typo via fastcgi.