Getting CI and Facebook to play together nicely has not been a smooth ride however, and we’ve still not nailed all of the problems we’ve had, but now that a few of the giants are slain, we thought it was time to share the love.

Timing is against us however, because we’re running against all the old Facebook API, not the new Open Graph stuff that was kicked off at F8.

We know we’re going to have to rip out the guts of all the FB API call bits in a few weeks, but I’ll update that when we do (and get it working).

Huge props to Elliot Haugin for his library, that was a massive help in getting us started.

A few things up front, which might affect how you build:

• We’re working on an FBML based facebook application (not iFrame)
• It’s an actual FB app, not a separate website using Facebook Connect.
• All of this should also apply to iframe base FB apps too, but I thought I’d better be clear.
• Facebook Connect is a different beast, and I’ve not played with it yet.

If this is your first attempt at building a FB app, have a go with a single file of vanilla code to make Hello World first rather than inside a code framework – much easier to get the hang of what a Canvas URL is etc etc without having to worry about whether or not CI is getting in the way or it’s your FB set up.

We’re running a base install of CI 1.7.2, and the first thing we did was install Elliot Haugin’s Facebook Connect library.  We followed his instructions to install the library and set up the config in /applicaitons/config/facebook.php.

The bit about xd_receiver.htm is not relevant if you’re doing a FB app, rather than a Facebook Connect powered site, but do it anyway.

At this point we battled with FB for a little whilst trying to get the examples to work and failing miserably.  There were a few things we needed to do to make it work, namely replace the php wrapper, and add a bit of config to handle $_GET.

Call the library correctly in the controller

In our constructor we call

$this->load->library(‘facebook_connect’);

We could also do this inside the index function but we needed to have the Facebook User’s ID available in the constructor, so did it early.

When we want to access the library we then do it like this..

//to get the user’s Facebook ID
$this->facebook_connect->user['uid']

//to find if this application has permission to access the user’s email address
$this->facebook_connect->client->users_hasAppPermission(“email”);

//To run some FQL

$this->facebook_connect->client->fql_query(“SELECT email FROM user WHERE uid=12345678″);

The PHP Wrapper

The Facebook PHP wrapper used to change reasonably frequently, and to  make things that little bit harder wasn’t version managed, so I don’t know what version we’re currently (or ever have been) using.

When Elliot’s examples didn’t work, we tried dropping the latest facebook.php and facebookapi_php5_restlib.php into /application/libraries/facebook-client and things got a lot better.

We just downloaded the latest ones from http://wiki.developers.facebook.com/index.php/PHP though these will now not be available because of the Open Graph updates.

$_GET

FB throws you lots of stuff in the URL, and whilst we’d love to make use of it (track referrers etc) we had to stop it to make CI play nicely. FB will stuck things like ?id=2579980995&ref=ts on the end of your URLS, and then CI will 404.

To ditch all the information being passed by get we added a hook.  Basically every request to the app now gets it’s $_GET ditched.  Eventually we’ll handle this more gracefully. In /application/hooks we created Querystring.php with the following content

<?php

class Querystring  {

public function rewrite () {

$_GET = array(); }

}

?>

An at this point, we were up and running.  We need to construct purely directory based URLs, such as http://apps.facebook.com/wishli-st/wishlist/100001071971681 and not http://apps.facebook.com/wishli-st/wishlist/?fbid=100001071971681  but thats just good URL structures anyway right?

All will have to change with Open Graph becomes the only way to connect, but it should just be a case of switching out th PHP wrappers.

A multi-site tangent

We have also implemented a very rough form of multi-site config, just to make our lives easier.  Because Facebook relies on callback URLs, developing locally on your machine is tricky, and we’ve ended up with an app per developer.

The problem being that each app needs it’s own config, and with a junior team only just getting to grips with version management, people kept standing on each others toes and checking their personal config in over the live app.   The fix – more education, but also a “contact aware app”, which switches config settings depending on what domain it finds itself sitting on.  This is all pretty rough at the moment, but is up and running.

It works by detecting the host that the application is running on ($_SERVER['HTTP_HOST']) and setting a site wide constant based on it.  This constant is then used in config.php, database.php and facebook.php to switch between config arrays.  We also define a boolean constact for “quick switching” so we can turn logging on in dev, tracking on in live etc etc.

We made changes to the following files:

/index.php (the root index file)

Added the following lines near the top (domains changed to protect the innocent)

switch ($_SERVER['HTTP_HOST']) {

case “live.wishli.st”:

define(’site_identifier’, ‘live’, TRUE);

break;

case “test.wishli.st”:

define(’site_identifier’,'test’, TRUE);

break;

case “dev1.wishli.st”:

define(’site_identifier’,'dev1′, TRUE);

break;

case “dev2.wishli.st”:

define(’site_identifier’,'dev2′, TRUE);

break;

}

if (site_identifier == ‘live’)

{

//we are in live!

define(‘SITE_LIVE’, TRUE);

}

else

{

//somewhere else – could be dev or indeviduals test

define(‘SITE_LIVE’, FALSE);

}

We can now use ’site_identifier’ in case switches as follows:

/application/config/config.php

-to switch the base_url and the the logging levels (base_url example shown only)

//default to test, so if something goes wrong we don’t screw live

$config['base_url'] = “http://apps.facebook.com/xxxxxxx/”;

switch (site_identifier) {

case “live”:

$config['base_url'] = “http://apps.facebook.com/wishli-st/”;

break;

case “test”:

$config['base_url'] = “http://apps.facebook.com/xxxxxxx/”;

break;

case “dev1″:

$config['base_url'] = “http://apps.facebook.com/yyyyyyyy/”;

break;

case “dev2″:

$config['base_url'] = “http://apps.facebook.com/zzzzzzz/”;

break;

}

/application/config/database.php

-to switch between database config sets

//default to test

$active_group = “test”;

// now choice correct one

switch (site_identifier) {

case “live”:

$active_group = “live”;

break;

case “test”:

$active_group = “dev”;

break;

case “dev1″:

$active_group = “dev1″;

break;

case “dev2″:

$active_group = “dev2″;

break;

}

And then define an active group for each environment

$db['dev1']['hostname'] = “xxx”;

$db['dev1']['username'] = “yyyy”;

$db['dev1']['password'] = “zzzz”;

$db['dev1']['database'] = “aaaaaa”;

…etc etc

$db['dev2']['hostname'] = “bbb”;

$db['dev2']['username'] = “ccc”;

$db['dev2']['password'] = “ddd”;

$db['dev2']['database'] = “eee”;

/application/config/facebook.php

- the same trick as above – change the config array based on the switch.

/default is test

$config['facebook_api_key'] = ‘aaaaa’;

$config['facebook_secret_key'] = ‘bbbbb’;

// now switch based on site_identified

switch (site_identifier) {

case “live”:

$config['facebook_api_key'] = ‘ccccc’;

$config['facebook_secret_key'] = ‘dddd’;

break;

…etc etc

Eventually I’ll clean this up and make it into a CI mod of some kind, for the moment, it’s how we roll.

Luckily the man himself seems to have provided the answer.  Imagine our surprise when we found this little gem on Wishlist last night:

That’s right, the big man has clearly made a choice and is preparing to go, queuing up the things that he’ll need on the next stage of his life including The Backpacker’s Bible Revised Edition, Just for Men Shampoo-in Hair Colour Dark Brown, The Bogleheads’ Guide to Retirement Planning and Hardwood WideBoy Deckchair.

You can find his full list over on the Facebook app, we’ve even included a special tab to celebrate our first celebrity wishlist.

The magic is all done by the FBML tag tag, which is sadly not brilliantly documented. However, after lots of Googling and experimenting, we got it working, and here’s how…

There are three bits

1. The backend to generate the data for auto populating with
2. The FBML selector (this is what the user will see)
3. The backend to handle the request once somebody selects something

The backend…

Needs to produce an array of id’s and names.  The id will be set as the value that the form submits, the name will be the bit people see.  We’re pulling data about products, so we did a quick database call to get unique names (there are lots of duplicates) and then format this up as a nice flat array:

SELECT distinct (name), id FROM [tablename] group by name order by name

We threw this to an array called $names.

The FBML selector…

Is actually really simple, despite what the documents might make you think. Note the <fb:fbml tag which you have to include (and specify this version) or it doesn’t seem to work.

I take the $names array and iterate through adding an option for each product like so…

<form action=”path/to/handler” method=”post”>

<fb:fbml version=”1.1″>

<fb:typeahead-input name=”name” autocomplete=”off” size=”50″>

<?php foreach ($names as $item){?>

<fb:typeahead-option value=”<?php echo $item['id'];?>”><?php echo $item['name'];?></fb:typeahead-option>

<?php } ?>

</fb:typeahead-input>

</fb:fbml>

And FB will take care of turning the FBML into HTML and JavaScripting it up nicely.

The backend handler…

Should be really simple, but there are a few edge cases, namely what you do when somebody managed to fill in your lovely autosuggestor with something new (who would do such a thing?).

Because we’re passing a number (the id) as the value, if what it is passed is not a number, we know that it wasn’t an option, and then we can do something with the input they did enter.  Here’s our actual code (minus a few secrets):

function addbymagicsuggest()
{
$id = $this->input->post(‘name_val’);
$name = $this->input->post(‘name’);
if(is_numeric($id)){
// they submitted something we know about
echo “thanks for submitted item”.$id;
}else{
//handle the new item
echo “you submitted”.$name;
}
}

And amazingly thats it – you’d never believe it was that simple from the docs, but it really is.  Here’s a picture in action to prove it.

So, after being here at wishlil.st for a little over a month, I thought it was time to get some of the little things we’ve done out into the world, and maybe help a few other people.  Developing Facebook applications has it’s own interesting infrastructure problems, and whilst we’ve not solved everything (there’s no equivalent of using a local MAMP install as I would for website development for example) we have solved a few things.

Using a code framework

We’ve ported all of our facebook app across to run on top of the amazing CodeIgniter.  As a PHP house it was all to easy to hack about in our own handrolled structure, but there comes a time to bite the bullet and use an MVC structure.  We chose CI because I had worked with it in the past, and loved the way it didn’t get under your feet.   It’s lightweight, and nicely flexible, but comes with lots of freebies for developers.

Getting CI to play nicely with FB will get a separate post later (you have to set lots of config right to stop FB killing your app with it’s crazy request strings) but the library from Elliot Haughin was a good starting point.  We’ve hacked it about a little and replaced it’s core FB wrapper with the latest one, but it got us off the ground.

Version management

We started with a Subversion repository on Beanstalkapp.com running a trunk for live, and a branch for development work.  Once we got Coda integrated with SVN and SFTP (you have to edit on a “live” server to develop FB apps) it was all running pretty smoothly.  I build a couple of deployment scripts, and all ways well until we had to merge the dev branch back into live, and then the version management hell started.  Merging is hard, should be hard, and will always be hard, but it shouldn’t be this hard.  We bit another bullet, and moved to Mercurial.

We’d heard a lot about it over the last few months and it was a quote from Joel Spolsky that encouraged us to go for it…

Or, to put it another way, I’d go back to C++ before I gave up on Mercurial. -Joel Spolsky

In the end it wasn’t that hard.  We’ve taken up a hosted Mercurial account with Kiln to get started (I’ll in-house this at some point) with a single repository for live.  We’ve branched this for dev.

Importing SVN to Mercurial turned out to be reasonably easy.  You create your local clone of the live repository (which is empty), run an “svn export” to flatten you SVN trunk of it’s history, and then “hg add” “hg commit” and “hg push”.  Job done.  The HGInit guide is a good starting place too.

So now we bug fix live on the equivalent of trunk, and “push” branches back up to the trunk when we’re ready to go live.  Command line all the way, but that’s just how we roll.

Deployment scripts

One of the big lessons I learned, and Flickr’s notes re-enforced as the need for easy deployment.  Gone are the days of me spending 3 days deploying code into a live environment, living on coffee and Haribo for a week and risking it all.

You really must be able to deploy the majority of your environment from a single script, and thus a single mouse click.

At the moment we do it in the easiest dirtiest way possible, we “hg clone” the repository into a fresh directory, and then symlink to it from the Apache document root.  You don’t even need to restart Apache (but it’s a good idea).  It’s a single command (./push_live.sh) and takes about 30 seconds.

A dose of monitoring

Having an idea of what is trending on your server is really really important.  I love Munin for it’s chronological view of the world, letter you see what has happened in the short term (why have we got 4 gigs more memory committed that 2 minutes ago) and whats going on over a more meaningful time frame (oh – we do this everyday about the same time – might be connected to a scheduled process).  Munin lets you be proactive, spotting things that are creaping up over time.  It’s also handy during a crisis.

Oh man - what's going on?

Oh no, it's ok.

Munin is a good partner to Nagios.  I’ve not got Nagios up and installed yet.  Munin lets you stop things going wrong, Nagios will tell when they have (and it’s a amazing how often you don’t know).

Development scripts

There are lots of things you end up doing during dev which can really benefit from a drop of scripting.  One we run several times a day on our personal instances, and every night on a schedule, is cloning our live database across to the development instances.  It’s not hard, in fact it’s a one liner really.  We run mysqldump to drop the database out to sql files, and then mysql < dumpfile.sql to import it into the dev databases. Call it and you can have a fresh new cut of live with all the crazy data people have sneaked past the filtering for you to play with.

Backups

Backing up is a pain in the neck, but so import it’s unreal.  Eventually I’d like to get to a point where we can deploy everything including server config form a central point, but until then we backup two things, the code and the data.

Database backups are a simple matter of mysqldump being run, and a little bit of tar, gzip and scp to bundle them up with the date and move them off site.  We keep an on site copy too for fast access though.

The live code is backed up using rsync to a mount point that is mounted before the rsync and unmounted afterwards (no accidental rm -rf).  Getting it to work well was a bit of a nightmare, and we only had FTP access to the backup space, but curlftpfs came to the rescue letting us mount a remote ftp connection as a local mount.

A bunch of silly things that save you time

If you find yourself doing the save thing ten times a day, stop it, and script it.  You remove the chances of you screwing it up because you’re tired.  Here’s a handy guide to get you started, and do remember to make yours scripts check their input before they run, kickout if something goes wrong, and log (so you can tell what went wrong)

Set yourself up  SSH keys between your trusted boxes and laptops.  Mistyping a password at 1am is frustrating, and sorting your passwords in a text file is worse.  It’s not hard , though it does vary between install types but Bush Cures Cancer had a great guide.

We’ll write up some more detailed insights into some fo the stuff we’re doing with time, but if you’re stuck, drop us a line.

As we wrote this post we noticed a few key factors including: thought, effort and money. The more thought you put into choosing a present (or effort put into making/finding one) the better. In many cases the more money spent the better too. However thought and effort will always trump money spent. Grandparents, for example, always appreciate home-made gifts and care little for how much has been spent.

1. The “Halcyon” Gift

Right at the top of the tree is gift giving nirvana: the perfect gift that you didn’t know you needed. A thoughtful and inspired choice that was appropriately priced. The halcyon gift is usually something you can use and appreciate time many times over. Perfect timing can also make a good present great – giving a gift when someone really needs a pick-me-up counts for a lot.

Examples include: a more expensive laptop or gadget (we’re thinking Macbook Air and iPod touch) than you would ever buy for yourself, a Mr Frosty ice lolly maker that your kid can use all summer long to make delicious lollies, or even a delicious homemade cake!

2. The “Decent” Gift

A perfectly good gift that you will use and enjoy counts as a “Decent” gift. It misses the level of inspiration required to make it a “Halcyon” gift. It can also sometimes be a carefully chosen “Generic” gift. Most good presents fit in this category.

Examples include: the Slanket, most books, DVDs and computer games.

3. The “Asked For” Gift

The easiest way to get what you want is to ask for it. Of course, your requests have to be reasonable and presented in a friendly way. This type of gift lacks the suprise element required to reach higher levels but, despite that, it beats all of the lower levels!

Examples include: gifts bought from a wishlist.

4. The “Duplicate Decent” Gift

The “Duplicate Decent” gift is a frustrating one. It is a well thought through present but you already have one and enjoy it! Clearly a good choice by the buyer but completely useless to the recipient. Half marks for effort.

Examples include: your second Slanket.

5. The “Generic” Gift

The result of a last minute panic the “Generic” gift is an uninspiring item that rouses little emotion in the recipient.

Examples include: Jeremy Clarkson books, socks, novelty gifts.

NB. Many “Generic” gifts are perceived as much better by the buyer than the recipient. For example: stars, lordships and Oxfam goats.

6. The “Duplicate Generic” Gift

One worse than a “Generic” gift is a generic gift that you have already been given! How many socks, stars and lordships does a person really need!?

7. The “Awkwardly Wrong” Gift

This is without doubt the worst kind of gift. Imagine your grandmother spends an hour driving to the shops and after trawling round HMV and comes out with an Eminem box-set. The wasted time, effort and money make it a painful and embarrassing gift. One giveaway of an “Awkwardly Wrong” gift is that it’s virtually impossible to write a nice thank you letter without lying.

Examples include: a camel-skin bag from your mother-in-law or anything you just can’t stand whatsoever.

We think every gift ever bought fits into one of these categories (or did we miss a category?). It also seems that the higher up the scale you can get the better. We’re going to keep this in mind as we build wishli.st!

If you have two minutes – we’d love to hear the best and worst presents you’ve ever received!

It was great to see some familiar faces (Di, Lee, Jonny and Team Presence) as well as to put some faces to Twitter handles (Kat and Jim of Sonodrome)! Our genial MC for the night was Paul Smith also known as the world-famous twitchhiker. The highlight of the night was definitely the raffle. Our Oli gave himself away to cook a meal for a lucky winner in their own home. Ross Cooney scooped this special treat! And Oli went on to win a massive bag of goodies from the Baltic courtesy of David Coxon!

All in all a great night in Newcastle with a really friendly crowd and lots of money raised for Concern. Well done to organiser Aoife and team!

PS. Apologies to any unfortunate victims of our enthusiastic cupcake sales campaign!

Also, with the group features on sites like Facebook and LinkedIn, you can test whether there is any demand for your idea for free!

I wrote a column in the Journal recently explaining how to get started. Check it out: Start your own social network site.

Unfortunately I wasn’t selected as a finalist but we’ve got a few friends among the finalists so if you have a moment to email in your votes please consider the following:

Emma Reilly – iYosh
Mark Easby – Better Brand Agency
Rob Earnshaw – The Casting Website

Good luck guys!

Now we need your support again as we push for the next stage of the competition. If you could vote for us every day between now and midnight on the 30th November we’d be extremely grateful indeed!

Thanks to Counterknowledge.com for endorsing us and thanks to all of you for your continued support. It means a lot to us.