Drupal 7

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.

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.

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.