I'm moving to London soon. From sunny South Africa to a place where it's currently snowing! So with that in mind, here's a pic from the Nature's Best Photography Awards:

I'll look something like the one on the left, except I'll be clutching a snowboard in one hand and a ticket to Austria in the other...

A method of syncronising database changes from development to live using Toad for MySQL.

Requirements: advanced Drupal, database administration, experts only

One of the recurring problems faced by Drupal developers is database change management. If you don't encounter this problem yourself, then just imagine a scenario where you have a live site that needs to be running 24/7, while all your changes are made on a development server.

The big problem comes in migrating all the database changes from the dev server to the live one, without overwriting any data. Some people simply fiddle with dev until they’ve got it right, then duplicate all their work step-by-step on live, until they’re the same. You can imagine how perilous this process is!

I’ve been needing a solution to this problem for a while now, so I’ve pieced together this guide in the hope of receiving feedback from those who are wiser than me! I have not thoroughly tested this method on a real server configuration, only on my localhost, so I don’t know if it’s foolproof yet. But please take a look!

Requirements: basic css, image editing, basic theming

The fivestar module provides a tidy little voting widget that allows users to vote on nodes. It also provides a CCK field of the type "Fivestar Rating", which can be used to rate a node on multiple criteria.

One of my pet projects, Hill Bomb, requires just this functionality. It's a maps-mashup site for downhill riders, for example skateboarders or mountain bikers, to upload details and maps of awesome hills around the world. Here are the some of the ratings that users can give to hills:

SaveTheDevelopers.org places a friendly popup request for IE6 users to upgrade their browsers. (via TechCrunch)

By placing a simple conditional comment with a .js script in your page.tpl.php, visitors using the outdated and buggy IE6 web browser will see a small roll-down on the top of their browsers, "nagging" them to upgrade. After clicking the roll-down, a new browser window opens with links to other recommended browsers:

It's amazing how fast the spam bots got hold of Code Baboon. One post on Drupal Planet was all it took to get masses of rubbish comments advertising pharmaceuticals and who-knows-what-else!

I could just turn comment moderation on, but I find it's a little annoying from the perspective of the genuine commenter, at least, more annoying than a captcha. If anyone disagrees with this, please let me know, but until then I'm enabling the captcha module which has a couple of simple are-you-human tests.

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

I'm writing this post using the newly released Safari 3.1 browser for Windows. I've always had the beta installed on my computer for testing page rendering, but up until now I haven't tried to use it as a primary browser, preferring Firefox because of the awesome extension engine.

Well... I think I may be facing a conundrum, as Safari is simply amazing. It's fast, clean, and everything just looks better! Firefox is great and all, but the fonts and anti-aliasing in Safari are awesome, leagues ahead of Windows' standard fonts.

I've always promised myself that I'd upgrade my HP laptop to a MacBook Pro when the time was right. But now, that time is looking to be very soon. Very, very soon.

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.