The 'Drush' of the Matter and Other Drupal Musings

January 9, 2012

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.

Workflow

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_query() expects parameter 1 to be mysqli, null given database.mysqli.inc:114 [warning]
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...)

It was the oddest thing. Searching for the error I was getting didn't really yield any good fix, I found where others were getting this error but not anything
concrete to go on, the error was fairly vague. The other weird part about this was that Drush was working fine on other local dev sites but not this one.
The problem site in question was using the Domain Access Module so I figured it was something with my local config either in the Hosts file or in MAMP Pro itself.
I read endless post after post on drupal.org of possible fixes for Drush not working but still no joy. I even filed my own issue as well. I created a drushrc.php file ~~in the webroot~~ in /sites/all/drush/

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:

No such file or directory
(trying to connect via unix:///var/mysql/mysql.sock)
[warning]

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 /var/mysql/

The fix

The fix was to simply open Terminal and execute these two commands:

sudo mkdir /var/mysql
sudo ln -s /Applications/MAMP/tmp/mysql/mysql.sock /var/mysql/mysql.sock

Basically this creates a symbolic link to point Drush to the proper location of MySQL which in my case was in MAMP. Not only did this fix this new Drupal 7 Drush error but it also fixed that old Drupal 6 Domain Access site Drush error. The part that baffles me is why I didn't get this same error on said Drupal 6 site, if I had, I probably would have fixed this much sooner.

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.

etc...

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...