We are loving the Drupal context module here at ComputerMinds, it puts a lovely user friendly formal front end onto creating context's for your site, something we had previously been doing with various snippets of code. If you haven't come accross the context module before then I fully recommend you have a look at this post http://www.developmentseed.org/blog/2008/apr/09/context-ui which explains all ...

With large Drupal projects, especially those in their post-live phase, good code and release managment becomes vital.
Update hooks provide the mechanism by which database changes can be scripted and deployed to the live server, this article assumes you are already well versed with the ways of update hooks.
The two main problems we have with update hooks occur on multi developer projects

Same function is implemented in 2 branches. Imagine the situation where you have 2 seperate branches open on the same project, with different developers working on each branch.
Both branches want to update the module crm_integration so they both add the next available update hook crm_integration_update_6003.
This obviously isn't a problem during the testing phase, but as soon as you integrate the two branches you end up with 2 implementations of the same function and consequently a PHP error.

Day 2 at Drupalcamp UK was as packed with goodness as the first day, here's some of the highlights:

Integration with 3rd Party Applications

In this excellent session given by Adam Evans common techniques and pitfalls for integrating applications with Drupal were covered. There were some really good tips, including using Solr to search external data held in a e-commerce system and using the Drupal Apache Solr module to pull that data into a Drupal page.

Form API

This session at Drupalcamp UK was given by our very own computermind: Steven Jones. He took a quick poll, and people wanted him to speak on using hook_form_alter. In a major blunder he tried to alter the node form. It turned out that you can't alter some bits of it at the module level, because of special handling. Still, the principles were covered!

A brief summary of some of the cool stuff I picked up from day 1 at DrupalCamp, interestingly most of it wasn't necessarily Drupal related ... day 2 and pics (featuring lots of ComputerMinds lanyards!) etc to follow ...

Hudson - a tool that automates builds, running of unit tests, running of jmeter performance tests and some other loveliness. Configure it to run periodically against your various SVN branches (works with other SCC systems (Git, CVS etc) too I believe). It even has front end with little weather style graphics, rainy if its broke, sunny if it's good, cloudy if not sure etc. Brilliant brilliant brilliant.

Drush is just brilliant - command line control over all kinds of stuff

If you have a Drupal site with users and you want to allow them to add some profile data about themselves there are a few routes available to you, one of the oldest (and thus simplest) ways is to use profile module. You can add text fields, selects and other bits and bobs to users, with different visibility settings for each field. You also have the chance (in fact it is required that you do) to categorise your fields. These categories then show up as secondary tabs on the user edit page. But what happens when you want to make it really simple and get the profile fields onto the main user edit page itself? At first glance you can't, because if you set the category to 'account', then Drupal will complain. But you can just set the category to 'Account' and you're done, right?

Wrong.

One of the interesting sessions that I attended at DrupalCon DC was one entitled: Business Analytics in Drupal with Views. In it, the presenters showcased two of their modules. One was a charts display plugin for views, and one was a 'group by' views field.

We are finding that the feature exciting most end users in Drupal 6 is the lovely new jquery based drag and drop, as seen on the blocks and menu edit pages - we will be quite happy never have to explain the concept of "weights" again. The best news is that you can add this functionality to your own forms for free - and here is how.

I'm always hunting around for these various bits every time I do an Ubuntu rebuild - so I thought I would collate them all into one place. This is what we use for our dev boxes, not certified for a production webserver. Note this is specifically for Ubuntu 8.04 - it may well apply to other versions of Ubuntu however.

One of those little Drupal annoyances this, there is now easy way to alter a comment (using hook_comment) before the comment is written to the DB. Hook comment is invoked during the validation phase, with $op set to "validate", and the comment array is passed by reference - but unfortunately any changes made to the comment are not passed on to the comment save function.

We wrote an article about linking a view's block title to the companion page view, in Drupal 5. Someone asked for a Drupal 6 version, which can be quite easily done with a preprocess function, but it's not very flexible.

Instead we just need to create a new display plugin for Views 2, and that will allow us to be much more flexible in our approach.

This is my first display plugin, so it may be completely broken (though it works for me!) You'll just need to download and install the attached file like any other module.

Instead of adding a 'Block' display to your view, add the 'Block (title link)' display, and you'll get an extra option to define which display you'd like the block's title to link to. Simple.

[EDIT] It was completely broken! But it is now fixed and should be working nicely.

There's an excellent article over on gtrlabs: Drupal 5: How to process multiple instances of the same form on the same page that describes in detail how to have multiple copies of the same form on the same page. There are some subtle differences to use this technique in Drupal 6, which I'll explain below.

The idea of this technique is simple, drupal forms are identified by their 'form_id' and these ids must be unique on a page, so if you want the same form to appear more than once, you need to change the 'form_id' somehow. We do this by appending a number to our 'form_id':

We love the views bulk operations module here at ComputerMinds, and frequently use it to create some lovely administrative interfaces.

However we often find a need for an administrator to be able to perform operations in a quick and easy way on an individual node. While some of the core operations (publish, make sticky etc) can be performed from the edit tab of the node, many other node operations do not offer this facility ("rebuild image thumbnails" for example).

So we have put together a simple module that exposes a form just like the one you get on the node admin page, that will allow you to perform bulk operations on the single node that you are currently viewing.

Thought I would post this little function on here, we tend to use it a lot and it gives some nice little extras for you to play with when you come to template your nodes.

• $node->view_name : the name of the view this node is being rendered in
• $node->position_in_view : the position within the view for this node

function phptemplate_views_view_nodes($view, $nodes, $type, $teasers = false, $links = true) {
  static $count;

  foreach ($nodes as $n) {
    $node = node_load($n->nid);
    $node->view_name = $view->name;
    $node->position_in_view=$count[$view->name];

    $count[$view->name]+=1;
    $output .= node_view($node, $teasers, false, $links);
  }
  return $output;
}

Super quick one this: say you have a CCK field on a particular node whose values you want to ensure are unique across all nodes on your site, you could write yourself a nice little helper module, or some PHP directly into the CCK field validation section of the admin form, but, a helper module already exists!
Unique field is a lovely little module that allows you to say that a particular text, number or date field should have unique values across the site, or indeed in that node.

I used this on a user's profile node for a 'alias' field, thus ensuring that everyone chose unique aliases!

One for the small but handy category this. The standard "more" link the views module adds to it's blocks has no place on a modern accessible website, you really need a more verbose link in there. One solution has always been to add a bit of footer or header text into the block, but it's a little tedious - and clients always find views hard to edit.