It is currently in Beta and the code could do with a bit of a tidy, but this is Open Source so roll up your sleeves and get involved.

What is it?
Multisite Elgg allows you to run multiple separate Elgg sites off of the same install of the codebase, saving disk space and making administration a whole bunch easier.

Currently based around the latest Elgg 1.7 release, once installed adding new Elgg sites is a matter of clicking on a button and entering in some details.

What can I do with it?
You can do everything that you can do with Elgg, but with the ability to create new networks on demand. This will for example let you:

• Set up your own version of Ning! What with Ning phasing out free accounts, it is my hope that Multisite Elgg will let a thousand more Nings bloom!
• In your organisation or institution, easily set up Elgg sites for each department.
• If your one of the Elgg hosting companies out there, you may want to look at multisite in order to simplify your work flow.
• … etc…

Installation
Once you have downloaded the installation package you will need to do a few things in order to get up and running. Multisite Elgg assumes that you have some knowledge of how to set up and run a server – there is no wizard just yet!

1. Unzip the package on your web server.
2. Point your master domain at the contents of the install location on your web server. This is your master control domain, go here to configure your sites. Because of this you might want to consider putting this behind some further access restrictions.
3. Point any sub domains to the contents of the docroot folder, eg (/var/multisite/docroot). This directory forms the base of all your Elgg installs. To make things even more automated you may want to consider making this an Apache wildcard domain, if your DNS provider supports it.
4. Chmod 777 docroot/data: This is the default location for multisite domains.
5. Install schema/multisite_mysql.sql: Create a new database on your Mysql server and install the Multisite schema – this is your master control database.
6. Rename settings.example.php in docroot/elgg/engine/ to settings.php and configure:
   

   $CONFIG->multisite->dbuser = ‘your username’;
   $CONFIG->multisite->dbpass = ‘password’;
   $CONFIG->multisite->dbhost = ‘host’;

   Make sure this user has sufficient privileges to create and grant access to databases and tables on your server. This will allow the admin tool to create the databases for your hosted sites automatically.

7. Visit your master domain and configure your admin user
8. Begin configuring your sites!

Creating sites
Once you have created an admin user, adding sites is easy. Currently you can only create one type of site, but in the future Multisite Elgg will let you create sites which have quotas and other access restrictions.

You have a box to enter database details, or you can leave them blank to use Multisite Elgg user defined above (which you may not want to do for security reasons).

You can also select which of the installed plugins you want to allow, this lets have different sites have different plugins available while still installing them on the same codebase.

Contributing
So, that was a brief introduction to Multisite Elgg. I hope that at least some of you out there find it useful!

As I said before, it’s Open Source, so if you want to get involved here are the important details:

• Project homepage: http://code.google.com/p/mp-multisite-elgg
• Bug Tracker: http://code.google.com/p/mp-multisite-elgg/issues/list
• Code Repository: svn checkout http://mp-multisite-elgg.googlecode.com/svn/trunk/ mp-multisite-elgg-read-only
• Discussion forum: http://groups.google.com/group/mp-multisite-elgg
• Direct download!

If you want to contribute patches, feel free to use the bug tracker or discussion forum!

Enjoy!

I have just written a very small Akismet plugin for Elgg.

When enabled and configured, this plugin will scan newly submitted comments of the ‘generic_comment’ annotation class.

While spam comments are rarer on Elgg due to the fact that most sites don’t allow anonymous comments, this could be useful for people who are getting spam comments from people who have signed up.

This plugin comes into its own when you allow anonymous comments, such as on a site I recently built for a client.

Extending this plugin to scan other content should be fairly straight forward for even a novice coder, but if I have time I’ll provide an interface to do so.

Anyway, go get it here, or check out the project page on google code!

Image “Spam! [don't buy]” by David Trattnig

In this article I will document the process, but first I should point out:

• This is highly experimental and not endorsed in any way.
• It is built against Elgg 1.6.1
• This is not canonical and doesn’t reflect anything to do with the roadmap
• This has not been extensively tested so caveat emptor.

Setting up the cluster

The first step is to set up the cluster on your equipment.

A MySQL cluster consists of a management node and several data nodes connected together by a network. Because I was running rather low on hardware, I cheated here and created each node as a Virtual Box image on my laptop – but the principle is the same.

Each node is an Ubuntu install (although you can use pretty much any OS) with two (virtual) network cards, one connected to the wider network (to install packages) and another on an internal network. If you do this for real you should consider removing the internet facing card once you’ve set everything up since a cluster isn’t secure enough to be run on the wider internet.

In my test configuration I had three nodes with name/internal IP as follows:

• HHCluster1/192.168.2.1 – Management node & web server
• HHCluster2/192.168.2.2 – First data node
• HHCluster3/192.168.2.3 – Second data node

HHCluster1 – The management node

Install mysql, apache etc. This should be a simple matter of apt-getting the relevant packages. Clustering (ndb) support is built into the version of mysql bundled with Ubuntu, but this may not be the case universally so check!

You need to create a file in /etc/mysql/ called ndb_mgmd.cnf, this should contain the following:


[NDBD DEFAULT]
NoOfReplicas=2 # How many nodes you have
DataMemory=80M # How much memory to allocate for data storage (change for larger clusters)
IndexMemory=18M # How much memory to allocate for index storage (change for larger clusters)
[MYSQLD DEFAULT]
[NDB_MGMD DEFAULT]
[TCP DEFAULT]

[NDB_MGMD]
HostName=192.168.2.1 # IP address of this system

# Now we describe each node on the system

# First data node
HostName=192.168.2.2
DataDir=/var/lib/mysql-cluster
BackupDataDir=/var/lib/mysql-cluster/backup
DataMemory=512M
[NDBD]
# Second data node node
HostName=192.168.2.3
DataDir=/var/lib/mysql-cluster
BackupDataDir=/var/lib/mysql-cluster/backup
DataMemory=512M


#one [MYSQLD] per data storage node
[MYSQLD]
[MYSQLD]

Data nodes (HHCluster2 & 3)
You must now configure your data nodes:

1. Create the data directories, as root type:
   

   mkdir -p /var/lib/mysql-cluster/backup
chown -R mysql:mysql /var/lib/mysql-cluster

2. Edit your /etc/mysql/my.cnf and add the following to the [mysqld] section:
   

   ndbcluster
# Replace the following with the IP address of your management server
ndb-connectstring=192.168.2.1

3. Again in /etc/mysql/my.cnf uncomment and edit the [MYSQL_CLUSTER] section so it contains the location of your management server:
   

   [MYSQL_CLUSTER]
ndb-connectstring=192.168.2.1

4. You need to create your database on each node (this is because clustering operates on a table level rather than a database level):
   

   CREATE DATABASE elggcluster;

Starting the cluster

1. Start the management node:
   

   /etc/init.d/mysql-ndb-mgm start

2. Start your data nodes:
   

   /etc/init.d/mysql restart
/etc/init.d/mysql-ndb restart

Verifying the cluster
You should now have the cluster up and running, you can verify this by logging into your management node and typing show in ndb_mgm.

A word on access…

The cluster is now set up and will replicate tables (created with the ndbcluster engine – more on that later), but that is only useful to a point. Right now we don’t have a single endpoint to direct queries to, so this direction needs to be done at the application level.

We could take advantage of Elgg’s built in split read and writes, but this would only allow us to use a maximum of two nodes. A better solution would be to use a load balancer here such as Ultramonkey to direct the query to the appropriate server allowing us to scale much further.

I didn’t really have time to get into this, so I am using the somewhat simpler mysql-proxy.

1. On HHCluster1 install and run mysql-proxy:
   

   apt-get install mysql-proxy
mysql-proxy --proxy-backend-addresses=192.168.2.2:3306 --proxy-backend-addresses=192.168.2.2:3306

2. On your data nodes edit your /etc/mysql/my.cnf file. Find bind-address and change it’s IP to the node’s IP address. Also ensure that you have commented out any occurrence of skip-networking.
3. Again on your client nodes, log in to mysql and grant access to your cluster table to a user on HHCluster1 – for example:
   

   GRANT ALL ON elggcluster.* TO `root`@`HHCluster1.local` IDENTIFIED BY '[some password]'

Installing elgg

Unfortunately as it stands, you need to make some code changes to the vanilla version of Elgg in order for it to work in a clustered environment. These changes are necessary because of the restrictions placed on us by the ndbcluster engine.

Two things in particular cause us problems – ndbcluster doesn’t support FULLTEXT indexes, and it also doesn’t support indexes over TEXT or BLOB fields.

FULLTEXT is for searching and is largely not used in the vanilla install of elgg, so I removed them. Equally, most indexes blobs one can live without, the exception being on the metastrings table.

Metastrings is accessed a lot, so the index is critical. Therefore I added an extra varchar field which we’ll modify the code to include the first 50 characters of the indexed text – this is equivalent to the existing index:

CREATE TABLE `prefix_metastrings` (
`id` int(11) NOT NULL auto_increment,
`string` TEXT NOT NULL,
`string_index` varchar(50) NOT NULL,
PRIMARY KEY (`id`),
KEY `string_index` (`string_index`)
) ENGINE=ndbcluster DEFAULT CHARSET=utf8;

And the modified query:

$row = get_data_row("SELECT * from {$CONFIG->dbprefix}metastrings where string=$cs'$string' and string_index='$string_index' limit 1");

Mysql’s optimiser checks the index first so this doesn’t lose a significant amount of efficiency (at least according to the explain command).

» Modified schema

The next problem is that the system log currently uses INSERT DELAYED to insert the log data. This is also not supported under the clustered engine.

There are a number of approaches we could take including using Elgg’s delayed write functionality or writing a plugin which replaces and logs to a different location.

For the purposes of this test I decided to just comment out the code in system_log().

What won’t work
Currently there are a couple of core things that won’t work under these changes, here is a by no means complete summary:

• The system log (as previously described). This isn’t too much of a show stopper as the river code introduced in Elgg 1.5 no longer uses this.
• The log rotate plugin as this attempts to copy the table into the archive engine type and we can’t guarantee which node it will be executed on in this scenario.
• Any third party plugins which attempt to access the metastrings table directly (of which there should be none as direct table access is a big no no!)

Anyway, here is a patch I made against the released version of 1.6.1 with all the code changes I made. Once you have applied this patch to your Elgg install you should be able to proceed with the normal Elgg install.

Let me know any feedback you may have!

» Elgg Clustering patch for Elgg 1.6.1

Top image “Birds-eye view of the 10,240-processor SGI Altix supercomputer housed at the NASA Advanced Supercomputing facility.”

Although I am drawing your attention to it now, it should be noted that this is still somewhat under development!

Anatomy of a geocoder

To begin geocoding your data you will need a geocoder. This is not something that Elgg comes installed with by default, although here’s one I coded earlier.

This geocoder users the Google maps API to do the actual encoding, and provides two primary features.

• It handles the plugin hook “geocode”,”location”
• It listens to all create events and attempts to tag it with the latitude and longitude – either from a ->location metadata on the object itself, or from the user’s current ->location – you could get more creative, this is a simple example.

When you attempt to geocode a location you call the function elgg_geocode_location(). This in turn triggers the above plugin hook and attempts to encode the data.

For efficiency once a location has been geocoded the result is cached. Future attempts to code the same location will return the result from the cache.

Once installed and configured, new content (wire posts etc) will be tagged with a latitude and longitude. Fill in your profile location field and try it out for yourself!

Location based searches

Once things are tagged with a location, you can start to use location as a starting point for searching by using some of the location aware search functions in location.php.

This hasn’t currently been hooked up to the Elgg interface in any way, but that doesn’t stop you making use of it in your plugins.

GeoRSS

This is something you’ll be pleased to know that you get for free!

As you list your entities using the Elgg listing tools using the RSS view, if an entity has a position defined it will be included using standard geoRSS simple notation, i.e:

<georss:point> 45.256 -71.92 </georss:point>

Happy coding!

This gives you the opportunity to develop interoperable web services and provide them to the users of your site, all in a standardised way.

The endpoint

To make an API call you must direct your query at a special URL. This query will be either a GET or a POST query (depending on the command you are executing), the specific endpoint you use depends on the format you want the return value returned in.

The endpoint:

http://yoursite.com/pg/api/[protocol]/[return format]/

Where:

• [protocol] is the protocol being used, in this case and for the moment only “rest” is supported.
• [return format] is the format you want your information returned in, either “php”, “json” or “xml”.

This endpoint should then be passed the method and any parameters as GET variables, so for example:

http://yoursite.com/pg/api/rest/xml/?method=test.test&myparam=foo&anotherparam=bar

Would pass “foo” and “bar” as the given named parameters to the function “test.test” and return the result in XML format.

Notice here also that the API uses the “PG” page handler extension, this means that it would be a relatively simple matter to add a new API protocol or replace the entire API subsystem in a module – should you be so inclined.

Return result

The result of the api call will be an entity encoded in your chosen format.

This entity will have a “status” parameter – zero for success, non-zero denotes an error. Result data will be in the “result” parameter. You may also receive some messages and debug information.

Exporting a function

Any Elgg function – core or module – can be exposed via the API, all you have to do is declare it using expose_function() from within your code, passing the method name, handler and any parameters (note that these parameters must be declared in the same order as they appear in your function).

Listing functions

You can see a list of all registered functions using the built in api command “system.api.list”, this is also a useful test to see if your client is configured correctly.

E.g.

http://yoursite.com/pg/api/rest/xml/?method=system.api.list

Authorising and authenticating

Most commands will require some form of authorisation in order to function. There are two main types of authorisation – protocol level which determines whether a given client is permitted to connect, and user level where a command whereby a user requires a special token in lieu of a username and password.

Protocol level authentication
Protocol level authentication is a way to ensure that commands only come from approved clients for which you have previously given keys. This is in keeping with many web based API systems and permits you to disconnect clients who abuse your system, or track usage for accountancy purposes.

The client must send a HMAC signature together with a set of special HTTP headers when making a call. This ensures that the API call is being made from the stated client and that the data has not been tampered with.

Eagle-eyed readers with long memories will see a lot of similarity with the ElggVoices API I wrote about previously.

The HMAC must be constructed over the following data:

• The Secret Key provided by the target Elgg install (as provided easily by the APIAdmin plugin).
• The current unix time in microseconds as a floating point decimal, produced my microtime(true).
• Your API key identifying you to the Elgg api server (companion to your secret key).
• URLEncoded string representation of any GET variable parameters, eg “method=test.test&foo=bar”
• If you are sending post data, the hash of this data.

Some extra information must be added to the HTTP header in order for this data to be correctly processed:

• X-Elgg-apikey – The API key (not the secret key!)
• X-Elgg-time – Microtime used in the HMAC calculation
• X-Elgg-hmac – The HMAC as hex characters.
• X-Elgg-hmac-algo – The algorithm used in the HMAC calculation – eg, sha1, md5 etc

If you are sending POST data you must also send:

• X-Elgg-posthash – The hash of the POST data.
• X-Elgg-posthash-algo – The algorithm used to produce the POST data hash – eg, md5.
• Content-type – The content type of the data you are sending (if in doubt use application/octet-stream).
• Content-Length – The length in bytes of your POST data.

Much of this will be handled for you if you use the built in Elgg API Client.

User level tokens

User level tokens are used to identify a specific user on the target system, in much the same way as if they were to log in with their user name and password, but without the need to send this for every API call.

Tokens are time limited, and so it will be necessary for your client to periodically refresh the token they use to identify the user.

Tokens are generated by using the API command “auth.gettoken” and passing the username and password as parameters, eg:

http://yoursite.com/pg/api/rest/xml/?method=auth.gettoken&username=foo&password=bar

Anonymous methods
Anonymous methods (such as “system.api.list”) can be executed without any form of authentication, thus accepting connections from any client and regardless of whether they provide a user token. This is useful in certain situations and it goes without saying that you don’t expose sensitive functionality this way.

To do so set $anonymous=true in your call to expose_function().

Image “In UR Reality” by XKCD

In a nutshell this interface provides an export view for Entities, Metadata, Annotations and relationships which can provide a convenient way of accessing data objects in a machine readable form.

Endpoints

The export url is constructed in different ways for entities, relationships and metadata.

All endpoints begin with:

http://yoursite.com/export/[VIEW]/

Where [VIEW] is the format you want the data exported in – e.g. json, opendd, php or default.

Entities
To export a GUID simply add it to the end:

http://yoursite.com/export/[VIEW]/[GUID]/

Annotations & Metadata

Metadata and annotation can be exported by providing the type (‘annotation’ or ‘metadata’) and the appropriate ID.

http://yoursite.com/export/[VIEW]/[GUID]/[annotation|metadata]/[annotation_id|metadata_id]/

Relationships
Follows the same format as above, but with [GUID] being the first guid in the relationship – in essence the entity to which the relationship “belongs”.

http://yoursite.com/export/[VIEW]/[GUID]/relationship/[relationship_id]/

Security

Some items of data (for example user passwords) are restricted from this export view. Exactly what is output by an output view is governed by $object->getExportableValues(); which returns a list of exportable fields in the entity.

In addition, access permissions on the object are respected – meaning that if you can’t see an item in Elgg, you will not be able to see it in the export view either.

Most Elgg programmers are by now familiar with extending or replacing existing views, or providing new views for new objects etc.

But what if you just wanted to make a simple tweak to an existing view – for example to replace all instances of rude words in a feed article, or to turn passive links into active ones?

Well, fortunately Elgg provides a post processing hook for views which can do just that.

After every view has been generated, the framework will trigger a plugin hook called “‘display’, ‘view’”. This hook is passed a parameter ‘view’ which contains the name of the view being processed (eg. object/blog).

The contents of the view are passed in the $returnvalue variable which you can perform any processing on before returning it from the hook.

I have just uploaded a Trac tags plugin to the Elgg community site which provides a good example of this.

The Trac tags plugin is a tiny plugin which uses the views post processing hook to turn Trac links (e.g. #xxxxx for tickets and [xxxxx] for changesets) into active links into your repository, and here’s how – first we register the hook:

function tractags_init()
{
....
// Register our post processing hook
register_plugin_hook('display', 'view', 'tractags_rewrite');


// define views we want to rewrite codes on (means we don't have to process *everything*)
$CONFIG->tractags_views = array(
'object/thewire',
'object/blog'
);

....
}

Then in our handler looks something like this:

function tractags_rewrite($hook, $entity_type, $returnvalue, $params)
{
global $CONFIG;

$view = $params['view'];

if (($view) && (in_array($view, $CONFIG->tractags_views)))
{
// Search and replace ticket numbers
$returnvalue = preg_replace_callback('/(#)([0-9]+)/i',
create_function(
'$matches',
'
global $CONFIG;

return "<a href=\"{$CONFIG->trac_baseurl}ticket/{$matches[2]}\">{$matches[0]}</a>";
'
), $returnvalue);

// Search and replace changesets
$returnvalue = preg_replace_callback('/(\[)([0-9]+)(\])/i',
create_function(
'$matches',
'
global $CONFIG;

return "<a href=\"{$CONFIG->trac_baseurl}changeset/{$matches[2]}\">{$matches[0]}</a>";
'
), $returnvalue);

return $returnvalue;
}
}

I’m sure you will be able to come up with some much more interesting uses!

Image from the Trac project.

A good example of where this has been done is the newly introduced Captcha functionality available in the latest nightly testing builds of Elgg.

The Captcha functionality is provided by a module which extends a view called “input/captcha“. This view is blank by default but is used in several places such as user registration and the lost password form.

This means two things; firstly that if a Captcha module isn’t installed or enabled then forms behave normally, and secondly it becomes a trivial matter for third party modules to provide their own Captcha functionality.

This same mechanism is how the URL shortener module works by the way.

Next, the Captcha module extends a number of actions to require a correctly validated Captcha code. This list itself is the product of a plugin hook which returns an array of actions which require Captcha validation:

$actions = array();
$actions = trigger_plugin_hook('actionlist', 'captcha', null, $actions);

...

function captcha_actionlist_hook($hook, $entity_type, $returnvalue, $params)
{
if (!is_array($returnvalue))
$returnvalue = array();

$returnvalue[] = 'register';
$returnvalue[] = 'user/requestnewpassword';

return $returnvalue;
}

The reason why the list of actions is provided this way is twofold, firstly it lets modules use Captcha functionality in their own code through a generic interface, and secondly it is harder to spoof than looking for some marker in the form code.

The Captcha itself injects a server generated token into the form, which together with the user’s response to the characters generated in an image are used to validate that the user is indeed human.

As we can see, Elgg asks to be provided with a Captcha if one is available by including a specific view, but is agnostic as to where (or indeed if) this functionality is supplied.

By using the techniques available to an Elgg programmer I was able to loosely couple the Captcha system to Elgg in such a way that a third party can easily use the same techniques to provide a more advanced module.

Happy coding!

Image “A new Captcha approach” by XKCD

I just thought I’d write a quick post about it as this module makes use of a bit of Elgg functionality which has been around for a while, but that I know a number of plugin developers have missed.

Namely, the ability to extend actions.

When the Elgg framework calls an action the Action handler triggers a plugin hook called “action” before executing the action itself. This hook looks like this:

$event_result = true;
$event_result = trigger_plugin_hook('action', $action, null, $event_result);

Where $action is the action being called. If the hook returns false then the main action will not be executed.

The captcha module uses this to intercept the register and user/requestnewpassword actions and redirect them to a function which checks the captcha code. This check returns true if valid or false if not (which prevents the associated action from executing).

This is done as follows:

register_plugin_hook("action", "register", "captcha_verify_action_hook");
register_plugin_hook("action", "user/requestnewpassword", "captcha_verify_action_hook");

.
.
.

function captcha_verify_action_hook($hook, $entity_type, $returnvalue, $params)
{
$token = get_input('captcha_token');
$input = get_input('captcha_input');

if (($token) && (captcha_verify_captcha($input, $token)))
return true;

register_error(elgg_echo('captcha:captchafail'));

return false;
}


As you can see, this lets a plugin extend an existing action without the need to replace the action itself. In the case of the captcha plugin it allows the plugin to provide captcha support in a very loosely coupled way.

Happy coding!

“I am creating an Elgg network and I am expecting 10 million users, can it cope?”

This question gets asked in one form or another almos tevery week, but I believe this is the wrong question to be asking. Perhaps the more pertinent scalability question is:

“I am creating an Elgg network, how do I attract 10 million users?”

This is by far the hardest question to answer and it must be solved before you can seriously address the comparatively simple task of hardware and software scalability.

Attracting users can be accomplished in many ways but it is mainly a matter of marketing, and of course to have a killer idea. As Ben discussed in his presentation at the recent Elgg Conference, this idea must be as useful to user 1 as user 10 million.

The idea has to be solid from day one,  so forget all the trendy “long tail” and “wisdom of crowds” buzzwords!

Once you manage to solve this most tricky of problems, you can begin to look at the infrastructure. So, can Elgg handle 10 million users out of the box?

Simply, no script in the world can handle this level of usage straight away without some modification and a serious investment in both time and money. You will not be able to unpack Elgg on a cheap shared host and have it handle 10 million users.

This is not an issue with Elgg’s design (which actually lends itself to many scalability techniques), but simple realism. Elgg has had substantial work done on scalability and optimisation – reducing queries, caching etc – and currently performs very well page for page against competitors like Ning and Buddypress.

Asking how many users an Elgg install can support is also a pointless question, because the answer is always going to be “it depends”. How many users Elgg can support depends on your hardware, your host (shared or dedicated), your database server, how your users behave and how many of them are active at any given time.

So what should you pay attention to?

Elgg itself is fairly optimal, and will improve over time. If you are dealing with millions of user you will be wanting to look at your server infrastructure – database server, bandwidth, memory, caching at every level. After this you can look at customised code to squeeze out the last percentage points of performance.

If you are serious about handling high load there is no avoiding the need to spend some time and money investing in your infrastructure. But, these are good problems to have, because it means that you have a successful network!

So in conclusion, my answer to the scalability question is “Don’t worry about it until you have to worry about it!”, get your users in first. Make a killer service that is useful from day one, and then worry about how you will handle millions of concurrent users.

Scalability is a largely solved problem… building a successful service isn’t, and is the thing you should be concerned with.