A while ago, I had a simple website, with a simple js script for calculating a price based on some user input. The script uses an updater function that, after all required choices have been made (radio buttons), calculates the final price and shows the price. It does this by adding html to a predefined ‘price div’ (price.innerHTML = “…”) and setting it’s height from 0 to ‘auto’. Nothing fancy, but worked quite nice.
Upon changing the website for a Drupal site, I was confronted with implementing the js within Drupal. And even though it wasn’t really hard, it took me a while to figure it out, so I thought I’d share my findings, hoping they would be useful to somebody.

First of all, I created a normal page within Drupal. The downside of the method (to some people) is that I had to enable PHP for the page input. But as I am the only person ever seeing an input form on this particular site, I didn’t care too much. For adding the required js (and some extra css for that page), I used:

And then I added an html form which calls the updater function on each click. This makes it possible to have the second choice customers have to make depend on the first choice they make.

Works like a charm for me...

Without a doubt, the Views module is one of those Drupal modules without which Drupal wouldn’t be the same. With Drupal 6, Views got a major revision, and I must say I quite like the new interface. There was one thing that I couldn’t figure out immediately however: how to random sort the selection. I should have looked harder in the sort criteria – which is the most logical place to put it – but I was sort of expecting the possiblity to add randomness to any sort criterion I selected (e.g. node:type). Not so: in the list with all possible criteria, you have to select “global:random”.

Still not sure whether that is the most logical way of doing it. Personally, I would think adding “random” as a choice for each criterion (besides “ascending” and “descending”) would yield a much finer granularity and makes more sense. The fact that the random sort criterion is listed as “global:random asc” (asc for ascending) doesn’t really help changing this view either.

But probably there is a good reason for doing it this way. To paraphrase a French proverb: The programmer has his reasons that reason doesn’t know.

Luckily, there are different ways to handle bots as well. If you’re using a .htacces file, for example, you can add a snippet to block the vermin based on their IP address. An idea I liked even better is to redirect the bots to a site that tries to reeducate the bots. You never know.

In stead of redirecting the bots to a governement site where they can take a seat and follow a hands-on course on cyber crimes, another good idea is to send the little bastards to a spam trap page. Gives me visions of all bots in the world swimming around in a pool of interlinked spam pages, never able to get out by them selves. Heaven…

So that’s what I do now, I redirect the bots to a spam trap. Typing in the IP’s in the required format for the .htaccess file, however, can be a PITA. Therefore, I wrote a little script to generate the .htaccess snippet based on a list of IP’s in their normal format. The .htaccess format itself comes from Am I Famous Now. Insert the URL where you want to send the bots to or leave the one I use, insert the IP’s of the bots and push the button:

Copy paste the snippet into your .htaccess file, and you’re all set. (WATCH OUT: if you don’t know what you’re doing, messing with .htaccess can wreck your site in a second. Don’t blame me. I told you.) This works fine, ofcourse, when you can easily keep track of the bots. When you have huge traffic on your site, you probably have a huge number of bots visiting it as well. In that case, you’re probably better of with a lean and mean, fully automated and integrated bot trapping/blocking device like this or this