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.

The answer was not to use datetime as a schema type, but int, and when passing data make sure you pass a timestamp. format_data() and views_handler_field_date etc. will then work as expected.

But it makes you wonder who left this mantrap lying around for foolhardy developers like me to fall into?

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.

Initially I was sceptical about using the Views module - I was thinking that Views are just for people who can’t be bothered to do proper PHP, but then I got into them and discovered the power and simplicity, and I have to say my first approach to most content display challenges in Drupal now tends to use Views.

But this leads on to one of my biggest gripes about Drupal - how much of the site configuration is stashed in the database where there is little accountability or control - I much prefer having files in the filesystem where you can use Version Control.

Then I discovered bulk export which does all of that - and it makes a big difference in safe use of Views. This is how I’ve done things several times now quite successfully:

• Carry out rapid development using the Views UI as normal.
• Enable the Views Exporter module - this turns on the ‘bulk export’ tab under ‘tools’ in the Views admin
• In Site Building > Views > Tools > Bulk Export, select the views that you want to export, and enter the name of the module you want to store the views code in and hit ‘export’
• Follow the instructions on the next page to add snippets to the .info and .module files, and to create the .views_default.inc file
• In Site Building > Views > Tools > Basic, click ‘Clear Views Cache’ button
• The right hand-most link against the views you exported in the admin list should now have changed from ‘delete’ to ‘revert’ - go ahead and ‘revert’ all the views you exported

That’s it - simples!

If you need to make any changes to exported Views, there are two approaches:

1. Modify the exported php directly in the .views_default.inc file - these changes should be immediately reflected on the site, but you might need to hit ‘Clear Views Cache’ just to be sure.
2. Use the Views UI, and re-export the views again, save the updated .views_default.inc file, then hit ‘revert’ on the list to use the file version

I’ve found it very useful when there are two or more enviornments being used for development (e.g. dev and live) to be able to spot that a local change has been made to an exported view by the presense of the ‘revert’ link - using diff on exports gives you a clue to what setting changed - a bit fiddly but not as bad as trying to go through every setting the UI one at a time to spot the difference. It’s also very reassuring to have Subversion (or your vrsion control system of choice) keep all your various environments in sync.

The final trick to pass on that has made my life much simpler is proper use of names and tags in views - if all the views for your module have the same prefix to their name, and the same tag, it makes it much easier to spot them all in lists, and to select them all together when you come to re-export them - it’s very embarrassing if you miss one and a whole section disappears from the site! If you need to rename or add tags - it’s easy to spot in the exported code where they can be changed, and that’s something you can’t do through the UI.

Now if only I could get more of Drupal’s config in the filesystem this way …

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.

Firefox is forgiving, and behaves as you would hope, but IE7, Opera etc. won’t properly set cookies on domains with underscores.

Solution - use hyphens instead e.g. site-dev.domain.com

In an article on A List Apart ‘Return of the Mobile Stylesheet‘, Dominique Hazaël-Massieux starts by reviewing the ‘ideal’ approach to making a site mobile friendly:

Ideally, site authors would be able to meet the growing demand for a quality mobile experience without changing a line of code. But the reality is that a site designed specifically with mobility in mind will always provide a much better user experience to mobile users, even when they are equipped with the device du jour. It’s not merely a question of network costs and delays or memory and CPU limitations. Rather, the mobile experience merits its own design, as discussed in a growing body of literature, including the W3C’s very own Mobile Web Best Practices, released in July 2008 as a W3C Recommendation. The formula for a mobile experience provided by Little Springs Design sums up the goal nicely: mobilize, don’t miniaturize. Mobile users operate in a very different usage context than PC users, and providing them with an experience customized to their needs is likely to be the best service you can offer to them.

But then he goes on to describe “a first step toward mobile design that uses CSS to maximize interoperability across platforms” asserting that “by starting simple, you can provide a decent initial experience, solicit user feedback, and iterate toward a more mobile-friendly design.”

Shame - because the likelihood is that if you put all your effort into a CSS solution, which is sub-optimal (in my view) because devices still have to load bloated code, and you probably end up with compromises for bot mobile and ‘normal’ browsers amongst other reasons, you’re much less likely to make the bigger step of producing a version of the site optimised for the mobile experience.

Many platforms make it quite simple to do this - there are mobile modules and plugins I’ve seen (and used) for Wordpress, Drupal etc. - if you’ve got server side logic, and preferably some form of content management / delivery system going on, it should be not much more than switching to a simpler theme for your presentation when a mobile device is detected.

But then that’s easy for me to say, because I still haven’t done it in anger to any large extent (yet).

Is Christmas a time for blog posting?

Certainly a chance to review the year, and catch up on things that have been missed. I’ve been lax in not keeping up with progress in mobile content delivery for instance, but it’s not out of choice.

Scanning some emails and posts just now I came across a summary of what’s been hapenning over at the mobiForge (ex dev.mobi) and I feel unbearable guilt that I haven’t tried their DeviceAtlas yet. But I do note with some satisafction that in one article they’re plugging the use of a lightwieght device detection function from  Andy Moore that seems to do a similar thing (but no doubt much better) to what I was playing with a couple of years back.

New Years resolution - make the time to keep up with this stuff, ‘cos it interests me and I’ll need it one day!  (see Perl xkcd strip!)

Sorry to post another xkcd strip, but they just keep hitting home:

http://xkcd.com/519/

I just had to look it up on wikipedia ‘cos it was bugging me - the British equivalent of 11th Grade in ‘my’ terms is Lower Sixth, or in ‘new money’ Year 12.

I’m trying to remember what I was doing that enhanced my life in the Lower Sixth - certainly not Perl which I didn’t discover until much later - I was probably doing good old BASIC and Pascal on an Apple II at that time, and perhaps some 6502 machine code on my Acorn Atom. Now that dates me!

I had an email today from Google saying that one of my Google Analytics accounts now had an Event Tracking feature enabled - unfortunately it’s not an account that has much use so I’m going to have to do something tricky to have a play.

I’m keen to have a go - I use GA quite a bit for a few sites and I really like what I see - it might not be as powerful as some of the big expensive tools, but for most purposes it’s quite good enough.

Having to abuse it a bit to track things like banner clicks, JavaScript events, Flash actions etc. has always rankled  - you never quite managed to properly track these fake page views, it interrupted the limited view you had of user journey, and it gave an inflated value for number of page views.

I had heard event tracking was in the pipeline, and I’m keen to give it a crack.

You know sometimes how the simplest little issue holds you up for days? Well I’ve just had a doozy!

I’m maintaining an inherited CMS application that I’m still having to trust that some of the inner workings ‘works’ because it’s all a bit involved and I’m not getting paid to rip it all apart for the sake of it.

We’re deploying the app onto new servers - something that I’ve done a few times so I wasn’t scared - but this time I just couldn’t get it to work - calling up pages I was getting “Content Encoding Error” messages from Firefox, and generally not helpful responses from other browsers.

The app was using GZIP to compress output where browsers support it using ob_gzhandler I knew, and if I commented out the gzip bits it was working, but that wasn’t something I wanted to do - and I was determined to find out why the same codebase wasn’t working on this environment with almost identical configuration to others that it did work on.

To cut a long story short - there’s a configuration include called at the start of each page that’s not under version control (for obvious reasons), and on this server it somehow acquired a couple of line breaks at the end after the closing php tag, so it started the html output early.  Nothing to do with double encoding or other potential issues I found when Googling.

I’ve used Amazon S3 for some time now on and off - it’s a great, fast, cheap service, but it does have its own quirks.

Developing a site that hosts a Flash movie displaying a series of flv encoded videos, we decided to host the flv content on S3 to save on bandwidth costs in case we got mass amounts of traffic.

First problem we encountered was performance - with a bucket created using the default location the videos were loading slower than they were playing, but switching to use a bucket created to be located in Europe, the speed has no longer been a problem.

The last issue which really took some head scratching was reported by some testers that the videos weren’t loading - they tended to be testing from behind corporate firewalls.

It would seem that when we used the S3Fox Firefox extension to upload the files, it didn’t know what flv’s were so didn’t set a Content-type. S3 default response is not to sent a Content-Type, which it would appear these obtuse firewalls didn’t like so blocked it.

The solution was to knock up a php based upload script using the Amazon S3 PHP class written by Donovan Schonknecht specifying ‘video/x-flv’ as a Content-Type - works a treat.

A piece by Raphael Pontual in this months .net magazine led me to think about what it is I do, and how I expect to compete in a marketplace filled with those who spend far more time than me keeping up with current techniques and technologies.

I’m only just starting to really get into jQuery and design patterns, and I have to make an effort not to keep reverting to old tried and trusted old skool strategies that have worked for me in the past.

The piece I believe was more aimed at design, but a relevant excerpt is: “It might seem crazy, but the older and busier you become, the less time you have to find out about the latest trends and adapting to the new graphics software. Meanwhile, there’s always a new generation that spends hours learning everything about the latest creativity suite.”

I’m a developer, not a designer, but I get what he’s saying, that successful professionals concentrate on identifying and solving problems, rather than just throwing gadgets and glitz at a project. A design for the sake of it is nonsense, it has to solve the problem, and the best solution is often the simplest whether it uses the latest whizzbang2.0 bling or not.

A good friend Sujvala kindly left a comment on an old post of mine ‘I want to be Clarkson‘ and one opinion he has is that I have an ‘infantile enjoyment of new toys‘ yet I’m ‘old enough to keep the safety catch on whatever is being tinkered with‘. I really like that.

Yes I do like toys, especially well thought out ones, but there’s a big difference between a toy and a tool. A tool has to earn a living.

The challenge when developing for the web, or making a fibreglass mould, or fitting a satellite dish (or most of my other previous employments) is to identify what it is you’re trying to do, what the challenges are, and what the most appropriate methods are to solve those problems.

Tried and tested (and safe) often beats bleeding edge, although you always have to be open to the idea. As Confucius said “It does not matter how slowly you go so long as you do not stop.“