EDIT: It seems that the version 7 early access now has a file watcher preset for Compass - nice work JetBrains! The part about scope from this blog post is still useful to you if you are on PHPStorm 7 though.

I started using PHPStorm about 6 months ago and while it is an extremely awesome and powerful IDE there are just so many things you can set up and configure. I have to admit that for the first couple of months I pretty much used PHPStorm just like I did Vim and not using any of the many configurable things except for the debugger. I am slowly venturing into playing around with setting more stuff up, and I thought I would share this one because it took me a while to get right.

It is super simple to use the Compass compiler from the command line and I always have. But PHPStorm can compile your .scss files into .css on the fly so why not take advantage of that.

So here is what I did. The settings assume that you use something that resembles the default settings in a Compass project with a folder for the scss files and the css being output to another folder called something like "stylesheets" or "css" (could be anything really). You also need to have Compass installed on your machine.

1. In the PHPStorm settings, go to "File Watchers".
2. Click the plus to add a watcher and choose SCSS.
3. Edit the settings to look like the ones on the screenshot. Where Compass is installed on your machine may not be in /usr/bin/compass like it is on mine, but you can use the command whereis compass from your command line to figure out where compass is. The output path is "stylesheets" for me for this particular project, but you shold edit that to whatever your project has named the css output folder.

Note that I have created a "scope" called Theme. Scopes in PHPStorm are parts of your project that you would like included or excluded in things like searches and settings like this Compass setup. There is no reason for PHPStorm to listen for changes to your module files if your theme folder is where you have your Compass project. So if you click the button with the three dots at the scope field you can setup PHPStorm to only look where it is relevant. I use scopes a lot to cut down on how long searches take, so setting up a few scopes for each project is time well spent.

I like to keep my code free of trailing whitespace. I feel what xjm describes as "spinach in your teeth" about whitespace and non-conforming coding standards.

I got (heavily) inspired by Josh The Geek's git pre-commit hook, and made myself a commit hook that will check the code I am about to commit for common errors. In addition to whitespace, I like to make sure that I don't accidentally commit debug code like krumo(). The commit hook also checks for common calls to debug functions.

If you want to use it, simply put it in your .git/hooks folder in your git checkout. Make sure the file is executable with chmod +x .git/hooks/pre-commit. This will only effect the git checkout you put the commit hook in, but you can make it apply to all future checkouts by putting it in your git install directory's template folder. Where that folder is will vary, but on my mac it is in /usr/share/git-core/templates/hooks.

The script is not the most clever in the world, so it will be wrong about some things from time to time. You can override it and still commit with the command git commit -n

Here is the pre-commit file: Gist is here.

#!/usr/bin/php
<?php
/**
 * @file
 * This is a Git pre-commit hook that informs you when you are
 * about to commit whitespace or a debug function.
 */

$red = "\033[1;31m";
$red_end = "\033[0m";

$yellow = "\033[1;33m";
$yellow_end = "\033[0m";

/**
 * An array of functions to check for.
 */
$check = array();
$check[] = ' dsm(';
$check[] = ' dpm(';
$check[] = ' dpr(';
$check[] = ' dprint_r(';
$check[] = ' db_queryd(';
$check[] = ' krumo';
$check[] = ' kpr(';
$check[] = ' kprint_r(';
$check[] = ' var_dump(';
$check[] = ' dd(';
$check[] = ' drupal_debug(';
$check[] = ' dpq(';

$return = 0;
$diff = array();
exec('git diff --staged', $diff, $return);

if ($return !== 0) {
  fwrite(STDOUT, "git diff returned an error. Commit aborted.\n");
  exit(1);
}

foreach ($diff as $lineno => $line) {
  if (substr($line, 0, 1) != '+') {
    // Skip the line if you aren't adding something that may contain a debug
    // function call.
    continue;
  }
  foreach ($check as $lineno => $function) {
    if (strstr($line, $function)) {
      fwrite(STDOUT, "{$red}Oh, noes! You were about to commit a $function)?{$red_end}\n");
      fwrite(STDOUT, $yellow . $line . $yellow_end);
      fwrite(STDOUT, "\nCommit aborted.\n");
      exit(3);
    }
  }
}

$whitespace = shell_exec('git diff --staged --check');
if (!empty($whitespace)) {
  fwrite(STDOUT, "{$red}Commit aborted. Fix trailing whitespace.{$red_end}\n");
  fwrite(STDOUT, $yellow . $whitespace . $yellow_end);
  exit(4);
}

// If this is still running, all is peachy. Let the developer commit.
exit(0);

I have my LAMP stack and other things set up on my mac with the wonderful Homebrew.

I recently did a brew upgrade on my system and it seemed that everything went smooth. But when I later ran PHP from the command line I got this error:

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/Cellar/memcached-php/2.0.1/memcached.so' - dlopen(/usr/local/Cellar/memcached-php/2.0.1/memcached.so, 9): Library not loaded: /usr/local/lib/libmemcached.9.dylib
  Referenced from: /usr/local/Cellar/memcached-php/2.0.1/memcached.so
  Reason: image not found in Unknown on line 0

I poked around in my php.ini to see if the wrong file was being included or something like that, but it turned out that I had upgraded to a newer version of libmemcached than the one memcached was using. So I needed to downgrade libmemcached. Here is how to switch to any version available with Homebrew:

• brew versions libmemcached

• Find and note the version number you want. In my case I wasn't sure, so I just went with the second newest and that worked.

• brew switch libmemcached 1.0.4

Change the version number and the formula above to whatever makes sense for what you are doing.

The example above is using a command that is an external command for Homebrew. It works super fast and is easy to use.

So, Camilla.. Why is your nick everywhere naxoc?.

Xoc means shark in Yucatec Maya. It might actually be one of the very few words that made it into English. I used to study American Indian Language and Culture at the University of Copenhagen. Those were the days with much nerding over Mayan hieroglyphics. Maya hieroglyphic texts are often about how fantastic the rulers where and one of the more fantastic female rulers was called Lady Xoc. I thought she was pretty cool, so I stole the name. The Na- prefix is simply a marker for female. So there is the story of my weird nick.

It is pronounced “nashoc”.

The Devel module includes the super helpful Krumo library. I use dsm() and krumo() all the time. If you are not familiar with Devel, you should try it. Morten Wulff wrote a demo page for the module.

Today a client suggested that the Devel module Krumo could display the "path" to an item in an array by right clicking or otherwise interacting with the nested elements in the output from Krumo. I was really excited about that idea - I can't count the number of times I have tried and failed to target an item deep in a form array or an item in the node object simply because my human brain can't remember a structure like $form['#node']->content['links']['comment']['#attributes']['class'] for more than 3 seconds.

Still very happy with this new idea I went straight home and started to hack away at the Krumo library to make it display the path to a desired item. After looking at the javascript for a while, and saying out loud that Javascript hates me, I realized that the killer feature I was trying to make already exists in Krumo! This is a well hidden gem that I haven't seen before today, so I thought I would share it: If you double click an item in the Krumo output it prints the items array "path" so that you can copy paste it into your code and stop worrying about remembering long array structures.

Thanks to Niels Fanøe for the inspiration.

EDIT: I was using the dev D7 version, and the feature just went in this August. Thanks to Mark Theunissen for pointing that out. I also feel less stupid for not discovering the feature before now!

If you are moving an iTunes library to a new mac it will go smooth if the user login is the same. So if I move my iTunes library from an old machine where it was located in /Users/ckj/iTunes to a new machine where it is gonna go in /Users/ckj/iTunes - I have no problems. But if I changed to another username on the new machine - all the paths in the iTunes Library.xml file will not be correct anymore. I have moved libraries so many times now and I thought I would share a really quick way to fix the iTunes Library.xml file to reflect the correct user directory.

If you use the built-in command line tool called sed, you can type one line in the terminal and be done. Let’s say I was moving from a mac with a user directory called "ckj" to another machine with a user directory called "naxoc". All I would have to do in the terminal would be this:

1. cd to the iTunes folder in the user directory you are moving to.
2. Enter this: sed -i "" -e "s,Users/ckj,Users/naxoc,g" files iTunes\ Library.xml

Note the funky syntax with the -i "" This is a mac quirck in sed. I found some info on it here.

My beloved 3years old Macbook Pro was starting to get really hot when I used it. It had gotten to the point where I would burn my legs if it was on my lap, and since having your laptop on the lap is kinda the point, I felt had to do something about it.

I bought a Logitech Notebook Cooling Pad that actually is very comfortable and does exactly as it says it will, but I was still curious to see if I could get my old healthy Macbook back.

I found this blog post about how to vacuum the laptop and the result is amazing. I was a little worried about the static, so I turned the machine completely off and removed the battery before vacuuming. The happy laptop is now quieter and cooler! Very simple and very recommended.

Image from noor*.

I have a lot of pet peeves when it comes to programming, databases, web content, food, beer, and, well just about everything. I am thinking of making a series of pet peeves here on this site. Some will seem like plain rants, and others will be more like tips.

When making comparisons, switch the order of the things you compare like this:

if ('book' == $node->type) {
// Stuff happens.
}

You might think why? And that looks weird! Yes, it does look a little weird. But I do this to not accidentally assign the $node->type the value I am comparing it with. It is hell to find an error like this when debugging:

if ($node->type = 'book') {
// Stuff happens whether you like it or not.
}

See what happened? I only put one = instead of two. PHP will not complain about this, I will just not get what I expect. If I had switched the items, PHP would have complained as I tried to assign an object to a non-variable.

I am doing some integration with facebook these days. I don't use facebook much and I certainly no not want all kinds of test data on my profile so I made a test profile using names that just came to mind :-P

On the facebook developer pages there is a demonstration of the like button. That you can like... Gotta love the meta!

I updated this website to D7 this weekend. Mikkel upgraded his site and urges others to do so now, so I thought I'd give it a shot too. And it was good fun! OK, granted, this site is 4 posts and pretty much nothing else, but that makes it a perfect time to upgrade.

I actually never did an actual core upgrade via the upgrade path before. The sites I have upgraded from D5 to D6 have pretty much all had such a complex data structure that I had to do an upgrade with a data migration. While that is a lot of work (and requires a programmer), I still like the opportunity it gives to clear out a data model that might have grown a little too organically. For this site though, that would be gross overkill. So my approach was simply to read UPGRADE.txt and follow the steps.

Modules

I don't use any of the big modules like CCK, views or panels. In fact I ended up with only 3 enabled contrib modules.

• On D6 I had a tag cloud that the tagadelic module made, but I simply removed that because I couldn't see a 7.x branch on d.o. It turns out that there is work in progress to port it, so in this issue I found that development is going on github. I really like that module so I might take a look and see if I can help.

• The twitter module does not have a 7.x branch either, but there is work going on. I decided to go for the easy choice so far and just this twitter-widget and embed the code in a block. In fact for my need that is just fine.

• I have always loved the admin_menu module even though the fancy menu that sits on the side and awaits your click in rubik is nifty, I still like the overview that admin_menu gives me better. Luckily there is a 7.x branch and it also packs a neat integration with the top toolbar that D7 ships with.

• Google analytics has a 7.x branch and I had no trouble with that other than some problem with actually writing the tracking codes. But it turned out that the theme was not doing that.

• The Mollom module was not working, but I think I upgraded it wrong. As soon as I uninstalled it and installed it again it was fine. It threw errors at me when I enabled it after the core upgrade, so I must have missed something there.

• I use ecto as a blogging client for my D6 sites. The blog API module was taken out of D7 and now lives on its own here. I tried to make it work, but I can see that it will take me some time. I will have to spend more time playing with that.

Theme

I really like the Corolla theme. I knew I wanted to use that so I didn't even browse around for a D7 theme. Configuring color and all that was easy, and the only problem I ran into was the theme not printing the footer with the google analytics tracking codes.

So what's it like?

I like D7. A lot. I have been playing around with it for a long time, but always with test data, the standard theme, and not so many contrib modules. It's great to see it all come together. One thing that took me a long time to get used to is the overlay. At first I hated it, but during the last 6 months or so it's grown on me. I am still not sure I would keep it enabled on any site, but it gets a chance on my site for now.

Another thing in D7 that really threw me off during the upgrade was that the core modules are listed first on the modules page. For a while I thought that drupal was just not finding my contrib modules. I would probably put them at the bottom if I was to sort them other than alphabetically.

I am excited to finally run Drupal 7! And I can't wait to play with more contrib modules more and see what cool stuff comes out of all the new opportunities in D7.