Blogs

… or "how I re-invented the wheel". Again

I found myself needing a tertiary menu in Drupal yesterday, which sadly it doesn't provide by default. There is a primary menu and a secondary menu that can auto-populate based on the primary menu selection, but sadly that's the level at which it stops.

Google helped me find a few blogs that show how to easily generate an arbitrary level sub-menu, though most are for D5 and not D6. Ignacio Segura amended code on this blog that makes it all work for D6:

I'm in the process of setting up Redmine (version 1.0-stable) on an Ubuntu 8.04 virtual machine. Getting a recent enough gem and rails is less fun than you might imagine, but the big issue I came across was a bug in the database model, which makes MySQL 5.1 (MariaDB 5.1 in my case) barf on installation.

There is a fix, but I am running from a git clone didn't want to download and apply a diff file to that repository. A quick google found what I need: the git cherry-pick command. It allows you to grab a single commit and apply its changes to your branch. In my case:

git cherry-pick a628b0f186cf4d182ce5cee1a497ad42c5246406

Because all commits have a unique label, when 1.0.1 is released and I update my git clone, I won't suffer merge conflicts from this already-applied change. Lovely :-)

When creating a Drupal site for clients, many people use a temporary hostname for development purposes. What's more, that hostname is not generally on the same domain as the production site. I'm sure I'm not the only one to use client,mydomain.com to develop the www.client.com site.

[[wysiwyg_imageupload:21:]]

When you — like me — use Drupal in a multisite setup, where the same codebase is shared between many sites, you'll have per-site settings, files and images. These are located in a directory structure that's based on the hostname you're accessing the site under. Eg: the files and settings for client.mydomain.com live in the sites/client.mydomain.com/ directory.

However, when the time comes to deploy the site to its production hostname, those settings and files need to live somewhere else. Moving them can result in link and image breakage on the front-end, which is never a good look and means you might need to painstakingly update links and images on all your pages.