Drupal

Basic HTTP authentication is a simple authentication mechanism that is used to prevent access to a site or directory on a server. It is by no means the most secure authentication mechanism but it is commonly used on staging sites in order to prevent unwanted access. This is a good way of preventing search engine bots from spidering the staging site, which is undesirable as it can cause staging site pages appearing in search engines results.

The usual route to set this up is to create a .htaccess that sets up the authentication and references a .htpasswd file to create the username and password details. This can mean editing the .htaccess file in order to setup the password correctly. Unfortunately, this creates a .htaccess file that shouldn't be added to the repository as it would mean that the live site would also be password protected when the code is deployed.

When generating markup in Drupal you'll often want to store the output in a cache instead of regenerating it every time. This is especially important for potentially expensive rendering tasks that don't change between page requests. Drupal 7 comes with a cache system that can be taken advantage of with the cache_get() and cache_set() functions. There is also a third function called drupal_static() that also fills in gaps between these two functions.

Varnish is a web application accelerator that provides an easy speed increase to most web applications and Drupal is no exception. It works by creating a reverse proxy service that sits in front of your web server and caches traffic that comes through it. When the page is requested, Varnish forwards the request to the web server to complete the request, the response that comes back from the web server is then cached by Varnish. This means that the next request to the same page is served by Varnish and not the web server, which results in a large speed increase.

The upshot of using Varnish with an application like Drupal is that when a request is made there is no hit to the web server (and thus PHP) and no hit to the database. Varnish works best with Drupal with anonymous traffic, as authenticated traffic requires cookies and custom HTML. Even so, you can see massive speed increases for any anonymous traffic on the site.

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

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.