Here's something interesting to keep in mind the next time you're getting fancy with your nodes during the hook_nodeapi presave step: Don't forget your teaser.

I was having trouble with a Drupal 6 website I've been working on, where it seemed almost as if the body was duplicating part of itself (or sometimes all of itself) on the edit - it looked fine when you were viewing the node, but editing it caused things to duplicate within the body field. I tried the usual suspects for fixing - I searched for nodeapi calls inside of the custom modules we'd written to find the culprit, and then even just started turning off modules, and the theme, one by one, hoping to find the culprit that way.

One of the interesting new opportunities - and thus pitfalls until you understand them - is Drupal 6's built in block caching. As a developer, I'm generally used to creating hook_block by just specifying the 'info' data in hook_block, and letting the other options be set by the admin via the blocks page. However, you can't set the caching level there, and more troublesome, you can't change the caching level of a block once it's been put into your site.

One of those little annoyances when working in jQuery and Drupal is the inability to grab the base_path() data. You wish it were available in javascript... but it isn't.

But if you put this:

right before you call drupal_add_js to load your own personal javascript, then when your script is run the base path will be available as Drupal_base_path.

And that makes things a lot easier to deal with!