webschuur.com

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.

iDeal is a Dutch, online payment system, widly adopted, but hard to implement.

In Drupal there are several iDeal implementations for übercart, but none are very solid and none are easy to implement. Moreover: the iDeal übercart implementations lack some error handling, which may not matter for smaller sites, but for large payment flows, this is far from ready.

Git Cola provided a very nice dialog explaining me how to improve my commit message:

A good commit message has the following format: - First line: Describe in one sentence what you did. - Second line: Blank - Remaining lines: Describe why this change is good.

I did some additional research and found some good other guidelines. from stack overflow

Unless I missed a feature entirely, Drupal Localization Server does not really allow packages from external sources to be parsed in its “local package connector”. It only eats tarballs with the exact names as they are released from Drupal.org. For example tagadelic-5.x-1.2.tar.gz and nothing else. Well, off course the 5.x-1.2 can vary.

I therefore hacked up an ugly script that we run in a cron to grab our REL-5.x-1.1 from our SVN. Our subversion repository-layout is rather hardcoded in the script, but since it is not that exotic, it should be easy to change it. This script runs over a loca working copy of our SVN and grabs the tags (aka SVN releases) and then tarballs them with the filenames that the local package connector will recognise.