Drupal Time-savers

If you work freelance like I do, you know that time is money. I’m always trying to shave a few more seconds off my development time. Here are a few tips and tricks that I constantly use:

• Firefox Wildcard Bookmarks

  Set up some bookmarks with keywords shortcuts and wildcards. I have a bookmark for the forms api reference so that I only have to type ‘forms’ to get to it. I also used this method so that I can quickly look up api functions. I used a similar wildcard bookmark for project pages. Now if I’d like to see the views page I simply type in ‘pr views’. Not only does this save me a lot of time but it also encourages me to go check out modules I might have otherwise put off looking at since it seemed like a slight hassle previously.

• Drupal CVS shortcut

  I check out a lot of modules from Drupal’s CVS. With Drupal you can just about build a website as fast as you can check out modules. Well, almost. I constantly had to look up the terminal command for cvs checkout until finally I got wise and set up an alias. On my Mac I did this by

  cd (go to your user home directory)
  vi .bash_profile (edit your bash profile in a unix editor I am just not quite geeky enough to have mastered. Alternatively, if you’ve set up Textmate properly you can do ‘mate .bash_profile’)
  Now add the line: alias drcvs=”cvs -d :pserver:[email protected]:/cvs/drupal checkout”

  Now when I want a module I type: drcvs -d {modulename} -r {version} contributions/modules/{modulename} . This I can actually remember.

• Drupal navigation

  You need to get into admin_menu and/or teleport modules. I’m going to stop giving out links to every great module since by now you should have created your firefox wildcard project bookmark.

• Parallels (Mac)

  Launching Parallels is faster than Bootcamp or getting up and turning on your old PC. Personally I believe if you’ve so much as touched your client’s css that it is now your moral imperative to recheck everything in both IE6 and 7. Bonus tip: run them both.

• Firebug

  Firebug is the best thing that ever happened to css as I’m sure you’re aware. Make sure you check which line number of which css file you need to change and then use your text editor’s keyboard shortcut to go straight to that line. I like to use Firebug for anything I might have previously used ‘view source’ for as well. You can make sure that new css or js file you added with drupal_add_css or drupal_add_js loaded properly on your page. Find out your keyboard shortcut to go straight to inspect mode (mine is shift-command-c). I constantly use inspect mode to take a look at the relevant markup. Often if you need to find a theming function a Firebug glance at the markup will give you something to search for in your text editor. It may also give you a hint as to the form_id you’re trying to hook_form_alter.

• Firefox search

  Go to your Firefox preferences and under General:Accessibility check off ‘search for text when I start typing’. Now you don’t need to hit command-f to search on the page. When you go to admin/build/modules to enable your new module, just start typing the first few letters and you’ll jump down to it on the page. Congratulations: you’ve just saved 200ms. Well, everything adds up.

• Use your editor

  Mine is Textmate (Mac only) and it’s pretty great. Although you might be tempted to just type a little php in a block edit textarea or similar place, I find that this usually costs me more time than it saves because half the time I mess up a bracket somewhere. If your block is fairly complex you’ll really be glad down the road (probably three minutes from now when you want to edit it) that you took the extra minute to call hook_block in your custom module. If I really do just need to insert a little php, I still write it in my editor and then paste it in. This spares me the otherwise inevitable debugging. I think that doing things right is almost always faster than doing them fast and possibly having to debug them later.

• Submit a patch

  This might not seem like a time-saving tip but I’ve come to believe it really is. It turns out the only difference between being a frightful Drupal hacker and an esteemed Drupal contributor is whether or not you submitted a patch. I used to always hear “don’t hack Drupal” and wonder how the hell these people thought that was possible when surely we all know there are dark corners of code where the override and hook systems never reach. Finally I realized they probably just submit a patch and call it ‘contributing’ instead of ‘hacking’. Actually I didn’t realize this until some point after I joined them.

  When you get in the habit of submitting a patch immediately after debugging or adding a new feature to a module, it will only take you a few minutes to do. The time savings comes from the fact that you now have other eyes on your work. Sometimes the module maintainer will turn around and point out to me a bug in my patch that I hadn’t yet tested for. Usually they will eventually commit my patch, which may be a time-savings for me on some future project or when upgrading the current one. Or they might give me a tip like “upgrade to my latest version you idiot because it’s actually way better” which is valuable to know. Maybe they will like my code so much that they will offer me marriage or employment, which could be side benefits on my time-saving mission.