I recently ran across a feature of Drupal’s devel.module that might not be all that well known, namely that it has a facility for debug logging as well as the dpm() I’ve advocated to my fellow developers for a long time.

That is the dd()-command which instead of logging to screen simply outputs a print_r() to a file called drupal-debug.txt in your temporary files folder (where that is depends on your site configuration, but /tmp might be a good place to look).

That alleviates the many problems of simply logging to screen (doesn’t work with AJAX, redirects, causes browser slowness for large datasets, lots of junk in your HTML source, etc.). You can then simply run tail -f /tmp/drupal-debug.txt to see what’s going on – and for those of you that use Mac OS X, I have an additional trick.

OS X ships with a fairly good log viewer, namely Console.app – by default, it’s installed in Applications/Utilities. That can be used to view all the logs in standard locations, but with a little trick, it can be used to view this log file also.

Console has a section for ~/Library/Log, ie. the Log folder in the Library folder in your home folder. You can then set up a symbolic link to the log file there. I have a subfolder in ~/Library/Log called apache2, and I also have my Apache log files symlinked in there as well.

Anyways, the procedure to set it up looks like this:

cd ~/Library/Logs/  
ln -s /tmp/drupal_debug.txt

As an avid user of Stack Overflow (and Server Fault, to some degree), I am well pleased to announce the stackoverflow.module for Drupal.

Why do we need a module for that?

Well, the Stack Overflow team recently introduced a new feature called “flair”. This is basically a badge you can put on your blog to show your level of awesomeness on Stack Overflow (or its related site, Server Fault).

My beef with that (and the reason for this module) is that using that requires either an iframe (ewww!) or injecting it with JavaScript (slowing the loading of your website). I found neither palatable, and in addition, I’d like to be able to run it through the Drupal theming system, so the theming guys will be able to make it look pretty.

What does it do?

Basically, it let’s you set enter your user ID for the different websites in the Stack Overflow family, and it then exposes a Drupal block for the flair for each of them. The data is loaded from the Stack Overflow JSON/REST API and cached with Drupal’s caching system for a configurable amount of time.

This means that your users will have the exactly same experience with the flair being displayed, without the overhead of extra HTTP requests to Stack Overflow’s server, with the exception of the favicon, which we cannot distribute with the module, unless we get a GPL2-licensed version.

So whether or not you care about performance, you can now stick a nice Stack Overflow flair on your site – another wonderful way to let your geek flag fly :)

Where can I see it?

I have stackoverflow.module (0.8-beta1) enabled on this site – there should be a couple of flairs in the sidebar with my face on them.

Future features

I plan to implement per-user settings for flairs, so each user on a site will be able to have his flair show up on his profile page. Other than that, I’m open for ideas. See you in the issue queue :)

Currently, defining the simplest content type in Drupal requires ~54 lines of 100% standard boilerplate code.

The reason Object Orientation would be good here is the simple concept of inheritance.

Very simply, my 54 lines of code could be replaced by something like:

class CampaignContentType extends NodeContentType {
  // Custom functionality here.
}

I think I’ll go see if I can help Crell with his objective somehow :)

I just came across a new kind of spam, very cleverly made:

It’s a clever ploy, posting praise with hidden images. Only it was a bit off in my case, but if I hadn’t checked the source, I’d never have known that I was in fact in the advertising business.

This particular post actually slipped through Mollom, so beware, my Mollom using friends – I’ve submitted this one to Mollom as spam, but beware what might have gotten through the net.

Mollom is generally a brilliant service (I’ve had 5922 blocked spam attempts the last 348 days), but there’s always going to be a small amount of false positives. Spam filterning is no replacement for vigilance :)

I’ve just finished my migration of my two servers to FreeBSD 7.1, and I thought I’d take the time to write a short walkthrough for one of the more difficult steps in the process, so others won’t have as much trouble figuring it out as I did.

My web server is a rented Sun Fire X2100 from EasySpeedy. I don’t have physical access, so if you want to install an operating system not supported by their automatic installation procedure, your only shot is KVM-over-IP via Sun’s eLOM. However, as noted on EasySpeedy’s operation system support page, eLOM has troubles with FreeBSD.

I managed to find a workaround for this, but it’s not easy to figure out, so here’s a short little walkthrough:

First you have to actually get to the eLOM KVM-over-IP interface, which can be a bit difficult if you’re on a Mac, since the Java-app that handles it has issues with the Java shipped with Mac OS X. I handled this by remote desktopping to Windows server at the office and using that to connect, but the friendly guys at EasySpeedy are going to contact Sun’s customer support and see if there’s a better solution. I’ll post it here if I learn anything.

Also, when you’re using KVM-over-IP, make sure to keep the browser with the eLOM interface open and click one of its tabs every so often to prevent it from timing out. If it does, you’ll loose your connection, although whatever you were doing will carry on, reconnecting can be a bit annoying.

That aside, when you managed to get KVM-over-IP control of the server, the first thing you’re going to want to do is mount the FreeBSD install disk. I downloaded 7.1-RELEASE-amd64-bootonly.iso, but pick whatever image fits your needs. I like the bootonly, because then I only need to download the parts I’m actually going to install, since you can do it via FTP in the installer.

Regardless of what image you pick, the procedure is the same. Click the mounting button:

Select ISO image and click to select the file:

Navigate to the file and select it:

When that is done, you’ll want to reboot your server to boot into the FreeBSD installer. When the server reboots, be sure to hit F8 to bring up the boot device selection:

When the boot device selector shows up (and that takes a while – it only shows up after a couple of screenfuls of BIOSy things), select the virtual USB CD-ROM drive to boot the FreeBSD install disk.

When the FreeBSD boot screen shows up, select the “Escape to boot loader” option (number 6 in the picture below), since we will have to enter a special boot command to make FreeBSD play nice with eLOM.

When the boot loader prompt shows up (a simple “OK”), type in set bge.allow_asf=1 and press enter.

After that, type boot and press enter to boot up the installer.

After that, the installer should work with no further special tricks required. Just make sure to repeat the process of entering set bge.allow_asf=1 in the boot loader when booting FreeBSD for the first time, or you won’t be able to take control via eLOM.

When you get your new installation up and running, just put hw.bge.allow_asf=1 in /boot/loader.conf so you won’t have to do it manually every time your server boots.

Now go enjoy your new FreeBSD installation. And sleep safely knowing that you have KVM-over-IP access :)

Hat tip to Markus Fröhlich for discovering this workaround.

I remember my first Internet connection, all 33.6 Kbps of it. The warbling sound, the seemingly endless wait for a connection. And even when you would finally managed to connect, there were still the several seconds of load you had to endure for most sites. The past millennium, it feels like ages ago.

And in many ways, it is. A lot of things have changed since then, but one particular thing that hasn’t is the branding of Internet connections as “lynhurtig” (meaning “lightning fast”(. For example in this lightning fast Internet ad (PDF) from TDC. As long as I can remember, consumer-level Internet connections have been branded as “lightning fast”. It has never been true, given that lightning is a near-instantaneous delivery of enormous bandwidth (watts). But at least we are getting closer.

It struck me, just as I was downloading something from my web server that I was actually downloading two megabytes every second. That’s quite normal today (In Sweden, that would probably not even be considered fast), but it’s like a revolution compared to what we had a few short years ago. I don’t think the possibilities of the Internet will ever cease to amaze me. It’s just… wow.

The code from my CCK-presentation with Danish postal code is available on Github.
The rest is attached.

I’ve made PDFs of both presentations, and the original .key files are in a zip file.

So, I’ve finally taken the step up (in responsibility, that is) to become a module maintainer. I’ve been wanting to contribute more back to Drupal for a long while, so here’s my chance…

Actually, it started with my upgrade process for this very blog. I’ve been using Typogrify on Drupal 5 practically ever since it came out, so I had to find an upgrade for Drupal 6, and after messing a bit around in the issue queue, I saw that the previous maintainer had been inactive for a year, so I figured it was about time that I grew up and took a module maintainership.

So here’s for all you who use or would like to use Typogrify: I’ve released 1.0-beta1 releases for both Drupal 5 and Drupal 6 today, which fixes some of the outstanding bugs (not to mention being the first release of Typogrify and the first tarball for Drupal 6). Also, I’ll do my best to be a responsible maintainer.

A big thank you to everyone who’s helped out in the issue queue so far, I’ll do my best to keep on top of it from now on…

I just wrote a fun little bit of code for answering a question on our Danish Drupal community site.

The user in question wanted to add different CSS-files, depending on the type of the node used as the main page content, and I just wanted to share a little bit of code demonstrating how much can be a achieved very easily with Drupal’s very flexible theming system.

So with no further ado, here it is:

1
2
3
4
5
6
7
8
9

/**
  * Override or insert variables into the node templates.
  */
function craftsmen_preprocess_node(&$vars, $hook) {
  if ($vars['page'] && // The node is the main page content
      $vars['type'] == 'side') { // Node type is 'side'
    drupal_add_css(path_to_theme() . '/node-side.css', 'theme');
  }
}

And in the example here, ”craftmen” is the name of the theme (the one used on Reveal IT, actually), and ”side” is the node type (it means “page” in Danish.).

So, I finally got around to upgrading my personal blog to Drupal 6. This was my first Drupal site, started almost two years ago, as I remember it on Drupal 4.7 beta-something. It also has some content imported from my old Joomla! sites, and has gone through countless revisions.

A lot of modules have come and gone on this site, and there was a lot left to clean up, so it took a while. Flexinode, image.module, links.module, img_assist, all methods for doing stuff I used in the past, but I think I managed to get rid of most of the cruft. One of the most troublesome is the fact that I have a lot of input formats by now. Originally, I think I used TinyMCE. Then plain HTML. Then an extenal client to Blog API. Then Textile. Then plain again. Then, finally, Markdown. This is one of the messes I have yet to clean up, reformatting all my old content to use Markdown.

So with all this database cruft and past errors, I hit quite a few snags while upgrading. I’ll have to spend some time figuring out whether it’s just my crusty old database or bugs in the upgrade code.

Nevertheless, I’m very happy with the upgraded version, but there are a few outstanding issues:

• Typogrify is still MIA for Drupal 6. I miss it already. I’ll have to see what I can do to help the porting effort.
• The gallery has been converted from image.module * to CCK, Views, and ImageAPI/Cache/Field plus Thickbox. The basic stuff works, but I’d like to tweak it a bit more
• Converting all my content to Markdown.
• Sorting out whether my upgrade problems were bugs.
• Image block

Also, thanks to Sungsit Sawaiwan for creating the theme used here, Colourise.

And of course, tonnes of thanks to Dries and the Drupal community, in whose mighty company I shall not now feel ashamed. (since I now run my blog on Drupal 6 like a good Drupaller).