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.
The City University London campus was the venue for Drupalcamp London 2014 and I went along for the weekend as a delegate. This was the first conference for a while where I wasn’t helping out, speaking, or organising in some form so it was good to just turn up and relax. I travelled down on the Friday night from Manchester and successfully booked into my Airbnb room.
The (pre-breakfast) keynote was from Mark O’Neil and was about the Government Digital Service (GDS) and about how they are working towards making the UK government IT service better and more open. Mark is Head of Innovation and Delivery at GDS and has had a hand in most of the projects that the organisation is involved with. The team he runs is only a dozen or so developers, but they are producing things that are used by millions of people right now. The most prominent of these is the gov.uk website.
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.
It’s been a whole year since the last DrupalCampNW2012 and this years DrupalCampNW (appropriately titled DrupalCampNW2013) seems to have been a great success. This years camp was held in Manchester at The Studio and I was part of the committee of people who helped organise and run the event.
Over the course of the weekend there was a range of talented speakers covering differing issues around Drupal, open source technologies and user experience. The weekend consisted of a Friday business event, followed by a developer and site builder event on the Saturday and Sunday.
My main task during the event was making sure the volunteers we had there on the day knew what they were doing and when to do it. The trouble with organising and running a conference is that you are lucky if you get to see many of the sessions. I did, however, manage to see several sessions over the course of the weekend.
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.