webschuur.com

A handy snippet for module developers that use external libraries. Drupal discourages inclusion of such libraries in modules, for good reasons. This, however, makes is hard for admins to install your module. I used hook_requirements to point out how, why and where a certain library can be found.

The admin is then helped with usefull messages: how to fix the problem.

Drupal’s block system is far from ideal. It was designed back in the threecolumn-era, was improved to work beyond three-columns-content-in-middle layouts, but is still unsuited for more complex layouts.

If you want real complex layouts, you will have to turn to Panels, or Panels2. Or so they say.

A client of mine, a large Dutch media company uses Drupal for all its new sites -about four, five each month-, and untill today used panels in these sites.

So, there is a good thing you, as non-coder can do: clean up your mess :)

Submitting issues is a good thing. Without that, there is hardly a way to improve a piece of software; after all: the only relevant test is real use.

I have been maintaining many Drupal modules for years. And I tend to give out CVS access to other people I like, trust or think are good developers.

Still maintaining a module is hard work. Today, after nearly four weeks, I went trough a backlog of open issues on various of my Drupal modules. And here are some rather disturbing numbers:

Svn has a very useful concept, called externals.

The idea, in a nutshell, is that you include code from another subversion server (and repository) into your own subversioned project. Instead of simply copying the code into your project, you link to existing code. That way you simply update remote projects, when working from thirdparty development releases (that library the other team is developing on the sidetrack), and/or switch to new or stable versions when they are released.

Because I decided to try Remember the milk again for my Getting Things Done thingies, I had to import all my stuff from vitalist.com.
In order to do so, I hacked together a dirty Ruby script.

It may help someone who is trying to achieve the same.

Most people develop and maintain their contributions in the last branch, effectively ignoring HEAD.
I have done just that for the last two releases, but chose to take the normal HEAD approach back again.

The reason is simple: I don’t want my development snapshots to be used by people who are not developers. I hope I can bring down the amount of support and bug-reports and increase the amount of real patches this way.
Obviously patches that apply and count only for a certain branch will be applied there. But I will try to keep HEASD as up-to-date as possible.