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

Taxonomy Menu is a very nice Drupal module that lets you create a menu based on a content type’s taxonomy. The taxonomy terms form the menu structure, and the way the nodes are displayed when a menu item (= taxonomy term) is selected can be customised using a custom view. I really like it. I like it so much, that I wanted the taxonomy terms displayed in the header of my nodes to link to the same menu structure, so that clicking on them was the same as clicking on the same term in the Taxonomy Menu.

Here enters Taxonomy Redirect. This module allows one to rewrite the url that the Taxonomy module creates. So instead of blabla.com/taxonomy/term/999 you can make the link blablabla.com/goto/this/instead/999. For this, you can define a redirect as plain text, or with a php snippet. Due to the link structure Taxonomy Menu uses, I had to resort to php for dynamically creating the Redirect link. The standard format for the link structure for Taxonomy Menu is “sitename.com/category/vid/pid1/pid2/tid” (with vid the vocabulary id, pid a parent term id, and tid the term id). The term “category” can be set in the settings for Taxonomy Menuy. Using plain text to define the Redirect link would f*** things up when the taxonomy term did not have any parents. Php worked fine, once I found out that the Redirect module defines a variable $tid for the term id, that you can use in your script. The code I used:

The “1″ behind “category” in the first line is for the vocabulary, so you’ll have to check what value you need there. Note that using php might not work straight away for anonymous users. To resolve this, have a look here…

becomes:

You may want to check whether the identifier for the PHP filter is 2 for you Drupal install. You can verify this in your Drupal database in the filter_formats table.

One of the disadvantages of BBClone, however, is the fact that it cannot be included from within a function. To function properly, BBClone has to be called directly. Calling BBClone is done using:

Optionally, you can define the refering page using:

The pagename and the directory have to be changed according to your needs.

When you’re not caching your website at all, you can easily add this snippet to you page.tpl.php template, and that should work fine. In this case, you can even use the available Drupal functions to define the page name. When you’re serving your Drupal cached, then that’s not possible, however, as page.tpl.php is only called now and again (when the cache is being refreshed). If BBClone could be called from within a function, one could easily write a module calling BBClone during the bootstrap. Alas, that’s not possible. Therefore, the only possibilties to my knowledge require some core hacking. The one that I like the most, is messing with the main index.php file, because it’s a very simple file.
Right after the comment, you can add:

(Ofcourse, you don’t have to include the php tags.) The first two lines define the page name as the url requested from the server. Because the bootstrap has not even been initiated, using Drupal functions is not possible. One could write a more elaborate function to extract the page title, but I think this solution is both elegant and simple. And it works…

What wasn’t immediately clear to me, however, was how to include the commenting section in a node using Contemplate (or node-type.tpl.php for that matter). A search on drupal.org eventually leaded me to using this:

which works fine at the moment.

Note that this is working for Drupal 5, but in the same thread, solutions for Drupal 6 have been suggested.