drupal

So what does everyone think of my new surfboard? It's a custom 6'3" made by Clayton (site under construction) in Durban, South Africa, my home break. I took it for a test drive last week and it is a sweet board indeed! Very reasonably priced too, especially after converting British pounds into South African rand.

I'm currently based in London, but I'm planning a few surf trips to Indonesia and Western Europe in the near future. Look out for photos of Druplicon inside some sick barrels. I hope.

Use the coder module to save embarrassment!

On my last blog post, I threw out a one-line patch for a usability enhancement to the Bio module. Here's the line in question:

How many errors are there in that line? Many more than I expected, as dww very patiently pointed out to me:

Here's a small one-line usability fix for all module developers that I think will be a huge help to users.

In the early stages of a project, I'm often playing around with quite a few new modules: testing them, seeing if they meet my requirements, installing and uninstalling. After downloading a module, the sequence of steps is always the same:

1. copy to /sites/all/modules
2. enable at /admin/build/modules
3. configure all exposed settings
4. use!

However, sometimes just finding the settings page takes the longest time out of all those steps. Is it in User Management? Content Management? Logs? Who knows!

I'm going to use the example of the Bio module; not picking on the Lullabot team or Bio module maintainers, this one just happened to be the first example I thought of. :)

Bio's settings page is difficult to find, as it's not in "Site configuration" but rather in "User management". It also hides itself quite nicely using the title "User biographies" instead of "Bio settings", as one would expect. The readme.txt file doesn't mention how to find the settings page at all.

So what I had to do in this case, after becoming frustrated with searching for the settings in the menu, was pull up the source code and check out hook_menu() to see exactly where I should go.

And here's my suggestion: we're all used to seeing the "installation successful" messages (and looking out for php errors on install of course). For example, the Bio module has these:

What if this message held the link for the settings page? Then it's just one click away, instead of a potential 2 minute search to find it.

This is just one line of code in the bio_install() function:

drupal_set_message(t('You can edit Bio settings at ') . l('admin/user/bio','admin/user/bio'));

Seems like a small change, but if every module did this, it would collectively save me hours in the module evaluation stages of a project, because I find that plenty of modules seem to hide their settings and not explicitly detail them in readme.txt, requiring me to either hunt them down or open the source.

Since I talked about the Bio module, I've provided a patch in the issue queue. Hate to be a complainer that does nothing about it... :)

http://drupal.org/node/236187

If you're using the Devel module while developing with Drupal, you may have enabled the "Switch users" block which is great for troubleshooting and configuring permissions.

However, if you accidentally use it while your site is in maintenance mode (offline), then you may notice a problem: it won't let you back to the path "/user" to log in again!

The solution is to use phpMyAdmin or your database manager of choice to empty the sessions table. Then you'll be able to access /user without being redirected.

Recently there was a bit of heated discussion on the development mailing lists (the good kind!) about module developers doing proper releases.

The jist of it being that some modules never get a proper release tagged, and exist as a constantly changing 'dev' version that is mostly stable but at any time could contain showstopping bugs as new features are constantly added to the tree.

Sure, you may argue that using a dev or release candidate on your site is bad practice, but often they are very stable (it completely depends on the maintainer) and necessary to use. The problem comes, I find, in upgrading these dev modules. Do you always jump to the latest dev version when you have the opportunity? I find that in the absence of proper releases, sticking to the mantra "if it ain't broke, don't fix it" is the best way to handle dev modules.

The important thing is to study the commits, release notes and issue queue to see what has changed. Sure, it takes a bit of time, but it can save you a lot of heartache down the line. Things can break in the strangest ways. For example, the imagefield module going from release candidate 4 to release candidate 6 of version 2. Should be more stable, right?

Wrong. RC6 has an absolute disaster of a bug that prevents it from working with single image fields.

With proper version control, generally it's safe to upgrade from one bugfix version to the next, for example from 1.6 to 1.7 of a module, when new features are being added into a separate branch. Don't make the mistake of thinking the same thing is true of dev releases!

To check out the issue queue of a module you're interested in, browse to the URL http://drupal.org/project/issues/search/ for the advanced search form. For example, CCK would be:

http://drupal.org/project/issues/search/cck

Select the version you're interested in, and search. Now scan the list for anything that looks remotely scary... if the version you're interested in looks like it's falling apart, stay away!