Tag Archives: Elgg

Posted on
by

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.

Posted on
by

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.