jimw's blog

For the last couple of years, the majority of sites we have built have been marketing to a global audience, which means we have taken on the challenges of displaying the site in an appropriate language (‘internationalisation’ or ‘i18n’) and often modifying the content for various countries and regions (‘localisation’ or ‘L10n’).

Following extensive experience of using Drupal to deliver intenationalised and localised websites, there are a few fundamental issues that keep catching us out - one of the main ones is ensuring that we use Drupal's t function approriately.

Here's a simple 'gotcha':

Wrong: <?php echo t('You are logged in as: ') . $username; ?>

Right: <?php echo t('You are logged in as: %username', array('%username' => $username)); ?>

There’s a sweet contentment knowing that a system is fully up to date and patched, but how uncomfortable it soon becomes when you find out there’s a new update or patch – leading to the nagging question of if / when to go through the grief of updating.

On the one hand, you know you should apply updates as soon as you can to get any potential benefit of new features, bugfixes or even improved security and performance – but anyone who has been around long enough will know that even the simplest patch can upset an otherwise stable system and be a royal pain to resolve.

Amazon have just announced a new addition to their web services family - Relational Database Service (RDS).

There are contributed modules that extend Drupal’s innate desire that all content should be publicly visible – notably node privacy byrole and Content Access. If you’ve defined your own node in a module, you can also use node_access() to set access rights to that node type.

This one caught me out for a good while – I’ve got my own data stored in a database using Drupal’s Schema API and one field I want is a date, so I used the ‘datetime’ type. But whenever I came to use a value anywhere I couldn’t get any of Drupal’s date formatting functions to work – they were expecting a unix timestamp (makes sense) but the Schema API uses ‘datetime’ as a field type on MySQL so was getting a MySQL date string in return.

I’ve been using Drupal in earnest since the New Year, and I have to say that I wish I’d discovered it sooner. It’s by no means perfect, but I think perfection is impossible with CMS systems and it’s doing everything I need it to.

I think I’ve finally found an almost perfect suite of tools to monitor webserver performance and availability – it’s only taken five years!

This post can relate to so many things – stylesheets, php code, glass fibre moulds – at some point when you’ve gone through a few iterations of an agile like process, you start thinking “If I’d known I was going to end up doing this, I would have started differently”

Not unique to Drupal, but common to any that use cookies to maintain login session information. I’ve met it before, but I just lost an hour and I have a brick shaped imprint in my forehead again, so I thought I’d drum into my head … don’t use underscores in domain names!

So often when using subdomains for setting up dev sites etc., it’s so easy to use site_dev.domain.com or similar. But, underscores are not valid characters in domain names.