Drupal

Steam wrappers were introduced in Drupal 7 and allow user file locations to be kept in a maintainable way, although I often forget which function to use to translate them. The three wrappers available are public://, private://, and temporary://, which map to the public, private, and temporary files directories respectively. All user files in Drupal are stored in either of these directories and they are referenced in the database as the file wrapper followed by the location of the file. This means that the location of the files is only dependent on a single config setting.

Translation of the stream wrapper into a file location is dependent on one of two functions, depending on what sort of file location you want. If you want to get a local file location then you would use drupal_realpath(), whereas if you want a URL of the file you would use file_create_url().

This years European Drupalcon will be held in the Czech Republic city of Prague and tickets are still available. This is the largest gathering of Drupal developers, site builders, project managers and users in Europe and it is always run exceptionally well by the Drupal Association.

Context is a Drupal module that allows you to set up reactions that fire when certain conditions are met. This might be when a certain path is loaded, or when a particular content type page is viewed, or even on every page on a site. When the conditions are met a number of reactions can be fired, which include placing blocks, setting breadcrumbs, or just adding a class to the page template.

I was recently working on a module that contained a content type as a feature. When the module was enabled the hook_install() hook set up a collection of taxonomy terms which were used within the content type as a field. Whilst testing this out I realised that although the terms were installed correctly the default value of the field changed depending on which system the module was installed on. The reason for this was that the term ID was being used to pull out the default term from the database, which is the normal behaviour in Drupal. The problem here was that if a term the ID of the term was different (because one had been added) then this had a knock-on effect of changing the default value of the field.

To get around this I needed a way of setting the default value of the field based on a given taxonomy term. After some research and reading of the Drupal source code I found a way to programmatically set the default value of a taxonomy field.

Alternative PHP Cache (APC) is an opcode and variable cache for PHP. When you run a PHP script it is first compiled into a series of opcodes which are then used by the Zend engine to run the program before being discarded. APC sits between the source files and the Zend engine and will stop the opcodes generated during the PHP script execution being thrown away. This means that when you run a PHP script a second time the work done in generating the opcodes has already been done and the script will execute faster. In fact, the opcode cache alone can substantially increase the speed of PHP execution and provides an 'easy win' when improving the speed of a PHP website. Having APC for a complex system like Drupal means that you will see a substantial increase in performance, so it is well worth having.

There are several methods to install APC, but the easiest is to use apt-get (or similar package manager).

I often find that after recreating a Drupal site locally to do some testing that I have left CSS and JS aggregation turned on. This can be turned off easily enough via the performance page, but this often breaks the flow of what I am doing. As an alternative I use Drush to reset the values via the command line.

The Drush command variable-set can be used to alter any value in the variable table. The two values needed for CSS and JavaScript aggregation are preprocess_css and preprocess_js. To turn these values of we just set them to 0 like this.

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.

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