There's a module for that! (and if there isn't we'll build you one)

Here's a little action I wrote recently, to automatically populate a specific YouTube playlist as new videos are being posted to a Drupal site, using modules Trigger or Rules. The same concept can also be used retroactively on existing content, using Views Bulk Operations: select all existing video nodes and apply the action to them.

The aim of Drupal architecture is to implement the logic demanded by the application while resorting to a minimal amount of new code written. Modules are used as logic blocks that are assembled to yield the desired software structure that will acquire, store and display the site's content.

Coding for Drupal involves mainly creating reusable modules that implement specific logical manipulations of information. The crucial reason why this modular approach works in Drupal is that each module exposes hooks that allow other modules to extend its own functionality.

Originally published at OpenCraft

Using the CCK + Views platform, we can replicate the traditional ER (Entity-Relationship) framework into a rapid application development environment that minimizes procedural and SQL programming by replacing most of it with "Visual ER programming": a way to specify data model and behaviour in terms of SQL-like abstractions directly inside the runtime Drupal environment - and reaping the benefits of incremental, always functional output.

ER Modeling

ER modeling deals with defining entities and relations among them.

Originally published at OpenCraft.

Google Spreadsheets are cool, but their problem is that they are hosted at Google instead of in your intranet portal. That means that they don't integrate easily with your other Web documents, in terms of classification, indexing, permissions, etc. The API provided by Google does help there, it's true. But what about adding new features? Google Docs simply isn't open source, and therefore is not ideal.

Actions are a convenient way to package functionality in reusable chunks that can be called upon specific events. Countless modules expose actions, and at least the following consume them:

• Trigger
• Rules
• Workflow
• Views Bulk Operations

I found it useful to manually call actions in the business logic as well, typically during form submissions or in hook_nodeapi.

One of the useful Web patterns I've been noticing has to do with item lists and bulk actions. Given a list of items, add a checkbox in front of each item, and let the user select an action to be executed on the checked selection. Specifically, I've seen it in phpMyAdmin, Mantis, and Google Mail.

UPDATE: The comment by jtsnow resolves the general problem of overriding theme functions in a module using hook_theme_registry_alter(). Woohoo! But the specific problem described below to override the rendering of menu items remains.

I am trying to instruct the menu system to display each item's description underneath the item text, in a smaller font. I located the theme_menu_item() function in menu.inc that currently performs this task.

"Install profile" is a really awful name, don'tcha think? I prefer "Drupal distro".

Here are some distros that I would love to work on:

Originally published at OpenCraft.

What happens if you need to open a file with fopen, but find that your function can exit at multiple points? It is tedious and error-prone to call fclose at each exit point. Alternatively, you could re-structure your code to only exit at the bottom, thereby calling fclose only once, but you would end up with many nested blocks that hamper readibility and are generally considered bad programming style.

A technique I like to use in those cases is the Automatic Resource Destructor.