Drupal

Every Drupal project I finish will usually have the same request at some point. This usually happens when the client tries to do a search that produces no results and sees the search hinting text about blue smurfs.

The text about blue smurfs that is printed when there are no search results is called directly in the search module so it isn't possible to edit or override it. The solution is to use the theme_box() theme hook and override the text just before it is sent to the page. Just drop the following code into your theme.php file, rename the function to fit your theme and clear your caches.

Drupal is capable of sending out a few different emails to users depending on different actions. The emails can be customised quite nicely with usernames, passwords, email addresses and other things by using a set of tokens. The password recovery email states that you can use the "!password" token to send the user their new password, but after a few tests I found that this token doesn't get replaced when the email is sent out.

The simplest solution here is just to remove this token from the description for this email. However, if you do want to allow user's to reset (and receive) their passwords by using this form then there are a couple of simple things you can do.

The first thing to be done is alter the user_pass form so that it uses a custom submit function that we will write. Add the following form hook to a module (or create your own for this purpose).

I often get asked a simple request during a project, and the solution to the problem is sometimes more complex than I originally thought. One of these problems was adding a WYSIWYG editor to the summary field on the node edit form. There isn't an easy way to do this, but it is possible to get a good solution working.

Using the hook_form_alter() hook we can intercept and change the node edit form to change the type of the summary element from a textarea to a text_format element. In order to get the WYSIWYG component of the form working we will need to also add a format to the form element. For the purposes of this example I have created a module called wysiwyg_summary, so the hook is called wysiwyg_summary_form_alter().

I recently noticed a strange little issue with Drupal 7 that seemed like either an oversight or a decision I don't agree with. Essentially, when a node is created with a menu item in place the extended flag on the menu will not be set, but the control is also not available on the menu admin page. This means that when you are trying to print out a hierarchical menu structure you need to create the page, go into the menu admin area, access the menu, click on edit to access the menu item and change the setting there.

To get around this I set about creating a little module that would add a form control to the menu options section on the node edit form. This single checkbox is used to override any settings that the menu module creates with regards to the extended menu parameter.

The first thing to do is create a simple info file for the module. I include this here for completeness.

A tabledrag form in Drupal 6 is any form that will allow you to move items up and down the list or into a hierarchy of items. This is actually a component of Drupal itself and is used on forms like menu, taxonomy and blocks management. Tabledrag is a great way of allowing your users to move items up and down a list with ease and they will be used to the mechanism from other areas of the site.

Essentially, a tabledrag is a normal HTML table within a form that contains some form elements and some JavaScript that will turn the table into a sortable group of elements.

I needed to create a tabledrag form in a recent project, but after not finding many good tutorials about creating a fully working form online I decided to write one. This will take you through the basics of what you need to get a weight based tabledrag form working and will also leave you with a working module.

During my work developing Drupal sites I am quite often asked if I can provide a example of form elements for designers. This is so that they can test their designs with all possible form elements that might appear in a Drupal install and make sure that the theme we create will be robust and future proof. I often find myself forgetting how to create, say, a multi select element and needed a sort of cheat sheet that I could look form elements up on.

To this end I sat down and created a list of all of the Drupal form elements and packaged them into a module so that when the path 'form_elements' is loaded a very large form with lots of elements will be rendered. There is even a tabledrag form component in there, which is used quite a bit within the Drupal administration pages.

The input format help text is a good way of telling your users about the sort of content that they can enter into any text area. For some users, however, they can get in the way a little and even cause confusion, especially when WYISYG editors are used as much of the help text will be quite useless to most users.

The input format section is controlled by the Filter module, which is built into Drupal core, and it comes with a couple of handy hooks that allow control over this section. The filter tips section is split into two parts, the actual filter tips text itself and the more info link below the tips. If you want to remove these then just pop the following into your theme template.php file and change the function names accordingly.

The Login Destination module is a neat little module that allows site admins to customize where the user will be sent to when they login. It provides a few of different ways of customizing, including a PHP snippet box that allows fine grained control.

What I needed to do on a recent project was to change the login destination for a single user role, but redirect everyone else to their user profile page. This required the use of the PHP snippet box. In order to get access to the current user object I had to include it into the scope of the PHP snippet code by using the following.

The Drupal 7 Queues API is a few feature of Drupal and provides a first in first out data structure that is used internally by Drupal itself and can be completely customised.

The Queues API isn't just a part of the codebase of Drupal, it is used internally as part of several different processes. The Batch API, which allows lots of things to be done at once, is built upon the Queues API and provides some customised queue classes. I won't be going into the batch API in this post, but I might cover it in later posts.

The new cron system in Drupal 7 uses the Queues API heavily. It works by allowing other modules to create queue items during their normal hook_cron() calls, which are then run afterwards. Each module that wants to include an item in the system cron queue can do so by implementing a hook called hook_cron_queue_info(), which tells cron what function to callback when the queue items are retrieved.

This weekend I attended the Druapl7Camp 2011 in Leeds and so I booked a hotel room for the weekend and managed to find the right place on Saturday morning. I was one of the first to arrive and was able to greet people as the came through the door. With coffee flowing nicely and the wifi appearing to be stable we all set down to the first session.