XKCD- Wisdom of the Ancients

Filed under: web development — jaydublu @ 6:09 pm

All long help threads should have a sticky globally-editable post at the top saying 'DEAR PEOPLE FROM THE FUTURE: Here's what we've figured out so far ...'

Been there – got the t-shirt.

Installing and XHProf to profile Drupal on Ubuntu

Filed under: drupal,web development — jaydublu @ 2:48 pm

The following recipe was used to install XHProf on a Ubuntu server running Drupal 6, inspired by http://techportal.ibuildings.com/2009/12/01/profiling-with-xhprof/ – my PEAR installer complained about missing config.m4, and I couldn’t find Brian Mercer’s php5-xhprof Ubuntu package.

Download and manually install XHProf:

wget http://pecl.php.net/get/xhprof-0.9.2.tgz
tar xvf xhprof-0.9.2.tgz
cd ./xhprof-0.9.2/extension/
./configure --with-php-config=/usr/bin/php-config
make install
make test
cd ..
cp -rp xhprof_html /usr/share/php/
cp -rp xhprof_lib /usr/share/php/
mkdir /var/tmp/xhprof
chown www-data /var/tmp/xhprof

Optional – install graphviz for the Callgraph funtionality

apt-get install graphviz

Create /etc/php5/conf.d/xhprof.ini



alias /xhprof_html "/usr/share/php/xhprof_html/"

Restart Apache

apache2ctl graceful

Configure Drupal in /admin/settings/devel

xhprof directory: /usr/share/php
xhprof URL: /xhprof_html

Now to get my head around what it all means!

Limiting access to Drupal content types

Filed under: drupal,web development — jaydublu @ 1:43 pm

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. But what if it’s a core or CCK content type and you want to keep things simple?

Well here’s a ‘light’ way to restrict access to a given content type (‘mytype’ in this instance) to the owner of the node and any given role (‘administer nodes’ in this instance although it could be anything). Put this anywhere convenient and off you go.

 * Implementation of hook_nodeapi()
 * Limit viewing of mytype nodes to owner and admins.
function mymodule_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
  global $user;
  if ($node->type == 'mytype' && $op == 'view') {
    if (!user_access('administer nodes', $user) && $user->uid != $node->uid) {

Storing dates in Drupal Schema API

Filed under: drupal,web development — jaydublu @ 6:25 pm

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?

Drupal Views bulk export

Filed under: drupal,web development — jaydublu @ 5:06 pm

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 …

Can’t log in to Drupal site in IE7, but can in Firefox?

Filed under: web development — jaydublu @ 12:20 pm

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

Mobile Stylesheets

Filed under: mobile,opinion,web development — jaydublu @ 2:41 pm

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

Mobile device detection

Filed under: mobile,web development — jaydublu @ 7:36 pm

mf-xmas.jpgIs 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!)

XKCD: 11th Grade

Filed under: life,web development — jaydublu @ 6:21 pm

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

And the ten minutes striking up a conversation with that strange kid in homeroom sometimes matters more than every other part of high school combined.


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!

Google Analytics Event Tracking

Filed under: web development — jaydublu @ 10:51 am

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.

Next Page »