Clean and maintainable pattern for blocks development in Drupal 6

Drupal7, has finally removed the confusing $op parameters from hooks. And replaced them with a family of related hooks instead; one hook per op.

Here is a way to achieve the same in Drupal 6; by building a simple router in hook_block().

I think everyone knows these moments: You have a problem, a question. And just by asking that question, the answer pops up in your head. It happens to me often, when programming. It is obvious: by asking the question, you have to analyze and simplify the problem. And by doing so

Today, there was another great way Stackoverflow helped me: I had a problem with a Drupal pager-query on a none-distinct SQL query. And right when I was finishing up, the answer struck me.

An answer on stackoverflow to the endless question “should I choose Drupal or Foo” gets the whole problem with many Drupalprojects in one sentence:

Drupal needs you to conform, symfony will conform to you - choose whichever you want.

I would refrase that as:

Drupal needs you to conform, a framework will conform to you - choose whichever you want.

Now, that would not be a big problem, if you have that freedom: the __freedom

Drupal is not object oriënted (OO). No really, it is not! It merely borrows some design principles from OO, and uses some design concepts (such as the Observer Pattern, or hooks, in Drupal) from OO. Though many Module developers actually use another design principle, that of Classes. When creating a module, one can borrow almost all ideas from the (good) design of classes, to create a good design for a module.

Maybe you think: “Why should I design my module”?

Attached is a simple script to backup Drupal databases in an incremental-archive-friendly way (1.7KB). Instead of dumping the database into one big SQL file, this script creates many small files; one per table. With a blacklist option to exclude certain tables. It stores the structure (CREATE TABLE statements) in a separate file too.

When testing, or developing an existing site, one often does not copy over all the filebase. A site that has been collecting uploads (such as images in blogs) for a while may have a gigantic amount of images. Often, when setting up a development environment, it is too much to keep the entire filebase in sync, even when you work on a recent codebase and a recent database.

In Drupal, this gives a lot of problems with the “file not found” handling. The default Drupal .htaccess puts 404 errors, file not found, on to Drupal.