Drupal 7

When doing site audits on Drupal sites it’s always a good idea to get a feel of what sort of content types, users and taxonomy terms are available. Here are some SQL queries that I tend to use when starting out on a Drupal Audit.

I recently came under a spam attack that gave me a bit of a problem to sort out. Over the course of 24 hours my blog received over 50,000 comments, all of which were utterly useless. What was good was the fact that my tiny little VPS server managed to stay available for most of the attack.

Due to the vast number of comments the normal administration form in Drupal became a little useless. I could only delete 25 comments at a time, so after an hour of this I decided that I needed to run a few SQL statements to clear out all of the unwanted comments in the database. I thought I would write up the commands I used in a post.

The first thing to do was to delete any unapproved comments from the comments table.

DELETE FROM comment WHERE status = 0;

Next, the comment body fields in the field_data_comment_body table also need to be removed. This was done by also cross referencing any missing comments from the comment table.

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

The WYSIWYG module in Drupal is a great way of integrating a client side HTML editor (better known as a WYSIWYG editor) into a Drupal site. It supports a variety of different editors, all of which can be configured depending on the input format being used by the user. The ability to incorporate many different content editors into a site using a single module means that the configuration interface for them all is pretty much the same. It also means that it isn't a disaster if a different editor is needed for an existing site. You just need to ensure that the correct configuration options are set to allow a similar user experience.

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.