Blogs

A few days ago, Michelle blogged to announce Author Pane (a glue module) and took that occasion to complain about the circumstances that made it necessary.

In a nutshell: Some modules could work very well together, if only one of them contained the required hook implementation. Nobody felt up to putting the code into their module.

Finally, I had enough. [...] So, grudgingly, I decided the only way out of this was to create a third module.

I experienced something vaguely similar a while back with a contrib module of my own, DHTML Menu, although that case hinged more on a conflict between two modules (I18n Menu) than on a glue feature.

It is a big logical leap to generalize from two occurrences to a trend, as the system has obviously worked for years. Still I can't help but theorize that this has a common cause: As long as modules work on their own to extend core, everyone knows where they stand, but try to get them to work together, and the development process hits a dead end: Where should the code go?

Neither developer wants to implement someone else's hooks if they're not directly dependent on the module. It's not simply some stupid ego issue ("Why should MY mighty module code for YOUR lousy module's API?"), but a problem of (plainly speaking) convenience. Drupal APIs are fast-changing, and contrib is even worse than core. Implement an API today, and you get to re-implement it tomorrow. Not something developers happily volunteer for. Nobody wants to have to acknowledge another module's existence in their own code - especially a module only tangentially related to theirs, or one they don't use themselves ("scratch your own itch").

The easy solution here is to make a glue module that implements both, but this module still needs to go somewhere specific: Do you put it into one of the two existing projects (which)? Or do you have to clutter the project namespace (as here) with a separate project that contains only glue code?

I can only conclude that the infinitely extensible modularity of Drupal works great on the code and usability side, but clashes with the "project ownership" mentality on Drupal.org. Perhaps it would help to open up sub-module creation to all developers (in the form of a "contrib" folder in every project to imitate "translations")? Or perhaps such things just have to be decided in face-to-face meetings at Drupalcon: "Heads says I implement the hook, tails you" .

This is just a notice of a bugfix update to XBBCode, my light-weight stack-based parser for customizable and extensible BBCode in Drupal.

I have been developing the module for two years now and using it on this blog for almost as long (see earlier posts), so I've had lots of time to work out most of the bugs.

It can be downloaded here:

http://ermarian.net/downloads/drupal-addons/xbbcode/xbbcode-6.x-1.1.1-r3...

It is also still available on SVN:

http://svn.ermarian.net/drupal/modules/xbbcode/trunk/xbbcode/

As a webmaster who uses open source web applications, you frequently have to download software updates. Web software is susceptible to security flaws that must be patched quickly, and even when bug-free it is improved constantly.

If you operate a lot of sites on the same software, you run into a very annoying problem: Every site needs its own codebase. For five MediaWiki sites, you will unzip the same MediaWiki package five times, update it five times, possibly hack your own modifications in it five times, and need five times the diskspace.

Practically no CMS software (apart from Drupal, and arguably Typo3) is tailored for power users. They all assume that the codebase is equivalent to the site, and do not allow multiple sites using the same code.

Drupal shows that multisite support is extremely simple: Just use a sensible algorithm to convert URLs into folder names of varying specificity, then include the most specific settings file that matches the current URL. In fact, this idea is so beautiful that I decided to steal it.

To generalize the concept of multisites, you need the following things:

• a sites/ subfolder in the software installation, where all site settings folders are contained.
• a standard configuration file where the software expects it, which determines the active site and includes the appropriate settings file.

It's basically the concept of Apache's "virtual hosts" applied to PHP software.

First, I have the multisites.inc file, which contains the algorithm that finds site folders by the URL. This is basically cribbed from Drupal (with some modification), which means it follows the following priorities:

Here is the code:

<?php
/**
 * determines the active site by URL and returns 
 * the folder the settings file is in.
 * settings file and site directory can be customized, 
 * default is "settings.php" and "sites".
 */
function multisite_load_conf($conffile = 'settings.php', $confdir = 'sites') {
  static $conf = '';
  // If for some reason the conf file is loaded again 
  // in the same request, save some time:
  if ($conf) return $conf;
 
  // When running an update script from the command line, allow an alternative:
  if (empty($_SERVER['HTTP_HOST'])) {
    foreach ($_SERVER['argv'] as $i => $arg) {
      if ($arg == '-site' && $i+1 < count($_SERVER['argv'])) {
         $conf = $confdir . '/' . $_SERVER['argv'][$i+1];
      }
    }
    if (!$conf) exit ("You are running PHP in a command line. 
            Multisite requires '-site <confdir>' as an argument.n");
    return $conf;
  }
 
  // Start with the path and the domain split into tokens
  $uri = explode('/', $_SERVER['SCRIPT_NAME'] ? 
              $_SERVER['SCRIPT_NAME'] 
              : $_SERVER['SCRIPT_FILENAME']);
  $server = array_reverse(explode(':', rtrim($_SERVER['HTTP_HOST'], '.')));
  
  // Strip sub-domains from the left, and folders from the right.
  for ($i = count($uri) - 1; $i > 0; $i--) {
    for ($j = count($server); $j > 0; $j--) {
      $dir = implode('.', array_slice($server, -$j)) 
                 . implode('.', array_slice($uri, 0, $i));
      if (   file_exists("$confdir/$dir/settings.php") 
          || (!$include && file_exists("$confdir/$dir"))) {
        $conf = "$confdir/$dir";
        return $conf;
      }
    }
  }
  $conf = "$confdir/default";
  return $conf;
}
?>

Then, in the normal config file ("LocalSettings.php" or "config.php" or whatever) you just need the following code:

<?php
require_once 'multisites.inc'; // or wherever you put this file.
$settings = multisite_load_conf(); // adjust default file and folder names as needed.
include_once "$settings/settings.php"; // but first make sure it exists to avoid errors.
?>

The actual config file for the site has to be moved to the proper site folder. Needless to say, any software that generates this file automatically may cause you some trouble when installing. Yet compared to the strain of keeping several different codebases up to date, this trickery is very much worth it.

I use it with MediaWiki and phpBB successfully, and it should work with any software as long as it does not try to place static files into a hard-coded location within its own installation directory. If it does, you will need to hack this hard-coded value to allow it to be configured.

I have taken my old morse code converter and fixed it up with AJAX. With the password generator I built some time ago, I managed to come up with a neat little framework for standardizing AJAX handling on my pages, including a little throbber bar.

In time, this AJAX improvement will happen to all the old utility scripts on the Ermarian Network. Currently a lot of them are in various states of disrepair, mainly because they weren't built E_NOTICE-compliant and now spew notices all over the place.

As of a few days ago, I am using PuTTY. In the years before, I had been using an extremely outdated non-commercial-use version (2003) of the client sold by SSH Communications, so this is the final part of my software suite to switch to Open Source.

Mostly, I've simply avoided it due to inertia. This was the client that I found on Google four years ago. Since then, whenever I needed my SSH client, I was in kind of a hurry, because obviously I had to do something on my webserver, and pronto. Now, I just migrated to a fresh system again (still XP, though, not Ubuntu), and had to download all my essential apps again: Browser, mail, calendar, media player, text editor, and of course the shell client.

Hesitating a bit, I decided to give PuTTY a go, and see how far I could get without a manual.

It turns out that (big surprise), it is far superior to the ancient program I used before, supporting RSA authentication (no password), a nicer interface that actually clears the screen once I'm done using vi, and it's crazy fast. I had thought that the .5 second response time was unavoidable when sending each new keystroke from Germany to California, but apparently not. Instead of timing out after a minute of inactivity, the connection only drops when the computer enters Standby.

So in summary, I should have switched far sooner, and I'm glad that my remote shell almost feels like a local one now.

In a video, Ayman al-Zawahiri, deputy leader of the terrorist network Al Quaeda, "accused President-elect Barack Obama of betraying his Muslim roots."

See what the campaign lies have accomplished? Obama's supposed Muslim faith is now so widely believed that even the extremists think he should be one of their own.

What gives?

This message contains a rich-text HTML portion. Consult your mail client's documentation for infomation on how to view it.

This is what greets me and every email user of a plain-text-only configuration whenever a poorly written list-mailer sends us HTML email. It is the result of a brilliant content-negotiation protocol being implemented by stupid people.

Now, first of all, I admit that I am heavily biased against HTML email. Unlike the multi-media interactive web, nearly all of the information in emails (or the ones I get) is text-based. I get only one type of email that must be viewed in HTML, and it's the Dilbert strip - it being difficult to convey cartoons in plain text.

But that's a matter of personal taste, and such matters are best left to individual choice. Lo and behold, the standard allows for exactly that: Sending your email in multiple content types to allow the receiving client to pick which to display. Instead of sending text/plain or text/html, your message can be sent as multipart/alternative with a separate segment for each content type.

Now, not everyone makes use of this neat standard, which is okay. Thunderbird will automatically remove rich-text markup from HTML emails and render them in plain. Others support the standard and send both a plain text and a HTML version.

Still others, and these are the real geniuses, send a plain text part that only tells you that plain text is not supported. If they simply sent an HTML mail, Thunderbird would have no problem with rendering the information - but this way, I don't get the information at all.

So here's a hint to everyone writing an application that sends HTML email: If you're going to use multipart/alternative, you had better send a text part that actually is an alternative, instead of some silly message. Otherwise you're no better than the "IE/Javascript/Frames required for this website" people.

"Scratch your own itch" is one of the mottos of the open-source movement. And this evening, I had one monstrous itch.

If you saw this blog more than a week ago, you'll remember that I only recently cleaned it up from a horrible mess and upgraded it to Drupal 6 at the same time. Since then, I've found numerous small ways to improve it. For the most part I use widely available addons (archive, tagadelic, adsense, agregado), but I freely hack away at them when I need more functionality.

For example, you may notice that when you are on an older post from October 2007, the calendar block to the right will show October 2007 instead of November 2008 - it doesn't do that out of the box. The tag cloud shows tags from both vocabularies, both the freely tagged "keywords" and the strictly hierarchical "news category", which required some extra code as well.

{{image_flow.png|right|200px}}But to get back to the itch above, I was really annoyed with the poor image attachment support. I can attach image files to every post, but they will be displayed below the text - to add them in the text itself, I have to enter specific HTML after I've uploaded the images, and this HTML will break if the site ever moves anywhere else, since it references internal paths.

~ ~ ~

What I started out with was a contemplate template that was intended to replace internal placeholders like the below (wiki-like syntax) with appropriate HTML to add the image in a floating box.

{{image.jpg|right|100px}}

Then I realized that I wanted to generate thumbnails server-side, and the template very soon spilled over into its own module. And so I can now, after an evening of coding, present Image Flow.

{{druplicon.small_.png|left|100px|noresize}}Image Flow hooks in at the "alter" (final) stage of hook_nodeapi. It checks your node for the content of CCK imagefield fields, then scans for placeholders like the above to replace them. Images get automatically scaled to the proper dimensions, and added as a floating box on the proper side within the text.

Then - and this is what I'm most proud of - the full-size image can be viewed in a box that fades in when you click on the thumbnail, Lightbox-like.

Image Flow is barely ready for testing, let alone release, but a version for Drupal 6 has been attached to this post. You can also check it out from my SVN repository:

svn co http://svn.ermarian.net/drupal/modules/image_flow

If you do not want an image to be enlargeable (for example, a software logo that offers no additional information in full size), the extra option "noresize" will cause the thumbnail to be shown without any full-size link.

Yesterday, I promised an update regarding my change of media players once I had tested the open-source player Songbird a little. I was very enthusiastic about the new application, mainly because I was happy to be well-rid of iTunes - but even so I did not expect this.

Songbird is a XUL application, like Firefox and Chatzilla. XUL is a new definition language for user interfaces, developed by Mozilla. I've found that applications using it are very fast and smooth (on my system, anyway), so I was really happy to see Songbird is one of them.

{{songbird.png|right|200px}}Hilariously, Songbird has a built-in web-browser of its own, making its user interface an interesting mix of Firefox and iTunes. You start with the standard table library view with the Playlist sidebar like iTunes has, but new tabs can be opened with Ctrl+T. The best part is that these tabs can of course also contain views of the Songbird library and different playlists, meaning that another annoyance of iTunes (having to switch back and forth between playlists) is taken care of. I rather like the different skins available for Songbird as well.

And finally, after years of mangling the sound of my Myst and Riven tracks, it is bliss to hear them sound as they should. No more rattling on the low notes. In summary, I'm very happy I switched.

Scott Gilbertson on WebMonkey heavily criticized the iTunes media player, and I found myself deeply in agreement.

{{itunes-logo.jpg|right|200px|noresize}}When I began using iTunes in 2006 (according to the first file added in 2006-08-25), it was a vast improvement over the alternatives I had tried:

• Windows Media Player frequently froze up, tried to call home without telling me, and (much like Internet Explorer) is altogether too cozy with Windows.
• WinAmp was Shareware, and made sure I didn't forget it.
• I didn't have any others, because iTunes was the third player I installed, upon falling in love with it.

Back then, when I started it, it launched instantly. It didn't freeze up, nor stutter on MIDI files, nor take two minutes to load. And back then I had 256 MB of RAM, rather than the 512 I have now.

Nowadays it is amazingly slow for something I expect to do nothing but organize my files, play them on command, and shuffle them when I need some background noise. And it seems like every button you click attempts to lead you to the iTunes store, which I never even use: I buy my music in uncompressed form on old-fashioned Audio CDs, so I don't have to deal with DRM telling me how often or where I can play the stuff.

The climax of my strained relationship with iTunes came a few weeks ago, when after a messy inadvertent downgrade the player just refused to start up, re-install, or de-install. It took me a full week of seeking online assistance (unsuccessfully) and two hour-long dives into the registry to dig out the program and re-install it. Obviously, favoring iTunes instead of WMP to avoid lock-in backfired royally, as iTunes messes with the registry just as badly.

{{songbird.jpg|left|200px|noresize}}This was the last stroke, and after reading the article I linked above, I realized that I don't even have an excuse for using iTunes. That's right; my player is a third-rate, ancient Trekstor i.BeatJoy that is essentially a 128MB memory stick with mp3 function; my cellphone is a Motorola that I basically use only for phoning, so I'm not locked in by any sleek Apple gadgets. My relationship with iTunes started nicely, but in the past year it has become increasingly abusive, and nothing stops me from leaving.

And as soon as I realized this, I went and downloaded SongBird. Bliss will soon be here. I'll write an update when I have managed to migrate my library.