The 'Drush' of the Matter and Other Drupal Musings
I'm a Front End Drupal Developer / Themer / Site Builder and admittedly have been slow in adopting tools like Drush and Git for my workflow. Not because I didn't want to but only that I am very right-brained, so the command line / Terminal to say the least has not been my friend. However, I know these tools increase productivity immensely and I have slowly been learning some skills here. Thanks to a few other Drupal Developers in the community helping me out over Skype and email, and reading the issue queues on drupal.org, I now at least have a working knowledge and have seen the light and advantages of using these tools. In particular, David Lanier for helping me see the light with Git on a project we worked on together and recently, Ben Buckman for showing me the power of Drush and Git. These two guys know their Drupal stuff. I'd like to think my days of FTPing a module update up to the server are in the past but this won't happen overnight as I need to retool a lot of my sites for this.
My new workflow basically is to develop locally using MAMP Pro 2.0 for Mac OS X Lion. (I won't say much about Lion except for that fact that I don't love it. I think it's a brilliant OS but it seems to run slowly on my Mac Pro Quad Core with 12 GB of ram, even with a clean install.) My local Drupal dev site is in Git and I commit and push any changes to Github. I then pull those changes to the production server directly from Github. I have even played around with creating branches like a
modules-update branch for example. I think I also want to have a branch for theming as well. The idea is that I pull a given updated branch to the server and if all goes well, I merge and then pull the master branch.
The 'Drush' of the matter
Well, here's the crux of the matter. Recently I ran into an issue with a local Drupal 6 dev site when trying to use Drush. When I input the Drush command I would get some mysql errors and then page.tpl.php would print out right in OS X terminal. I could not even run
Drush sql-connect successfully but that told me that Drush was not even seeing MySQL.
The error was:
mysqli_errno() expects parameter 1 to be mysqli, null given database.mysqli.inc:128 [warning]
(and then page.tpl.php proceeds to print out in terminal...)
/sites/all/drush/and specified my local site:
$options['l'] = 'mysite.drupal';but that did not help to fix it either. It seemed like I spent days trying to get this to work and finally I moved on.
The issue reveals itself
Yesterday, I installed a new Drupal 7 site I am working on for a client via Drush and all seemed to go well. However, after I started using Drush on this new site to download and install some third party modules, though it was working of sorts, I was getting a little error. Part of the error was:
(trying to connect via unix:///var/mysql/mysql.sock)
hmm, interesting, Drush is looking for mysql where it normally would be had I installed it natively, not where MAMP has it placed. I used my google-foo and came up with a very interesting issue on drupal.org in regard to MAMP and in particular MAMP v. 2 being used in combination with Drush. It turns out that if you are using MAMP you need to tell Drush to look for MySQL in the MAMP directory and not in
The fix was to simply open Terminal and execute these two commands:
sudo ln -s /Applications/MAMP/tmp/mysql/mysql.sock /var/mysql/mysql.sock
Moral of the story?
Ultimately I found there was a patch made to the Drush Readme documentation file. Had I throughly read the documentation from the beginning, I would not have had to go through much of this. On the other hand, my right-brained creative side often prevents me from doing so and that's both painful and exhilarating at the same time. Ask my wife, Elise, she will be the first one to say that I never read the manual for anything.
Next up, learn how to use the Features Module and make this web site a responsive design but hopefully with less hair pulling as I don't have much left...