Drupal

Organic Groups (OG) in Drupal 7 has a role based permission system that works on a group by group basis. This permissions system works separately to the main Drupal permission system, which can cause a couple of issues. For example, if you want to give a group role access to give other users roles then you'll need to give them the 'Administer groups' permission. The downside of this is that it overrides Drupal's core permissions to do with node deletion and allows the role to delete the group. Allowing any user to delete groups can lead to all sorts of problems so an alternative is needed.

The group people admin page (found at group/node/%nid%/admin/people) has a bulk operations form that allows users with access to the form to manage user group membership. To allow or deny a member a user just needs to select them from the list, select the action required and click Update. Here is the select statement from that page.

I have been developing a site with the Drupal 7 Organic Groups (OG) module today and I found the need to grab a bunch of users from a group depending on their group role. The first parameter here is the group GID (not the node ID) and the second is an array of role ID's to use.

$administrators = og_get_users_by_roles($group->gid, array(4));

This is fine, but as I couldn't be sure that the role would have the same ID on my production server I needed to use a function that loaded the role ID based on the name of the role I wanted. The result of which could be fed back into the above module. It turns out that OG doesn't have a function like this (that I could find) so I wrote the following.

I had a recent requirement where I needed to temporarily replace the homepage of a website running Drupal with a simple HTML page. I wanted to do this without doing lots of changes to the site templates so I needed a solution that was easy to turn on and off and would still retain the Drupal site as it was. I found the simplest solution was to add a rule to the DirectoryIndex rule in the sites .htaccess file. Here is the rule I used.

# Set the default handler.
DirectoryIndex newhomepage.html index.php index.html index.htm

With this in place I just needed to create a file called newhomepage.html in the root directory for this to be used instead of the main index.php file. When the user visits any other page on the Drupal site then the index.php file is used as it normally is. The good thing about this method is that it can be turned off easily by just removing the newhomepage.html file.

When Mike Bell approached me several months ago and said we should do a Drupal camp in the north west I was completely on board with the idea. So for the past few months I have been working with Mike and a group of people from the North West Drupal User Group (NWDUG) to create such an event. The result was DrupalCampNW2012, which was held from Friday 23rd to Sunday 25th November. The venue was the new University of Salford campus buildings in MediaCityUK.

Our main stumbling block in getting this conference up and running was the venue. After talking to some of the computer science people in the University of Salford they offered the use of the building in exchange for some free student tickets.

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.