Roughly two years ago, I prepared a diagram of the dependencies in the then-current version of Drupal e-Commerce (eC) for Drupal 4.6.

Now, with other eC projects looming ahead, a possible session about eC at Szeged, and eC 4 being in alpha, I figured it was time to update the model. Boy, has it changed ! Click the thumbnail for the full-size view.

Funnily enough, my recent post about wishes for Drupal happened just before discussion started afresh on the recurring "everything-as-a-node" theme, in which I seem to have been played the re-animator part this time.

Thinking deeper upon this issue, I figured it would be interesting to see where Drupal stands currently (in D5) regarding the reularity and orthogonality of the hook system and most visible content-related entities: nodes, comments, terms, vocabularies, and node types.

The resulting table is attached to this post (OpenDocument format), and shows some interesting results:

The release of Drupal 5 today comes at a time of the year where one makes wishes, and obviously I wish the best for Drupal, be it for our new production workhorse Drupal 5, or its hardly conceived descendant Drupal 6.

So while there's still time for wishes in Drupal 6, here is a selection of three grand wishes :

This table shows which operations are actually documented, used, and implemented, by the e-commerce ProductAPI, hook_productapi().

UPDATED for eC4 in new post

The Drupal ecommerce module suite is a rapidly evolving and quite massive part of Drupal, and newcoming developers may be overwhelmed by the sheer number of modules included in the suite. This UML dependency diagram chart should help understand how the modules fit together.

Having non-HTML-skilled contributors input content on a Drupal site seems to often lead to invalid HTML tag soup being input. And even with seasoned coders, a HTML input error happens sometimes, which can be a problem until someone fixes the post.

So I figured I'd force valid HTML from user input, and here is the proof-of-concept valid_node module: it will force any node to be saved as a XHTML fragment.

For quite a long time I'd been wishing this blog had an original theme. Not that I dislike Marvin, but I felt it was time to create my own theme, especially after doing work on adding settings to drupal themes.

Since today was bank holiday for the Assumption day, I decided I'd use it to create a theme after one of my pet peeves: white space on web pages.

The project module is at the heart of drupal.org. Here is a UML model of how it stores its data:

As of Drupal 4.7.3, project.module uses a set of tables in addition to core tables node and users. This UML diagram shows how they are logically related together.

Wouldn't you like a diagram of Drupal 4.7 with complete data types and referential integrity constraints ? Here's one.

The suggestion

Currently, various modules within core and contrib use various tables to store historical (i.e. "write once, read sometimes, never update") data. The most obvious is the watchdog table, but others exist, including accesslog, and zeitgeist's eponym table.

Logging through a unified API has the potential to reduce the code volume somehow, as all logging functions could be made one, and could also potentially be simplified to automatically record some information so that modules invoking the function don't have to write in some parameters, that could be recorded automatically.