It has been a busy week!

We started the week with the ongoing push towards Elgg 1.1, including a number of bug fixes and some translations. The biggest change this week was to move sessions over to a database store – this provides more scalability options as well as making things more secure on shared hosts.

This week also saw the development of the first version of our commercial SMS server that provides both outbound and inbound SMS channels for Elgg installs to hook into. This included a sophisticated client side library which provides simple yet powerful tools for hooking into this feed – the proof of concept was to add SMS functionality to The Wire (so you can now post your Elgg community thoughts on the road!)

More on this to come…

On Thursday, me and Ben were helping out at the OFE stand at the London Linux Expo. We got to meet some very cool people and talk about open standards (such as OpenDD), introduce Elgg, and generally big up FOSS.

I had a good look around the show. The contrast with the Linux side and the Mac side in terms of style was striking.

It depressed me somewhat that the Open Source Village (with a few exceptions like Open Street Map) was pretty much a lesson in what not to do.

It was good to see the projects there, and its great they were given this space. But most people there seemed to be more interested in staring intently at their laptops rather than talking to people or interacting with the other projects.

Contrast this with projects like Ubuntu which had people giving keynotes and wandering around chatting to people.

No prizes to see who is more likely to still be around in a years time…

But, on a positive note, while I was there I discovered that GoDaddy (one of the largest hosts and domain name resellers in the world) are now offering Elgg hosting and support!

And finally, after spending the day working on a commercial build, I spent 15 minutes building a small plugin which enables The Wire to push messages to Twitter. It is now possible to send an SMS to your wire and then out to your twitter – all through some loosely coupled drop-in plugins.

Cool eh?

Following on from my previous post about doing things the Elgg way, I thought I’d illustrate some of what I was talking about by building out a quick plugin while the kettle boiled for my tea.

This plugin uses the hooks present in Elgg – specifically the getIcon() api – to provide Gravatar icons for users which have not provided their own.

On many platforms this might have been an onerous task, but on Elgg it literally took me 15 minutes (in fact, it took me longer to write this post than the plugin).

If a user defines their own icon it will use that, but if they haven’t provided one it will use their email address to find their gravatar icon.

This is accomplished by setting the priority of the hook somewhere after the icon handler provided by the profile plugin, and before the default icon handler.

Anyway, here is the code:

<?php
/**
* Simple gravatar integration for Elgg.
* Scratching an itch! (+ a good example of icon overloading)
*
* TODO:
* 1) Fallback to elgg default icons instead of gravatar one for missing images
* 2) Have sizes better handle changes in defaults for theming
*
* @package ElggGravatar
* @license http://www.gnu.org/licenses/old-licenses/gpl-2.0.html GNU Public License version 2
* @author Curverider Ltd
* @copyright Curverider Ltd 2008
* @link http://elgg.com/
*/

/**
* Init.
*
*/
function gravatar_init()
{
// Now override icons. Note priority: This sits somewhere between the profile user icons and default icons -
// so if you specify an icon for a user it will use that, else it will try a gravatar icon.
register_plugin_hook('entity:icon:url', 'user', 'gravatar_usericon_hook', 900);
}

/**
* This hooks into the getIcon API and returns a gravatar icon where possible
*
* @param unknown_type $hook
* @param unknown_type $entity_type
* @param unknown_type $returnvalue
* @param unknown_type $params
* @return unknown
*/
function gravatar_usericon_hook($hook, $entity_type, $returnvalue, $params)
{
global $CONFIG;

// Size lookup. TODO: Do this better to allow for changed themes.
$size_lookup = array(
'master' => '200',
'large' => '200',
'topbar' => '16',
'tiny' => '25',
'small' => '40',
'medium' => '100'
);

if ((!$returnvalue) && ($hook == 'entity:icon:url') && ($params['entity'] instanceof ElggUser))
{
$size = 40;
if (isset($size_lookup[$params['size']]))
$size = $size_lookup[$params['size']];

return "http://www.gravatar.com/avatar/".md5($params['entity']->email) . ".jpg?s=$size";
}
}

// Initialise plugin
register_elgg_event_handler('init','system','gravatar_init');
?>

Pretty simple.

It has been a busy few weeks. Those of you who have been following the cut and thrust of development and tracking SVN will have noticed a fair few extra features and functionality and a lot of core code changes – extra tools, new activity viewing code, many speed improvements, a central entity icon API, bug fixes etc.

A lot of people have been picking up the code and contributing. The Community site we launched earlier this month seems to have been a big hit with people and we are seeing some really quite useful stuff fall out of the mix.

As we approach the release of Elgg 1.1 I thought it would be a good time to talk a little bit about what I call “doing things the Elgg way”.

Elgg is built to be modular and pluggable, so this means always thinking about how you can let others safely hook in and extend the way your code works.

We make extensive use of the events system, so for example when an entity is created or updated it triggers an event. Other bits of code can chose to listen to this event and do something.

This is for example how logging works.

The Elgg system log simply listens to events in the system, and when an event is triggered on an object which can be logged it writes the appropriate entry in the system log.

This can be then further processed by the River or Activity viewer, which brings us rather nicely into the subject of views (which we have talked a bit about before).

The activity stream and the river both work off the system log and use the views system. What happens is that when either of these is displayed the code looks to see if it has a view to render a given item in the log, and if so it renders the event.

This is very flexible, since it means that any plugin can come along and add and extend the river or activity stream – adding custom views for its own entities or extending other entities – all of which without touching a single line of core code.

This is a pretty big win, and this is part of what it means to develop the Elgg way.