When to Roll Your Own Module (or not)

Today I added a tiny new feature to this website. Basically, I wanted a way to add a 'tweet this' link to posts of certain content types like blogs or maybe articles.

I did some searching and found that a module called 'tweet' exists. (Be Circle Rule 12 of Drupal states that if you have an idea for a module that module has already been written**). Tweet seemed to do everything I wanted, but on closer inspection I discovered it did a bit too much. The module does what it advertises, and appears to work, but it's just not for me.

What do you do in theses situations?

Clearly, if there were a bug, I could open an issue and provide a patch to help the module maintainer. But, in this case there wasn't an obvious bug that I could see glancing at the code.

If the module lacks features, once again, I could open an issue and provide a patch. But, in this case the module was too feature rich.

If I had a wildly divergent idea for a similar module with enough fundamental functional differences from the original, I could create my own project on Drupal.org and release it. But, this is not one of those times. Besides, there is already a Duplicate Module Hall of Shame and you should always think twice about starting your own project.

Sometimes, the best action is simply to write your own tiny module to scratch your own itch. In this case, roughly 20 lines of code in my own custom module gave me the exact functionality I wanted. (actually it ended up being a bit more in the end because I decided I did want one administration feature of tweet).

When do you write your own module for your site? You know your site or client's site best. Weigh the available options (existing modules) and see if you can't improve those first. If the problem you are solving is general enough write a module that you are going to share. But, if the problem is small enough and unique enough to your specific needs, start rolling your own.

If you are curious, here is a snippet of what I basically did. Remember this is unique to my site and my needs and I am in complete control of the content when this code runs.

/**
 * implementation of hook_link
 */
function becircle_tweet_link($type, $node = NULL, $teaser = FALSE) {
  if ($type == 'node' && in_array($node->type, variable_get('tweet_node_types', array()))){
    $tweet = _becircle_build_tweet($node);
    $links['becircle_tweet'] = array(
      'title' => t("Tweet This"),
      'href' => 'http://twitter.com/home',
      'attributes' => array('target' => '_blank', 'class' => 'tweet_this', 'title' => t('Click to Tweet About This Post on Twitter (Twitter shortens URLs to 25 characters)')),
      'query' => 'status='. urlencode($tweet),
    );
    return $links;
  }
}

/**
 * helper function to build the contents of the tweet to be sent to twitter
 */
function _becircle_build_tweet($node) {
  if (is_object($node)) {
    global $base_url;
    $title = $node->title;
    if ((strlen($title) + 26) > 140) {
      $title = substr($title, 0, 110). '...';
    }
    $url = $base_url . base_path() . $node->path;
    $tweet = $title. ' ' .$url;
    return $tweet;
  }
}

** Other Drupal rule books have the same rule, but include a statistic about the likelihood the module was written by @eaton

January 16th 2009 7PM
By: andre

 

Comments

Glue code makes sense

I think glue code like this is often preferable. A well commented short snippet is easily understood and usually quite stable.

If I need to debug a site I didn't build, I find it a little frustrating if they used a lot of unfamiliar modules to add features that could be done in a few lines of code. In fact, that small site-specific module often tells you a lot about the project and mindset of the builder.

But as soon as you decide to do that same thing on every site, or the snippet gets unweildy, I like to see a contrib module. And if you're managing a developer, make them justify custom code before they write it, because things can get out of control quickly.

Different than tweet in a couple of ways

The module is different in a few ways.

  1. It doesn't depend on any 3rd party API's to work. Tweet module hard codes a dependency on a 3rd party website to 'shorten' URLs
  2. It doesn't shorten URL's. Twitter will shorten URL's for you. Any URL greater than 25 characters will be tinyurl'd (therefore removing a third party dependency off your site and onto twitter)
  3. It does shorten node titles so that the 'tweet' will be less than or equal to 140 characters including a tinyurl'd link
  4. It does make use of the available node object and doesn't do any extra 'node_load'ing that isn't needed
  5. It does move display options off to the theme where they belong in my opnion

Basically, it is a very streamlined version of tweet. Like I said, tweet is 'fine' but it runs a lot more code than I want (and has admin features I didn't want) just to get a link to display. For that reason I rolled my own module.

Tweet

How does your module differ from http://drupal.org/project/tweet ??