Xen.dk

Seems that Drush make is becoming the way to build distributions and sites. Especially the ability to use recursive make files to let each module pull in it's own dependencies allows for compartmentalisation of things is handy.

However, some times it can get a bit in the way of thing. Picture this:

We're building a distribution which consists of a lot of, more or less optional, modules, which all pull in their dependencies using make files, whether it's contrib modules or our own. For everybodys sanity, they're all specifying specific versions of their dependencies.

(If you don't get the title, watch this video.)

With the recent release of CTools/Panels alpha for Drupal 7, fears that Drupal 7 would have to go a long time without one of the more popular add-ons has been silenced. If Panels aren't ready on the D7 release day, it shouldn't be far behind.

So Hitler is happy, as is a lot of users and site builders.

At work we've been trying to figure out better ways to deal with CCK fields on our sites. The sites we build are very custom build, with much code relying heavily on specific CCK fields.

So far, content type and field setup has been a manual process, with all the problems that brings.

It's been a long way, and a lot of that time has been spent barking up the wrong tree, but the E-Commerce 4 QuickPay module is getting somewhere.

As eC4 doesn't (yet) quite grasp the concept of 'authorized but not captured', ec_quickpay have to modify the workflow somewhat. Being eC4, the problem is not customizing it, the challenge is to figure out the best way to do it. Should it modify the existing workflow rules from ec_store, or should it disable them and create it's own? The latter is probably the most robust solution.

Recently I got myself an G1 phone. Oh happiness, but I'll cut to the chase:

I've just made a (very) minor modification to an existing Android application (SMS Popup), and got it working on my phone.

I've longed for this moment for so many years.

UPDATE: This post applies to Drupal 5, in Drupal 6 it doesn't work. An alternative is to use full URLs in the menu, like "http://xen.dk/da", but that might not be acceptable in a given situation.

This is one of those hacks that just look wrong, but seems to work all-right.

Goal: Linking to a language specific path in a menu.

I was exited when I stumbled upon the news of Ruby for UIQ. Having an UIQ phone and being very fond of the Ruby language, I saw an opportunity for perhaps doing some applications for my phone. Technically, I could brush up my Java and make something right now, but truth be told, I just can't be arsed. Java is somewhat low level, and the amount of work involved keeps me away. For me to get involved, it would require a low effort to get started, and it might develop into more then.

The internationalization module (commonly know as the i18n module) and the pathauto modules are great modules, but when combined they do create a minor gotcha.

If you're the type to run statistics on your site, or otherwise look into how people are using your site, and have a fairly standard setup of i18n and pathauto, you'll discover that each node gets a path for each language you're using, regardless of what language the node really is.

FFMPEG is a great package for converting different video formats, which is widely used by Drupal video modules. The trouble is that due to licensing issues, the default version in Debian is somewhat crippled. One notable issue is the lack of MP3 support.

Google will tell you that you need to compile your own version, if you want to have support for the missing formats, and there's no shortage of pages suggesting how to do it. None of which I'm particularly happy about, so here's my version.