Moving away from WordPress.com and 10 must-have WordPress plugins

Moving-Day-Pic-for-Blog-Post-2a0i04v

Last night, with a couple of hours to spare, I decided to get on and move my blog away from WordPress.com to my own hosting.  Why do this?

  • Access to my own Google Analytics data
  • Use of any plugin I like
  • Association my content with my domain name
  • Greater control over the site, to, for example, add Google Authorship links

I’ve been running the blog on WordPress.com since 6th December 2007, but time has come to move to new pastures.   The move process was very simple:

  1. Set up WordPress on my Linux server (5 minutes)
  2. Export existing blog content using WordPress XML export
  3. Import XML into new blog
  4. Pay $12 / year to 301 all pages / posts from the old blog to the new domain
This was I won’t lose any of my Google ranking weight, and users won’t get the dreaded 404 on that key post they were looking for.
To get my new blog up to scratch I did some research and loaded up the following 10 awesome WordPress plugins:
  1. Akismet – the de facto comment and trackback spam protection
  2. Digg Digg – add as many social media buttons as you can shake a stick at
  3. Google Analytics for WordPress – all in the name
  4. Head Space2 – manage SEO meta-data to a fine grained level
  5. Multi Social Favicon – auto-generate the blog favicon using a social media account
  6. Smart Video – simple YouTube, Vimeo video embeds
  7. SyntaxHighlighter Evolved – awesome syntax highlighting for code in posts
  8. Tweet old post – keep old posts alive by tweeting them every now and then
  9. W3 Total Cache – speed up your blog with caching
  10. WP-DBManager – database management, backups – essential
WordPress is an awesome blogging platform; it moves out of the way so you can focus on writing content.  And with the large plugin and theme offerings out there, there’s no excuse to share your knowledge with the wider community.
Get on and write something!
Advertisements

Clearing up the confusion over session timeouts in PHP and Zend Framework

I’ve recently made a foray into the world of Zend Framework.  If you’ve not come across it, it is one of several popular PHP frameworks that implements the Model View Controller software architecture.

By day I’m mostly devoted to hacking ASP.NET MVC, but having had some experience with PHP I decided to get my teeth stuck into Zend for a new PHP project I’ve been working on.  Somewhere in my head I have another blog post to write about the dyer state that is documentation for Zend, but that’s a topic for another night.

This post details my journey through figuring out how PHP sessions really work and how to fix them for properly bringing down a user’s session after a period of inactivity, in the context of Zend Framework (although most of the post applies to PHP proper).

Get your server’s clock synchronised

The PHP session files are date-stamped when they are created/updated.  The PHP Session cookie that gets sent to the browser has an expiry date-stamp on it.  While you can’t rely on the client’s system clock to be correct, making sure your server’s is makes debugging less of a headache.

On a Windows server this should already be set up – if not check the Date & Time Properties in Control Panel and pay attention to the Internet Time tab.  On a Linux server it’s a case of installing and configuring the ntp package – a bit of Googling should show you the way with whichever distribution you are using.

The options for session timeouts

There are a number of options as to how you can handle session timeouts, as I see it:

  1. Keep the session alive until the user closes their browser
  2. End the session after a fixed period of time (regardless of activity)
  3. End the session after a fixed period of time with no activity
  4. Some combination of the above

I’d put my money on the best user experience being a combination of point 1) and point 3).  This, rather surprisingly, isn’t as straightforward as you would hope.

PHP Session Settings – What they mean

image

There are a handful of PHP settings relating to sessions, and understanding how sessions work and what these settings do is critical to getting the behaviour you desire.

PHP sessions are stored as files (by default) – the files contain a serialised version of the $_SESSION superglobal arrray.  The path to these files is set by session.save_path.

N.B. Security Warning – make sure no other users can get to the session directory.  Files are stored unencrypted and therefore should be treated with the same caution as password files.

An interesting side note: if you inspect the cookie PHPSESSID (the default name for the PHP Session Cookie), you’ll notice a funny looking value.  Now take a look at the contents of the PHP session directory – hey presto, there’s a file called sess_<SESSIONID>. Simple eh.

Each time PHP session_start() is called (which is not just when you first start a session, but every time you want to load session data into your app, i.e. on every request for most apps), PHP works out whether or not it should run the session garbage collector.

Garbage – what garbage?

The session garbage collector runs around and checks all of the timestamps on the session files and compares them to the current time less the session.gc_maxlifetime value, to work out if a file should be deleted (because it has exceeded it’s lifetime).

You might think that the garbage collector would run on every session_start(), to avoid any expired session files being left hanging around.  However there is a performance overhead with this and so PHP uses two settings, session.gc_probability and session.gc_divisor to calculate the probability that it should run the garbage collector (it does this by dividing the two and then rolling it’s own dice to see whether it should run).

N.B. Remember that each time you access the session the timestamp on the session file gets updated, this stops the garbage collector from killing a user’s session while they are still active.

This all sounds very cosy and like it will do just what I want – dump the user’s session after a period of inactivity (as specified by session.gc_maxlifetime).  And on low volume sites you could force the garbage collector to run every time by making the probability 100%.

However, all is not quite so straightforward!

The order of things

I’m sure there’s a good reason for this, but I’m not aware of what it is.  PHP first loads up the session, then works out if it should run the garbage collector.  So even if the garbage collector runs every time and the session file has expired, on the first request the user will appear to still have a session, and then only on the next request they won’t.

Imagine this scenario.  A user has logged in to your site.  They go away for lunch, and during that time their session has expired.  They come back and hit refresh – the screen reloads with their session apparently intact.  All is looking good.  Then they click somewhere else and bam – their session is gone.  Kinda confusing really.

In an ideal world there would be a way to check for dead sessions before the session fires up, and in fact there is, but you have to roll it yourself.

Did I mention Zend Framework?

So far everything I have covered is PHP proper, no mention of Zend.  However the Zend_Session object is based on all of these settings, and therefore it warrants understanding the underlying PHP behaviour first.

The solution to this problem is to roll your own inactivity timeout check.  I needed this to implement inactivity logouts.  I used the following code to do my tracking:

$idleTimeout = 3600; // timeout after 1 hour

if(isset($_SESSION[‘timeout_idle’]) && $_SESSION[‘timeout_idle’] < time()) {
Zend_Session::destroy();
Zend_Session::regenerateId();
header(‘Location: /account/signin’);
exit();
}

$_SESSION[‘timeout_idle’] = time() + $idleTimeout;

N.B. If you’re not using Zend Framework you can exchange the Zend_Session lines for their standard PHP equivalents.

All this does is check if we have an idle timeout set in our session (remember this gets loaded even if the session has technically expired) and if it has fallen past the current time we tear down the session, regenerate the session ID (to avoid picking up the existing session file) and head off to the log in screen.

Specifically to Zend, you can set the following settings in the application.ini file:

resources.session.gc_probability = 1
resources.session.gc_divisor = 1
resources.session.gc_maxlifetime = 3600
resources.session.idle_timeout = 3600

And then place the custom idle time out code inside this function in Bootstrap.php:

protected function _initSession()
{
# set up the session as per the config.
$options = $this->getOptions();
$sessionOptions = array(
‘gc_probability’    =>    $options[‘resources’][‘session’][‘gc_probability’],
‘gc_divisor’        =>    $options[‘resources’][‘session’][‘gc_divisor’],
‘gc_maxlifetime’    =>    $options[‘resources’][‘session’][‘gc_maxlifetime’]
);

$idleTimeout = $options[‘resources’][‘session’][‘idle_timeout’];

Zend_Session::setOptions($sessionOptions);
Zend_Session::start();

# now check for idle timeout.
if(isset($_SESSION[‘timeout_idle’]) && $_SESSION[‘timeout_idle’] < time()) {
Zend_Session::destroy();
Zend_Session::regenerateId();
header(‘Location: /account/signin’);
exit();
}

$_SESSION[‘timeout_idle’] = time() + $idleTimeout;
}

And that’s all there is to it!

If you know the reasoning behind some of these apparently strange PHP session operations then please post them here – I’m left scratching my head in a daze at how complex a matter it has been to implement such a standard bit of user experience.

Using O2 ZTE MF100 Mobile Broadband on Mac OS X Lion

A few days ago I took the leap and upgraded my Macbook Air to OS X Lion.  After a seamless (and typically Apple) upgrade process, I was enjoying the benefits of an even more refined operating system.

However, one of the first things I did was test out my mobile broadband – and there the problem began.

I have an O2 mobile broadband dongle, the ZTE MF100 USB stick. When I originally installed it a small application called O2 Mobile Connect installed and worked a treat for connecting to the O2 service.

After upgrading to OS X Lion the application crashed as soon as it opened – I assume because of a change in an API somewhere. After hunting around the O2 site (and Google) I could find no update on getting the Mobile Connect application to work on Lion, or even where to download it.  It would appear that O2 have ditched supplying the ZTE dongles in favour of Huwaei branded sticks.

Anyway, I was damned if I was going to lose my mobile broadband (and I certainly didn’t want to uninstall Lion), so here’s how I eventually got the stick working:

  1. Open System Preferences
  2. Click on the plus sign to Create a new service
  3. Choose ZTEUSBModem as the interface
  4. Name the service O2 Mobile Broadband (or something recognisable)
  5. Set Telephone Number to *99#
  6. Set Account name to 02web
  7. Set Password to password

Note that this is for Pay Monthly Broadband – I think the details are different for Pay & Go customers.

Key step: set DNS server to 193.113.200.201

And hey presto, I now have mobile broadband working again.

Hope this helps anyone out there trying to get it working.

The Novice’s Guide to Replacing a Bathroom – Part 2

In late April (this year) I started out as a novice replacing our main bathroom. Last night I finished the bathroom project, and although still a novice, I’ve certainly learned a thing or two.

The Motivation

It’s taken me two months, and a lots of hours of work, late at night and during weekends. I could have paid someone to do this, but I wanted the satisfaction of understanding how it works, and it’s been a nice distraction from work.

The Final Outcome

The bathroom now looks nice and clean, spacious and modern, while retaining some of the history of the house (I’ve left the old radiator in, the door and window frames are the same).  We have a new toilet, sink and taps, bath and taps, new floor, new tiles, new light, new mirror and rails.  We’ve kept the old shower (which is actually quite new).

It should be good for many years (and baths) to come!

Laying the new floor

What I’ve Enjoyed

The most rewarding moments have been grouting the tiles (turns an ugly looking wall into a very nice finish), fitting the skirting board and connecting up the taps.  The one job I paid for was fitting the tiles – this took an experienced handyman a whole day just to cut and fix the tiles – I did most of the grouting.  This would have taken me at least twice as long to do.

In goes the bath

What I’ve Learned

Ripping out the bathroom initially took a lot longer and was a lot more difficult than I had anticipated.  This may have been in large part to problems with leaking pipe stops and not having the right tool to undo the bath taps.

Almost every plumbing joint I made leaked the first time around. Compression fittings like to be nice and tight, then they work fine without any PTFE tape or sealant. However, plastic pipe fittings (in particular the water inlet to the toilet cistern and the bath waste) took several attempts to get them sealed. I naively assumed that just fitting the supplied rubber washers would do the job. In the end I resorted to large amounts of silicone sealant – I’d pump this in first time from now on.

Building a budget VMWare ESXi server

The Background

One of the projects that I’ve been working on recently requires a lot of interaction between different systems, and in order to roll-out changes and carry out integration testing I needed a replica of our production environment.  However the challenge was that it required 7 machines to replicate production.

In the past I’ve happily run a few virtual images on my desktop machine, albeit paired back to 500MB RAM each.  But 7, there’s no way that’s going to run on my current desktop, even if I had enough RAM.

So I decided it was time to invest in some hardware to give me the flexibility to build larger virtual environments.

This is where VMware’s awesome ESXi product comes in (which I see has now been renamed to vSphere Hypervisor 4.1).

ESXi 101

I won’t repeat what many excellent blog posts have already said about ESXi, but essentially it’s a small operating system which can run multiple virtualised machines on top it – by providing a virtual hardware layer to the virtual machines, it can share the underlying physical system resources out. The sweet thing about this is that you can start and stop virtual machines in a matter of seconds, and very easily duplicate machines. So on one reasonably powered server, you can run a bunch of virtual machines thereby reducing your hardware overheads.

This kind of approach is great both for business line systems and development environments.  I will of course be using it for the latter.

The Hardware

One of my big concerns was getting compatible hardware, and not paying too much for it. After some Googling and talking to fellow geeks I settled on the HP Proliant ML110 G6.  This is an entry level HP server and the base build comes with a 250GB SATA drive and 1GB RAM.

Whilst I couldn’t do much about the processor, the main two limiting factors were the disk space and RAM.  Most of the virtual machines I want to create are circa 50GB each, so 250GB would run out very quickly.

Therefore I made two upgrades: I bought a Western Digital 1TB ‘green’ SATA drive (only 5400 RPM) and 8GB RAM (2x4GB).

I bought the server and the SATA drive from eBuyer and the RAM from Crucial – total spend approximately £400.

Installation

With the new hardware in place I needed one other item – a 2GB USB stick.  Yes, to make life easier you can install and boot ESXi from a USB stick, rather than take up space on your image storage drives. And the HP machine’s motherboard came with an on-board USB socket – so I simply plugged the stick into the motherboard.

I initially installed the special HP version of ESXi – supposedly it is preferable because it comes with all of the HP drivers.  However after one hour of running I discovered the kernel had performed a memory dump, and after several reoccurrences I ditched it and went back to the vanilla ESXi image and haven’t had any problems since.

Once booted it’s best to assign a static IP address to your ESXi box and then that’s it – I’ve stashed mine away in the garage.

Day-to-day use

My ESXi Server (on the right)Once the server is set up you can forget about needing to be near it, as you do everything from the equally awesome (although sometimes annoyingly sluggish) VMWare vSphere Center program. This tool allows you to create new virtual machines, upload ISO images to the datastore (you’ll need these to install any software, i.e. the operating systems for your virtual machines).

So now when I’m ready, I fire up my the virtual lab in question and I can happily run all 7 virtual images on 1GB RAM each.

And when I’m ready, I can max the RAM up to 16GB!

Happy ESXing!

Another useful reference:

Techhead – Installing VMWare ESXi 4.0 on a USB Memory Stick

Synchronising Highrise, Basecamp and Google Shared Contacts–Part 2

Background: In Part 1 of this series I wrote about a recent project that I worked on to synchronise contact data between a number of web applications, and how I had to work around the (current) shortcomings of their APIs.

As Scott Hanselman says, “talk is cheap – show me the code”.  So here we go…

Basecamp & Highrise APIs

Implementing an interface to the Basecamp & Highrise APIs is relatively straightforward – I did it using PHP’s curl().  My implementation doesn’t support all of the API’s functions, but you should be able to easily add any additional calls that you need.

The functions centre around a single function which does the hard work on making the request:

private function _getData($uriExtension) {
$base_url = $this->url.$uriExtension;
$session = curl_init();
curl_setopt($session, CURLOPT_URL, $base_url);
curl_setopt($session, CURLOPT_USERPWD, $this->apiKey.':X');
curl_setopt($session, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);
curl_setopt($session, CURLOPT_HEADER, false);
curl_setopt($session, CURLOPT_HTTPGET, 1);
curl_setopt($session, CURLOPT_HTTPHEADER, array('Accept: application/xml', 'Content-Type: application/xml'));
curl_setopt($session, CURLOPT_RETURNTRANSFER, true);
curl_setopt($session, CURLOPT_SSL_VERIFYPEER,false);
curl_setopt($session, CURLOPT_FRESH_CONNECT, true);
$response = curl_exec($session);
curl_close($session);
$xmlObj = new SimpleXMLElement($response);
return ($xmlObj);
}

Google Shared Contacts

This was simply done using the Zend GData classes which you can grab here.  Here’s some sample code for updating a shared contact in Google:

$client=$this->googleClientAuth('cp');
$client->setHeaders('If-Match: *');
$gdata=new Zend_Gdata($client);
$gdata->setMajorProtocolVersion(3);
// get the existing contact.
$query = new Zend_Gdata_Query($id);
$entry = $gdata->getEntry($query);
$xml = simplexml_load_string($entry->getXML());
// update title.
$xnl->title = $title;
// update the fullname.
$xml->name->fullName = $title;
// update entry.
$entryResult = $gdata->updateEntry($xml->saveXML(), $entry->getEditLink()->href);

Get more details over at the Google Apps Shared Contacts API page.

Basecamp & Highrise – Filling in the API gaps

So the big problem with the Basecamp & Highrise APIs is that they have bits missing – rather significant bits it turns out.  In particular the ability to create and update companies.

To get around this I wrote a couple of classes that use a combination of curl() and the awesome phpQuery to walk through the front-end pages and execute URLs just as a real user would.

Whilst this is not impervious to UI changes by 37Signals, it’s a fairly generic implementation and it’s a best endeavours approach given the current lack in the APIs.

Here’s some sample code:

public function createCompany($companyName) {

$success = true;

// go to the company page first, to get the token.
$resp = $this->_fetchUrl($this->_urls['base'].$this->_urls['companies'], 'GET', array(), false, $this->_ch);

phpQuery::newDocument($resp['data']);
$authToken = pq('input[name=authenticity_token]')->val();

$formFields = array(
'authenticity_token' => $authToken,
'company[name]' => $companyName,
'commit' => 'Create Company'
);

$resp = $this->_fetchUrl($this->_urls['base'].$this->_urls['companies'], 'POST', $formFields, false, $this->_ch);

// check - has this company already been created?
phpQuery::newDocument($resp['data']);
if(pq('div.flash_alert')->text() != '') {
$success = false;
$this->_errMsg = pq('div.flash_alert')->text();
}

return $success;
}

Show me the code!

So, in the hope of helping others to get synchronisation working (and work around the lack in the APIs) you can download the code at GitHub for your own use.

Enjoy!

Synchronising Highrise, Basecamp and Google Shared Contacts–Part 2

Background: In Part 1 of this series I wrote about a recent project that I worked on to synchronise contact data between a number of web applications, and how I had to work around the (current) shortcomings of their APIs.

As Scott Hanselman says, “talk is cheap – show me the code”.  So here we go…

Basecamp & Highrise APIs

Implementing an interface to the Basecamp & Highrise APIs is relatively straightforward – I did it using PHP’s curl().  My implementation doesn’t support all of the API’s functions, but you should be able to easily add any additional calls that you need.

The functions centre around a single function which does the hard work on making the request:

private function _getData($uriExtension) {
  $base_url = $this->url.$uriExtension;
  $session = curl_init();
  curl_setopt($session, CURLOPT_URL, $base_url);
  curl_setopt($session, CURLOPT_USERPWD, $this->apiKey.':X');
  curl_setopt($session, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);
  curl_setopt($session, CURLOPT_HEADER, false);
  curl_setopt($session, CURLOPT_HTTPGET, 1);
  curl_setopt($session, CURLOPT_HTTPHEADER, array('Accept: application/xml', 'Content-Type: application/xml'));
  curl_setopt($session, CURLOPT_RETURNTRANSFER, true);
  curl_setopt($session, CURLOPT_SSL_VERIFYPEER,false);
  curl_setopt($session, CURLOPT_FRESH_CONNECT, true);
  $response = curl_exec($session);
  curl_close($session);
  $xmlObj = new SimpleXMLElement($response);
  return ($xmlObj);
}

Google Shared Contacts

This was simply done using the Zend GData classes which you can grab here.  Here’s some sample code for updating a shared contact in Google:

$client=$this->googleClientAuth('cp');
$client->setHeaders('If-Match: *');
$gdata=new Zend_Gdata($client);
$gdata->setMajorProtocolVersion(3);
// get the existing contact.
$query = new Zend_Gdata_Query($id);
$entry = $gdata->getEntry($query);
$xml = simplexml_load_string($entry->getXML());
// update title.
$xnl->title = $title;           
// update the fullname.
$xml->name->fullName = $title;
// update entry.
$entryResult = $gdata->updateEntry($xml->saveXML(), $entry->getEditLink()->href);

Get more details over at the Google Apps Shared Contacts API page.

Basecamp & Highrise – Filling in the API gaps

So the big problem with the Basecamp & Highrise APIs is that they have bits missing – rather significant bits it turns out.  In particular the ability to create and update companies.

To get around this I wrote a couple of classes that use a combination of curl() and the awesome phpQuery to walk through the front-end pages and execute URLs just as a real user would.

Whilst this is not impervious to UI changes by 37Signals, it’s a fairly generic implementation and it’s a best endeavours approach given the current lack in the APIs.

Here’s some sample code:

public function createCompany($companyName) {

    $success = true;

    // go to the company page first, to get the token.
    $resp = $this->_fetchUrl($this->_urls['base'].$this->_urls['companies'], 'GET', array(), false, $this->_ch);

    phpQuery::newDocument($resp['data']);
    $authToken = pq('input[name=authenticity_token]')->val();

    $formFields = array(
        'authenticity_token' => $authToken,
        'company[name]' => $companyName,
        'commit' => 'Create Company'
    );

    $resp = $this->_fetchUrl($this->_urls['base'].$this->_urls['companies'], 'POST', $formFields, false, $this->_ch);

    // check - has this company already been created?
    phpQuery::newDocument($resp['data']);
    if(pq('div.flash_alert')->text() != '') {
        $success = false;
        $this->_errMsg = pq('div.flash_alert')->text();
    }

    return $success;
}

Show me the code!

So, in the hope of helping others to get synchronisation working (and work around the lack in the APIs) you can download the code at GitHub for your own use.

Enjoy!

Technology, Literature and the Rest