Analytics tracking for Lightbox 2 image galleries

I use the Lightbox 2 plugin for the image galleries on this site— it’s a pretty great plugin: loads fast, looks nice, easy to implement… but one gripe I’ve had for a while is the inability to track image views with Google Analytics.

Problem solved…

Open up the file lightbox-resize.js (or lightbox.js if you’re using the non-resizing version), and go down to the showImage: function(), around line 323. You’re going to want to add a line at the end of the function, so it looks like this:

  1.  showImage: function(){
  2.   Element.hide('stimuli_loading');
  3.   new Effect.Appear('stimuli_lightboxImage', { duration: resizeDuration, queue: 'end', afterFinish: function(){ myLightbox.updateDetails(); } });
  4.   this.preloadNeighborImages();
  5.   pageTracker._trackPageview(imageArray[activeImage][0]);
  6.  },

Now, when an image is opened in a lightbox, the image URL will get passed to Google as a pageview. The console output, for those interested, looks like:

To test this, I’m using the Google Analytics Tracking Code Debugger for Chrome.

Events vs. Pageviews

I think the proper way to do this would have been to generate an event, not a pageview… but I’d like to be able to use the click data overlay view within analytics. With the way I have it now, I’ll be able to easily see which images were most clicked within my image galleries.

[highlight]Update: 10/30/10[/highlight]
I didn’t actually confirm that the pageviews were coming through in my Analytics report when I first published this article. A few days later, I noticed that even though the debugger said the beacons were being sent, no data for the image clicks was showing up on my reports. You can see in the screenshot above that my account was being sent as UA-XXXXX-X, not the real account number. It turns out that the Analyticator plugin I’m using for wordpress uses the asynchronous tracking method, not the older synchronous method that I was using in my example above (the above example should still work for the synchronous code).

Then I had a problem with the URLs coming through with the domain name (which is how Lightbox2 refers to them) when Google expects them to only be the path. This was giving me a content item of To fix it, I added a little string modifier to remove the first 27 characters of the string before it’s passed to the tracker. This is very hack-y and not good, I’m hoping someone will give me a better suggestion, but for now, it’s working. The code looks like this:

  1.  showImage: function(){
  2.   Element.hide('stimuli_loading');
  3.   new Effect.Appear('stimuli_lightboxImage', { duration: resizeDuration, queue: 'end', afterFinish: function(){ myLightbox.updateDetails(); } });
  4.   this.preloadNeighborImages();
  6.   var urlString = imageArray[activeImage][0].substr(27);
  7.   _gaq.push(['_trackPageview', urlString]);
  8.  },

Conditional Loading Facebook Scripts

I’m working on a client project currently which employs a “Like” button on each of the post pages– but nowhere else on the site. You can see here, Facebook requires 253.2 KB worth of scripts (54% of the entire page!) and adds 2.73 seconds to the page load time (52% of the time).

I’m using the Simple Facebook Connect plugin for the Like button.. so I went into the sfc-base.php file in the plugin’s folder, and tried to find a way to prevent the plugin from loading on non-post pages. After a bit of trial and error, I eventually added a conditional if is_single() to the Facebook script loading function (see line 9 below).

  1. // load the FB script into the head
  2. add_action('wp_enqueue_scripts','sfc_featureloader');
  3. function sfc_featureloader() {
  4.  if (is_single()){
  5.   if ($_SERVER['HTTPS'] == 'on')
  6.    wp_enqueue_script( 'fb-featureloader', ''.get_locale(), array(), '0.4', false);
  7.   else
  8.    wp_enqueue_script( 'fb-featureloader', ''.get_locale(), array(), '0.4', false);
  9.  }
  10. }

Now the Facebook script only loads on individual posts, and the rest of the site is 3 seconds snappier!

Universal-Video Plugin Troubleshooting

I’ve been using Rob McGuire’s Universal Video plugin for WordPress to handle the videos on this site.. which is great because it’s HTML5 based, but reverts to a Flowplayer flash player for older browsers.

I had a few problems getting video to play in any browser other than Chrome, so I’m providing my fixes below, in case anyone else runs into similar problems:

HTML5 video won’t load in Firefox/Safari

Make sure the ogv mime types have been added to your Apache configuration. You can add to your httpd.conf:

AddType video/ogg .ogm
AddType video/ogg .ogv
AddType video/ogg .ogg

Or, in your hosting control panel, look for a MIME type option, and add

MIME type: video/ogg
Extensions: ogg ogv ogm

If videos still don’t play, try relocating the Flowplayer .swf from /plugins/universal-video/player/ to /plugins/universal-video/. On line 34 in universal-video.php, make sure you change the path to the .swf:

  1.  $plpath = $wp_url .'/flowplayer-3.2.1.swf';

Flowplayer doesn’t load video file in IE

For me, the flash object would load, but right clicking on it would display an error: “Movie not loaded”. I fixed it by specifying an absolute path to the .swf in universal-video.php. So, for me, my line 34 read:

  1.  $plpath = $wp_url .'';

WordPress 3.0 Upload Image Fix

After upgrading to WordPress 3.0, I could no longer upload media in the visual editor. Instead of popping up in the lightbox, a whole new page would load, and no images would attach to posts.

In the Headspace2 plugin… go into /wp-content/plugins/headspace2/js and open the headspace-tags.js file. Around line 67 (function get_tag_element () {) change what’s there to the following:

  1.     function get_tag_element () {
  2.       if ($('#tax-input-post_tag').length == 1)
  3.         return '#tax-input-post_tag';
  4.       else if ($('#tags-input').length == 1)
  5.         return '#tags-input';
  6.       else if ($('#tax-input\\[post_tag\\]').length == 1)
  7.         return '#tax-input\\[post_tag\\]';
  8.     }

Refresh a couple of times, to clear your browser’s cache, and try and attach an image. The usual popup window should now load.

(If you don’t have Headspace2 installed.. maybe it’s some other plugin interfering..?)

Thanks to Aaron Campbell. Found at the Headspace bug tracker.

Compressor – “Unable to submit to queue.”

On trying to submit a job to Compressor (3.0.5, OSX 10.6.3 Snow Leopard – 64 Bit) I would get an error:

"Unable to submit to queue. Please restart your computer or verify your Compressor installation is correct."

Restarting the computer did not fix the problem. After poking around online for a while, I learned that this error is caused by Qmaster failing to launch on system startup. Thankfully, you can manually launch Qmaster. Open a terminal, and run:

cd /usr/sbin
sudo qmasterprefs -restart

Open Compressor again, and the job should submit. I have to do this every time I want to use Compressor– but at least it works.