drupal

New Year - New Theme

no comments

Hey! I have a new theme!

The theme was designed and implemented by Sam in her spare time. She spent a lot of time getting even the littlest details worked out and I'm super grateful for all her work on it. So thank you Sam, you really are awesome!

My blog runs on Drupal 6, though up until this past summer it was running on WordPress. I use this site to experiment with ideas and mostly just play around with it, so occasionally you may get a php error or something, please let me know if you hit one.


A screenshot of the blog, for those stuck in RSS

Over the next little while I'll be posting about individual hacks and modules I've added to the site. Currently, one of the cooler features is that I get an IM on my google talk account every time someone comments. This is using the XMPP framework with some patches I've submitted, more on that in another post.

If you're looking for a Drupal developer to do some work for anything from theming to a full Drupal website build, please feel free to contact Sam. I strongly recommend her.

Creating Custom Triggers in Drupal

5 comments

So after playing around for several hours tonight trying to build my own custom trigger I think I've finally figured it out. I thought I'd post it here for reference.

Though triggers are included in core in Drupal 6 it seems they're very poorly documented. The extent of the documentation I could find was on this trigger page in the handbook. Pro Drupal Development also has a chapter on it but unfortunately isn't really explicit enough for me with some parts.

Disclaimer: I don't really know what I'm doing, so please let me know if I've done anything wrong.

What I want to do is create a custom trigger in my module. Let's say I want to execute a custom action on my server whenever a node of a type script (as defined in the 'script' module) is created. The first step is to define hook_hook_info.

/**
 * Implementation of hook_menu_alter().
 */
function script_hook_info() {
  return array(
    'script' => array(
      'script' => array(
        'code_entered' => array(
          'runs when' => t('After script is created'),
        ),
      ),
    ),
  );
}

This will create a new tab in my triggers page that will be named after the name of my module as set in my .info file.

Two things I still need to do to make sure this trigger actually does anything... define hook_script and call it from a module_invoke or module_invoke_all whenever the triggering event happens and call the actions using actions_do(). Since these hooks should be executed on node insert I'll need to use hook_nodeapi().

/**
 * Implementation of hook_nodeapi().
 */
function script_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
  switch ($op) {
    case 'insert':
      module_invoke_all('script', 'insert', $node);
      break;
  }
}

The second aspect (calling the associated actions) requires an implementation of hook_script() (the alternative being to just replace the module_invoke line with this functions body.

/**
 * Implementation of hook_script().
 */
function script_script($op, $node) {
  $aids = _trigger_get_hook_aids('script', $op);
  $context = array(
    'hook' => 'script',
    'op' => $op,
    'node' => $node,
  );
  actions_do(array_keys($aids), $node, $context);
}

The first line in the function is a call to _trigger_get_hook_aids which returns the list of action ID's that have been assigned to this trigger. This is a private function, but seems to be the only way to get the list of actions. The last line in the function calls actions_do(), which processes all the actions assigned to this trigger.

And that's all there is to creating your own custom triggers.

Alternatively, I don't need to create a hook for the trigger, instead I could just piggyback off of the nodeapi hook, since this is a node operation.

The hook_hook_info looks a little different with:

function script_hook_info() {
  $info['script'] = array(
    'nodeapi' => array(
      'script' => array(
        'runs when' => t('After script is created'),
      ),
    ),
  );
  return $info;
}

And then just a slight change to hook_script() to change the hook from 'script' to 'nodeapi'.

/**
 * Implementation of hook_script().
 */
function script_script($op, $node) {
  $aids = _trigger_get_hook_aids('nodeapi', $op);
  $context = array(
    'hook' => 'nodeapi',
    'op' => $op,
    'node' => $node,
  );
  actions_do(array_keys($aids), $node, $context);
}

One other thing that was bugging me with triggers was the inability to only use them on specific cck types. There's no way to setup a trigger to only get called when an event happens to a single content type (without using the workflow module, which I found has some problems using variables in actions). Put an "if ($node->type == 'script')" somewhere appropriate, in my code I'd wrap that around the call to module_invoke_all().

----

After writing this I found this blog post which also looks quite useful.

DrupalCon Szeged 2008 Fast Approaching

no comments

drupalcon hungaryWith just over one week remaining, Drupal's bi-annual conference is fast approaching. This time around the conference is being held in Szeged, Hungary. I'm no expert, but this could be one of the most exciting things to happen to the city since the birth of one of NowPublic's own developers, Peter Galiba.

Drupal is a web development framework and content management system. It's the base of the NowPublic website and quickly growing as one of the most popular CMS's on the web.

With just shy of 500 registered attendees, this will prove to be the largest European DrupalCon to date. There will be over 50 sessions in 4 tracks over the 4 days of the conference. Rasmus Lerdorf (creator of PHP) will be giving the Keynote for the conference. A lot of the sessions look interesting, but a few of the ones I definitely plan on attending are:

I hope to be posting updates and photos as the conference progresses, so stay tuned :). I'll be tagging everything with drupalcon and drupalconszeged2008.

(re-posted on NowPublic.com)

DrupalCon Boston 2008 - Some Sessions

no comments

Just for fun... I thought I'd put up a list of a few of the DrupalCon sessions I'm excited about. I'm going to try to blog daily and maybe post photos daily too. I was also thinking... since it seems to be getting popular to take pictures of people taking pictures, I'm gonna try and take as many pictures of people taking pictures of people taking pictures as possible.

Monday 9:30 - Drupal Multimedia (Presenters: Aaron Winborn, James Walker, Darrel O'Pry, Nathan Haug) - "This session will guide you through the steps necessary to build image, video, and audio into your sites."

Monday 1:30 - Mapping business requirements to Drupal modules: a gap-fit process (Presenter: Boris Mann) - "Join me to talk through a process of building repeatable processes in selecting modules and implementing a gap-fit analysis of which modules your new Drupal project is going to need."

Monday 3:30 - OpenID and Identity in Drupal: the future of user.module (Presenter: James Walker) - "This session will not be why OpenID, but rather what’s next with OpenID."

Monday afternoon NowPublic will be at the job fair, so drop by and say hi! :)

Tuesday 9:30 - The Future of Fields (Presenters: Barry Jaspan (bjaspan), Nedjo Rogers (nedjo), Karen Stevenson (karenS), Larry Garfield)

Wednesday 9:00 - SimpleTest: Because clicking on forms is for suckers (Presenters: Angela Byron (webchick), Rok Zlender, Karoly Negyesi (chx), Jimmy Berry (boombatower))

There's plenty more... but I think this is a good start.

And now I'm off to the airport.

EDIT:

Missed one!

Wednesday 9:45 - Practical jQuery - how to act like you're JavaScript-smart (Presenter: Dimitri Gaskin) - Dimitri is Drupal's 12 year old developer. I'm really looking forward to watching this presentation.

Drupalcon - part 2... testing

3 comments

There were a lot of very interesting sessions at Drupalcon, 4 full days packed with them in fact. Some of my personal favorites were openid, form api 3, panels 2, and the Drupal association panel. One of the things that really stood out (and I also really enjoyed) was the configuration management discussions. A decent percentage of the talks covered or had some overlap with configuration management and testing. Automated testing is a huge issue for "Enterprise" Drupal right now. There's not really a "safe" way to upgrade a Drupal site at the moment. A major upgrade pretty much goes as follows:

  1. backup
  2. upgrade the code
  3. update the database
  4. cross your fingers
  5. tap your toes
  6. hope it works.
  7. repeat if necessary (*always* repeat if necessary ;-))

Once you've upgraded you can manually go through the pages and try to find any glitches in the site, and if you're lucky you'll get them. Maybe the users of the site will find and report the errors. If you're lucky you won't lose any data. There's currently no unit testing, regession testing or smoke testing (sure, there's some test code... but as far as I'm concerned the amount that exists is really only proof of concept that it can be done). There's roughly half a dozen companies that put the majority of paid development into Drupal and are also hiring up most of the good Drupal developers. These companies have a vested interest in getting automated testing working in Drupal.

At one of the more ad hoc sessions (which included people from most of the big Drupal comapnies and prominent community members) NowPublic promised a large chunk of one of their developers' time to work exclusively on writing unit tests. There was obviously a lot of support for this. This session was more or less a discussion of how to approach the problem and solve it and I think some good ideas and points came out of it.

Writing tests is a bitch. I can say this as I use to write *very* extensive tests for code I wrote (python has some very nice tools for unit testing that I miss in almost every other language I use). The test code can often be significantly larger than the code it's testing. It was kind of fun at first, but all the typing and copy-and-pasting quickly started aggrevating the carpel tunnel ;). Writing the tests is the easy part. Keeping the tests up to date is the tough part. Getting developers to keep improving the code at the same rate while forcing them to write and update the test code on a mostly volunteer project... I don't even know if that's possible.

There's a popular idea in the Drupal business community that if you develop something, give it back to the community and let the community maintain it. I think this works great for both the companies developing Drupal and the volunteers working on the project. Keeping their code a secret hurts both parties. Let the company pay for the initial development of the code, and if there's interest someone will pick it up. Unfortunately, I don't see this working for testing. Even if the initial set of tests is paid for, I really can't see the "community" picking up the maintenance of the tests. It's a bitch, and doesn't scratch enough peoples' itch.

Regardless, automated testing in Drupal will be a Good Thing. And what do I know, maybe volunteer developers will be totally into keeping the test code up to date. "All tests passed" messages make people feel warm and fuzzy inside :).

One last point... since I'm in a ranty mood. This is to the person who likes to preach "...every time you touch a contrib module ... run coder module ... write and update simpletest tests ... yada yada". Perhaps it's about time you put your money where your mouth is and start getting your own developers to do it. :-p

Syndicate content