Drupal

Views is an amazing module, but sometimes you can come across certain limitations that make life difficult. For example, I created a view that pulled in a bunch of nodes based on different taxonomy terms. The problem was that I had more than one taxonomy term in different vocabularies being used to filter the results, which essentially caused the same field in the term_data table to be used for both taxonomy filters. So, no matter what I changed the parameters to I always received no results. I did try and add the second term as an argument but it isn't possible to do LIKE matches with views arguments.

One new feature of Drupal 7 is that any title you give a node will be copied to the menu title field when you create a menu item. I wanted to replicate this functionality in Drupal 6 and so I created a function that did just that. I have used this function a few times in different projects so I'm posting it here.

This code uses the drupal_add_js() function to push a small amount of JavaScript code into the page when a node is added or edited. The hook hook_init() is used to add this content as it is run very early on in the Drupal boot cycle. I have tried putting this code into other hooks (like hook_preprocess_page()) but it isn't included, I would look into this further but this solution seems to work well.

Whilst creating a large and complex form in Drupal 6 recently I hit upon a problem that took me a couple of hours to solve so I am posting the solution here in case anyone else gets similarly stuck. I am also writing this down so that I can remember the strategy in case I have to do the same thing again.

What I was doing was creating an event booking form. The form allowed users to select from a number of times slots in a select list, but each time had a limited number of bookings. When the user submitted the form and all allocated slots for their selected time were fully booked they were shown a message asking them to select a different time slot. The original time was removed from the select list so that the user didn't try to select it again. This was fine and it all worked as expected but when this happened I also got the following error message from Drupal.

Rewriting the output of a Drupal view isn't always necessary, but figuring out what to do with the available templates can very useful. It is, however, also a bit of a stumbling block from time to time, especially for newcommers. After you have created your view you will have a number of filters to restrict your data, and a set of fields which are printed by Views using a set of templates. How these templates are used depends on what sort of view data you use and style you select, but there will be three standard templates that are always used in views. These templates are display, style and row and can be treated like any other Drupal template in that you can override them with more specific filenames.

I discovered a little issue recently with the Profile module in Drupal 6 and after finding the solution I thought I would post it here in case it helps anyone else.

The problem occurs when using the list selection form item in a specific way. This form item works find for just about every situation, except one special case. Lets assume that you wanted to ask a user a question which requires a number between zero and four; you enter the following into the selection options box.

0
1
2
3
4

This is saved fine, but when the form is rendered it doesn't actually print out the option to select 0, which is odd as the value is definitely saved in the database and can be reedited in the form admin.

The Drupal Features module is a way of packaging site components with the ultimate aim of easing migration. For example, an events section in Drupal doesn't just contain a node type called events, it also contains all of the configuration settings around comments, fields added to the node type, permissions available to users, menu items created and any views used to aggregate or search the events. Features can integrate module dependencies so that all functionality that has been packaged along with the feature is available on the other system.

The main thing to realize about Features is that they are not meant to transport content, just blocks of functionality. The idea is that if you create a "blog" feature then you can package that and deploy it to multiple sites.

A common practice when creating sites in Drupal is to create different node types for different purposes. Sometimes these node types can be functionality based rather than content based and are used for creating a rotating banner or something similar. A side effect of this is that you will then see these nodes appearing in search results, which can cause some confusing results to be displayed.

So how do you remove these nodes? Well with quite a simple little module you can intercept the search query and stop certain node types being searched for. Adding a couple of extra functions means that we can add form controls to the advanced search form and the search admin area so that nodes can be selected to be excluded from the search results.

A couple of weeks ago saw the release of Drupal 7 so I thought I would run through a few new features that might be of interest. This certainly isn't a comprehensive list of new things as there is a lot of changes in this new version.

1 - Admin Interface
Drupal 7 comes with a nice new admin interface that has gone through lots of usability testing and redesign which has resulted in two new themes being bundled with the system. The admin interface is powered by a brand new bundled theme called Seven, the new front end theme is called Bartik. The old Garland theme is still there, but isn't enabled, so you can still use if you feel the need. Some of the older table based themes have now gone in favour of these new themes. The new Overlay module makes it easier to administer Drupal by displaying the admin pages as a layer over the current page, rather than moving the user around the site.

SimpleTest is a great way to test your modules, but it can take a bit of setting up. For every test that is run SimpleTest effectively has a fresh install of Drupal, so if you need to test a particular function you need to have everything in place before you run the test. I was recently testing a migration module that I had written and needed to create nodes with a variety of CCK fields, which is quite common in Drupal site setups. In order to test that a CCK field saves the data for a test you need to do the following in the setUp() method, remember that this all happens before any tests are run.

Drupal SimpleTest is a module that will allow you to unit test your own modules or unit test any patches you have made for third party modules. This module will be integrated into Drupal 7, but for Drupal 6 you have to do a couple of thngs before you can start testing. This article is a very quick introduction to Drupal SimpleTest and will be followed up by more articles in the future.

The first step is to download and install the SimpleTest module as you would any other module. You can use Drush to do this if you know how.