modules

Wow, long lapse in posts there. Sorry folks. On with the show:

Here's the problem. The Drupal security team do a fine job, following up on reports, auditing contributed modules with a point release to check for security weaknesses, working on core. It's all good, except for one thing:

Contrib release process.

Today I found an article about password usability, which suggested that showing users what they type for their passwords is an improvement to usability.

You can try a working demo, which adds a 'show password' checkbox.

This had me wondering whether this is a feature we should consider having in Drupal.

Checkout view being currently disabled in ViewVC is a very good opportunity to remind everyone that linking to your README.txt file in CVS does not count as documentation on your project page!

Here are some things I, or anyone else, can do with a proper documentation page in what used to be called the handbooks section of drupal.org:

• Correct it.
• Expand on it.
• Clarify things for newbies.

Edit: Please read this blog post, but also please jump in on this thread - the idea is already proposed but needs community support:
http://drupal.org/node/484034

And so again today it happened, as it does so many days. Someone needs to be able to do something. They Google. They search Drupal.org. They find nothing but a few open issues or an unsuitable/unsupported contrib module. They're a developer, so after an hour of searching they think "ach, to hell with this - I'll just write something".

I'm just finishing the first phase of a job using the GMap and Location modules in tandem (along with Views) to create assorted location maps driven by the Google mapping API. I have to say, the last time I tried to use these modules it was about a year ago in Drupal 5.x and it was a struggle.

You probably know about dependencies in modules and how to declare them in a module's .info file. In case you're not familiar with the concept, it looks like this:

(Slightly different in Drupal 5.x - be warned!)

Each one of those modules must be enabled before Drupal will allow you to enable the module you want to install. Neat, huh? But there is a problem:

For those of you unfamiliar with the ImageCache module, get familiar here:
http://drupal.org/project/imagecache

It's pretty useful, allowing you to define preset image sizes that will be automatically generated whenever an image is uploaded to your site (providing the module doing the upload supports ImageCache which, fortunately, most do - including the Image module and the frighteningly useful ImageField CCK module).

I'm in the process of updating my training materials for various Drupal courses I teach so they reflect the new Drupal landscape, post Drupal 6 launch and wide acceptance. One of the interesting things is the number of killer modules in Drupal 5 that have died (either the maintainer lost interest, ran out of time or found a Drupal 6 module that does the same job better).

Note, Actions and Triggers are core in Drupal 6.x so this only applies to Drupal 5.x if you are using the Actions module as a 5.x contributed module:
http://drupal.org/project/actions

If you are using Triggers in Drupal 5.x then you have probably installed something like the Node Triggers module, which allows Actions to be triggered on node-related events (using hook_nodeapi()):
http://drupal.org/project/nodetriggers

These days, now the Update Status module is core in Drupal 6, people find themselves updating their core, modules and themes far more regularly than before. This is, of course, a very good thing. I'd just like to raise a couple of points of order on the matter:

When updating it is always tempting to copy the contents of the downloaded tar file straight over the existing module or theme. Don't! It is entirely possible there are files with the old version which are not required by the new one. Worse, they may even do some harm.