workflow

You want to set up key-based authentication so you can ssh into a server without entering that pesky password over and over again?

If you have to do this often, then use this wonderful one-liner to install the public key of your system on a remote server¹:

cat ~/.ssh/id_?sa.pub | ssh <host> 'mkdir -p .ssh; cat >> ~/.ssh/authorized_keys'

Easy, right²? Replace <host> with your host, or possibly even user@host. To be able to use just <host>, you’ll want to configure SSH host aliases, e.g.:

Host seedbox2
    HostName norris.com
    User chuck
    Port 55555

Jacob Singh did a presentation at DrupalCon London about “How to have an open relationship … with software (and still make paper)”. I’m one of the people he interviewed for his presentation.

One of the questions he asked, was this one:

How do you use version control, spreadsheets, text files, napkins, etc to track your customizations to Drupal modules and core? Until the DOG project is done, what is the best worst practice here? On the Gardens team for instance, we used a PATCHES.txt file which listed the date, author, description and link for every patch to core or contrib. low tech, somewhat functional. How do you do this?

He liked my answer so much that he told me I should write a blog post about it — even if I’d just copy my answer verbatim. I’d been wanting to do that for years now. “Better late than never”, right? Although it’s actually too late now, because this system was actually designed to work when Drupal’s code still lived at http://cvs.drupal.org…

I keep all my Drupal sites up-to-date by updating a single Drupal core instance and one install profile. And I keep Drupal core and all modules in this install profile updated through CVS. But then a problem poses: what if a file was added to or removed from CVS? Until now, you’d have to manually svn add or svn rm the file. And in the case of some modules (e.g. Views), that’s a lot of files you’ll have to check.

The solution: syncvsvn {#solution}

I’m aware that this probably isn’t the best name, but it gets the job done :).

Suppose you’ve just updated the xmlsitemap module:

It has bothered me since day one at university that I can only use the university’s SMTP server. I got by, by just letting sent messages fail, because then I’d get a pop-up which would let me pick another SMTP server. This was of course far from perfect: sometimes I thought a message was sent while it really wasn’t … so it would sit in my outbox for a day.

Possible solutions {#possible-solutions}

The only real solution is for the university’s network to be improved: they should find a way to limit network traffic and abuse in ways that don’t affect the user so severely. (On the bright side: the wireless network was incredibly unreliable the first 2 years but is superb since this year!)
Until that happy day, I needed an interim solution. The best solution would involve an SSH tunnel to keep using the correct SMTP server. It also requires you to have a server somewhere with SSH access. I don’t want to maintain that too, so I chose for a simpler solution.

For several courses at the university, we’ve got projects going on (actually, 5 simultaneously…) and for most of them, we have to write fairly large documents. We also have to work in groups of 2, 3 or 5. So collaborative writing becomes a necessity. Finally, in the group of 5, we work on 4 different operating systems. So whichever solution we pick, it must seamlessly work on any platform as well.

We chose LyX.

• LyX is a WYSIWYM GUI to write LaTeX documents.
• LyX is written in Qt, a cross-platform GUI toolkit (the most awesome one, if you ask me!), which makes it possible to use it on Windows XP, Windows Vista, Mac OS X and Linux.
• To make LyX collaborative, we use the SVN version control system (which is also cross-platform).

This is how we started. But some problems emerged:

Is it also for you a routine to look up the documentation for Drupal hooks at api.drupal.org? If you also use TextMate and are sick of having to command-tab to your browser to get to the documentation, then you’ll have a much better alternative in about 15 seconds.

Go to Bundles → Bundle Editor → Show Bundle Editor. There, click the plus-button in the bottom left corner to add a new command. Set the input to None, the output to Show as Tool Tip and the scope selector to source.php. Copy/paste the command below and assign a shortcut — I use CTRL + D.

Add these lines to your ~/.bash_profile if you’re using the Bash shell:

alias ddiff="cvs diff -u -F^f -N > "
alias dhead="cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal checkout drupal"
alias dupdate="cvs update -dP"

Now you have three new commands at your disposal:

ddiff : Usage: ddiff patchfile.patch, creates a patch file.

dhead : Usage: dhead, checks out Drupal HEAD in the current directory.

dupdate : Usage: dupdate, updates the current directory recursively.

Update on August 10, 2011

While cleaning up my ~/.bash_profile file, I came across the following functions that I’ve used for many years and shared with several other Drupal developers. These are now obsolete, thanks to Drupal.org’s migration from CVS to git.