Drupal

I spent what seemed like an eternity today trying to figure out something in a form I was creating on a Drupal site. I was building a multi step form with previous and next buttons, both of which were submit elements like this.

$form['next'] = array(
  '#type' => 'submit',
  '#name' => 'next',
  '#submit' => array(
    'mymodule_next_submit'
  ),
  '#value' => 'Next Step',
);

What I needed to do was override these and make them button elements instead of input elements. This involved creating a theme function in my template that looked like this. You could also do this in your module by adding theme overrides using hook_theme_registry_alter().

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.

A couple of months ago I gave a talk at the North West Drupal User Group in Manchester where I talked about the EU Cookie Law and about cookies in PHP and Drupal. The EU law has been in practice in the EU for the last year and is due to be implemented in the UK on May 26^th 2012.

People have been asking me to provide them with the slides so I thought I would create a quick blog post and put them on #! code.

Cookies and the EU Law.

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.