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.

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.

Getting the first or last item from an array in PHP is usually quite easy. If you create an array and then add a bunch of values to it then the array index will increment by 1 for every element you add. This means that in order to get the first element from an array you just reference the default starting position (0). To get the last item in the array the index key will be the length of the array, minus 1. Here is some example code showing this.

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.

I recently have started looking into making myself a PHP Zend Certified Engineer and after doing a bit of research I found that the standard PHP string and array functions appear to be a large part of the exam material. So as a starting point (and for future revision) I decided it might be a good idea to create a revision sheet for those functions.

Ever sat there and pondered which browsers support what css styles? If so I’d like to quickly introduce http://www.caniuse.com. This is a great tool and sometimes the quickest way to find answers to your questions. But what about W3Schools; I hear you say. W3Schools does have a comprehensive list of styles, complete with examples of how to use them and a list of properties that you can use. However, what I find W3Schools fails on is a comprehensive outline of browser support.

The DateTime classes in PHP have been available since version 5.2, but I have largely ignored them until recently. This was partly due to the fact that I was working in PHP 5.1 environments a lot (don't ask) but mostly because I was just used to using the standard date functions that have always been a part of PHP (well, since version 4). I wanted to explain why I will be using the new DateTime classes more from now on and why you shouldn't be hesitant to use them.

Using a combination of strtotime() and date() can handle most things and is a good method to quickly grab a date.

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.