August

I spent most of this week banging out a contracts request, approval, and tracking system. Most of the tools were readily available in Drupal and just needed some modifications to meet specific business rules. I tried very hard on this project to do things "the Drupal way": override instead of edit, no logic in the theme layer, etc.

Here is a quick module for Drupal 5 to allow you to drill down on your top errors and see what their top referrers are. In this way it should be easy to find where the problems are coming from so you can fix them.

Needs documentation and testing, but the options to drill down show up under admin/logs/page-not-found/drill and admin/logs/access-denied/drill.

I spent some time today reworking the ecard module, knowing I'm going to need something similar at work. The main changes are:

• A few more configurable language bits, like the thank you message.
• md5-based URLs of the form ecard/view/message_hash/pickup_hash.
• A tracker that records sends, recipients, and pickups so you can tell which ecards are most popular.

http://drupal.org/project/revisionary

I got my drupal.org CVS account today, and created a project for revisionary. It's exciting to be able to offer back something that others may find useful. As part of the process, sadly, I fat-fingered the word "module" and created a new directory at cvs.drupal.org; "contributions/moudles/". I have some support requests in to fix it: hope they come through soon :/

I needed to allow revision viewing and reverting (but not deleting) for only one content type (a wiki). The solution turned out to be in hook_menu and module weights, and overriding Drupal's menu structure for the revisions of wikis.

In an effort to reduce clutter on the average user's node creation form, I wanted to hide the formatting tips when TinyMCE was active. There's little reason for them to see Web page addresses and e-mail addresses turn into links automatically. etc. when they have a nice wysiwyg running already. Turning the editor off, however, should bring the tips back.

I figured a way to create per-organic group specified forums, with no extra modules needed*. You will, however, have to apply this patch. It gives Views more respect for the $group placeholder. I am not using the core Forum module, but would be interested to see if this worked with it.

I developed this because I was worried about my users understanding the OG Taxonomy or OG forum modules. With this, they only see a few extra text fields when defining their group, and a pull-down when creating their topics.