Drupal

Simpletest is a Drupal module that I have been using for about a week to unit test a module I have been working on. It is a brilliant and powerful module that every module developer should be using to test their code properly. I did, however, encounter a couple of weird errors that took me a while to fix. So for the benefit of everyone else I thought I would post them here, along with the solutions. These errors are probably things that developers new to Drupal Simpletest will come across, which is why I have labelled them beginner errors.

Drupal has two ways in which to allow users to download files, these are private and public.

With public the files are open for anyone to download and Drupal is not involved in the download process. This means that no statistics are recorded or permissions used when downloading the file. Each file is referenced by name.

Private file access means that Drupal is run every time a file is downloaded. This allows the download to be recorded and a permissions check run to make sure that the user in question is allowed to access the file. Each file is referenced by a path that can be completely different from the original filename.

I just spend the last few minutes looking for the solution to this so I thought that someone else might be able to benefit from it.

Calling the hook_form_alter() hook in your module using just the module name allows you to target all forms in your system, if that's the sort of thing you want to do. For a module called "My Module" this would be called mymodule_form_alter().

The power of hook_form_alter() hook is that it alos allows you to specifically target a form with a specific name within a module. A good example is if you want to alter the search form to add a class, which is a common task. To do this, create a module so that you can add the hook_form_alter() hook to it and then construct the function name in the following way:

2010 saw the third annual Drupal Focus on Enterprise conference, which took place at the Sun Microsystems offices in London. The free event, which is sponsored by Sun, brought together a set of speakers to talk about different things that they or their businesses have done with Drupal. Even though I live in Manchester I was lucky enough to go along.

The conference consisted of two tracks, with a number of talks in each. I obviously couldn't go to every talk, but the talks I did see were of a very professional standard. The tracks weren't set in designated rooms but a head count was made of everyone who wanted to see which track and the bigger room used for the talk that got more votes.

I also arranged to meet fellow North West Drupal User Group (NWDUG) member @eli_t at the conference.

A related items block looks at the current content of the page and tries to present the user with a list of items that relate to the current content. Creating a related items block is quite easy, and is a good way of introducing the search module api without having to get to involved in the search module.

Before starting I should point out that there are other related items modules available. These are modules like Related Nodes or Related Items but these modules either aren't released for Drupal 6, or simply don't work in the way I wanted the block to work. I wanted a module that would act with little or no user input.

Whilst creating a view for a Drupal site the other day I created an exposed form but rather than the usual select boxes that get displayed I needed them to be a list of check boxes. Whilst searching about on Google I eventually found this article, which kindly provides a function that will do this. Here is the function in full.

The title tag on the Blog module index page (found at /blog after the module is installed) is by default "Blogs | Sitename", which isn't editable in the backend of Drupal. I've been talking to other Drupal developers and reading forums about the best way to go about changing the title of the blog index page. Ideas ranged from editing or duplicating the blog module (which is bad practice) to installing the String Overrides to provide a quick translation of the string in the title.

These suggestions are either quite poor, or simply overkill for what should be a simple string replacement. There were two methods we decided upon that work quite well and are easy to implement.

1) The first involves creating a page-blog.tpl.php template file and adding a str_replace() function call to replace the word blog from the title of the page. This would look something like this:

It is sometimes necessary to turn off caching on certain pages on a Drupal site. This might be when trying to do something out of the ordinary, like write information to a file, or randomly generate a section of a template. The following code can be used to turn off caching just on the front page of the site.

function theme_preprocess(&$vars, $hook) {
    if ($vars['is_front'] == true) {
        $GLOBALS['conf']['cache'] = false;
    }
}

Adding false to the cache item of the conf globals array at run time will turn off the cache. This is within an if statement that checks to see if the current page is the Drupal front page so it will only be used on the front page.

The Poll module is a useful little module that comes with Drupal and allows the addition of simple polls to pages or blocks. However, there was one major issue that I wanted to correct on a certain site, but I didn't want to directly edit the core functionality of the module. The default behaviour of the module is to record one vote per IP address or user, which is fine for normal uses but in some situations it does tend to fall over. A Drupal site with one administrator that allow anonymous users to vote on your polls seems fine, but lets say that this site wants votes to come from people in the business world. The problem here is that multiple people might work for the same business, be situtated behind a firewall and therefore would have the same IP address. What this means is that if one person in that company votes on your poll it will block all other people from voting for that poll.

I recently had some trouble with a Drupal 6 site I was updating. I wanted to create a local working copy of the site to test so I downloaded the files and backed up the database, but for some reason I couldn't get the site to run. In every browser I tried I would get "page cannot be displayed" or "host unresponsive". These messages were basically telling me that something on the site was causing it to fall over before it ever got around to producing any HTML, and so the browsers were treating it as best they could. I tried clearing the Drupal cache and disabling some modules but this didn't appear to do anything, or simply broke the site. Searching the internet for this problem yielded very few results, so I eventually had to track the problem down myself.