Drupal

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

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.

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.

During DrupalCampNW 2012 last November the company we hired to record the sessions also spent some time interviewing the people who attended. From these interviews we were able to create three videos, two from the main event and one about what Drupal means to different people. These videos are now complete so I'm posting them here so everyone can see. I think they came out really well.

I would also like to thank Drupal Association, who very generously financed the creation and production of these videos.

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.

I'm just letting all my neurons cool down after a fantastic Drupal Camp at City University, London. These Drupal camps are getting bigger, better, and much more frequent in a really, feely, organic way. They never feel like there is a sponsor driven sales push to use this service or that, moreover, it genuinely does feel like a community of like minded people, groups of people, willingly sharing their knowledge, ideas, and enthusiasm in what it is they are doing, using, or believe in.

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.