Drupal

If you want to use Zend Framework in Drupal then most of the time you can use the Zend module. This takes a little configuration but will include the framework and instantiate the Zend_Loader_Autoloader class so that everything is ready to run.

The Zend module has a number of different strategies to including the framework, which is handy if you do or don't want to use the Libraries module. The module uses the hook_init() hook to include and instantiate the Zend_Loader_Autoloader object, which meant that this was done on every page load; even if the framework isn't being used.

Although Drupal SimpleTest is an extremely useful module it doesn't currently support data providers, which is a shame as I use that feature quite a bit in other testing frameworks. A data provider is a mechanism that allows you to call a single test case multiple times with different arguments so that you can ensure the correct output each time. This is useful because testing a single function once is fine, but testing it with a variety of different values can otherwise mean having multiple test cases.

To mimic this functionality in Drupal SimpleTest you can create a data provider method that returns an array, which is then used to test a particular function.

For example, let's say I have the following (trivial) function in a Drupal module.

I am currently using SimpleTest to test a complex multi-step form implementation in Drupal 7. It made sense to do it this way as there are a lot of factors involved that all need to be accounted for and automating what form elements appeared on what page was the most robust solution. In order to test how the form worked I needed to submit to the form once (using a $this->drupalPost() method) and then submit the form again using the same method. The tricky bit here was that when calling the drupalPost() method with a URL it first called drupalGet() on the URL before posting to the form. This basically meant that the form was initiated twice and never got past the second page.

Altering text in Drupal 7 is quite simple thanks to things like string overrides that allow you to replace all instances of a string throughout a site. If you want to change a single element on a single form then string overrides don't quite work, but using hook_form_alter() or hook_form_form-id_alter() allows you to manipulate any form in a Drupal site.

Whilst working with Organic Groups today I had the need to load a list of the nodes that a user is connected to. After a bit of looking around in the source code I couldn't find a good solution on how to do this. So after looking around on Google for a bit I just sat down and wrote one.

Getting the group nodes that a user is a member of is quite easy as it turns out, but must be done in a number of steps. The first step is to grab a list of the group entity ID's that the user is connected through using the og_get_entity_groups() function. This can be used with no parameters (which assumes the current user).

// Load in the current user's group entity ID's
$groups = og_get_entity_groups();

Or you can load a user and pass this object to the function.

Drush is a command line tool that allows interaction with a Drupal site. The tool itself is incredibily useful and provides mechanisms to download modules, backup databases and most other things that can be done with Drupal. Drush Make was a plugin for Drush which has now become part of the Drush core and allows Drupal sites to be created via a make file. What Drush Make does is to use the make file to download the modules, themes and libraries needed for a Drupal site ready for the site to be installed. This means you can give this make file to another developer who can then build their own Drupal site.

There are various different forms and modules in Drupal that allow for PHP code to be embedded into them. I have even talked about adding PHP code to forms in a previous post. These form elements can have their uses, modules like Views allow for PHP code to be run when collecting arguments which can allow for some advanced funcationality.

However, it can lead to problems. The code in the form is essentially outside of source control which means that anyone can mess about with the code and there is no way to revert changes or get back the code if the form save action failed for whatever reason.

Many modern browsers now come with auto-complete functionality so that users can fill in their details quickly without having to type in their username and password every time they want to log on. This can be turned off by adding the attribute "autocomplete" to the form and password elements and setting its value to 'off'.

Setting the autocomplete attribute to off on password fields (and forms containing password fields) can add an added level of security to your Drupal site. This is especially important as if the computer is stolen it is more likely to contain saved passwords that will allow access to sensitive systems. So turning this feature off might be beneficial for certain systems, especially those with very sensitive information.

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).