September #TMIL - Back to Drupal

Last fall, I finally got around to moving joemerante.com, a Drupal site, to a new host. It was getting a little ridiculous that I had no way to ssh into the hosted space and couldn't simply git push origin master or similar to deploy (no need for anything fancy given the traffic and simplicity of the site - see my previous workaround here). Why didn't I just quickly redo the site in Sinatra or Rails? Mostly because it works fine as-is, I like Drupal (the nostalgia factor of being the first web framework I learned well, also it's a great CMS and community) and jumping around between different environments keeps you sharp. This post rolls through a few things I came across while moving the site, maybe it'll help someone out there.

First, a quick to do list:

• get latest database and code
• import database to new host, add new database user and privileges to the database, change Drupal admin user password
• update production database connection info in settings.php
• get ssh access and set up drush on new host 
• add git remote of new production code location, push (move git-ignored settings.php separately)
• point domain nameserver to new host
• profit

OK, well maybe not so much the last part. And there might've been a few other steps along the way but those are the basics. I just like making lists. Along the way, I wanted to make a change to the way a legacy project (a Drupal site living in my Drupal site) displayed a field, since ... no one ever looks at it. The principle of trees falling in the forest, I guess.

To make the change, I needed to brush up on the Drupal 7 database API and drush. I thought I'd check my work locally before deploying, which means MAMP. While it's usually trouble-free, sometimes things go wrong...

Can't get Apache to start?

• try changing /Applications/MAMP/Library/bin/envars to _envvars

Great, now the MySQL and Apache servers are running. (Assuming you're all set up on localhost otherwise - this post helps) Now from the command line I was hoping to simply drush sql-cli when things went wrong again.

Can't connect to local MySQL server through socket '/tmp/mysql.sock'?

• Create a symlink in your application's root directory then restart MAMP (or just MySQL), something like public_html git:(master) ✗ ln -s /Applications/MAMP/tmp/mysql/mysql.sock /tmp/mysql.sock
• ht @ https://coderwall.com/p/w5kwzw (which redirects to the right url but shows a 500 error as of this writing)

OK, enough is enough. Turns out what I was really looking for is drush php-eval to run code and get instant feedback (wish I knew this when I built my first Drupal site in 2009-10!), though I needed to use double quotes inside my query and pass everything as a single-quoted argument, like

drush php-eval '$doctype = "document"; $result = db_query("SELECT n.title, n.changed FROM {node} n WHERE n.type = :doctype ORDER BY n.changed DESC LIMIT 1", array(":doctype" => $doctype));
foreach ($result as $record) {  $datestamp = $record->changed;
  $unixtime_to_date = date("F jS, Y", $datestamp);
  echo $unixtime_to_date;
}'
More complicated examples can be found in the documentation for database API Result Sets. Going through this reminded me of something a wise friend once told me as I was moving from PHP/Drupal to Ruby/Rails a few years ago, "It's all the same issues and concepts, just different syntax."