The latest Elgg 1.0 code changes how the river works slightly from that discussed in my previous article on the subject. These changes are entirely under the hood so they’ll only be noticeable to plugin writers, however it simplifies matters immeasurably and makes it possible to do some quite funky things.

In a nutshell, the river generation function now passes a variable called "statement" to your river views instead of passing the object, event etc as separate values. "statement" is a class called ElggRiverStatement.

Loosely speaking all river items are in the form of “X does something to Y”, where X is usually a user and Y is either an entity or another statement. I borrowed a bit from linguistics, and X is called the Subject and Y is the Object.

Subject, as I said, is the user, so this is easy. The ElggRiverStatement will provide you with a fully created user entity.

The statement “does something to” translates to the event in the system which you will be used to if you’ve implemented plugins for Elgg 1.0 already… so that’s “create”, “update”, etc.

Object will either by an ElggEntity in the case of simple statements like “User X updated their Profile”, or an array which represents compound statements.

What do I mean by compound statements? Well, take the following for example:

“User X is now friends with User Y”

As far as the system is concerned, what you are actually saying is:

“User X created a new friend relationship between User X and User Y”

In terms of language, User X is the Subject and “a new friend relationship between User X and User Y” (yes, the whole thing) is the Object (and yes, before someone jumps in I am aware this is highly simplified!).

I use the terms Subject and Object again in the array, so to take the above example our array would look something like this:

Array (
    "subject" => User X (ElggUser object),
    "relationship" => "friend",
    "object" => User Y (ElggUser object again)
)

If you take the example of adding some metadata (writing a note on a file for example), you’ve got another compound query. You are making the statement:

“User X has created some metadata which relates to File Y”

In this instance “some metadata which relates to File Y” is our Object, and the array returned would look something like this:

Array (
    "subject" => Metadata object,
    "object" => File Y
)

In summary then, the ElggRiverStatement provides a pretty flexible way of representing diverse river statements with a common interface. The entities referenced are provided in full to your view so that you do not have to load them yourself.

Although this is a small change under the hood it makes it possible to do some other cool stuff (which I will discuss a little bit later).

Thanks for visiting! If you found this helpful, you might be interested in knowing that I offer development and consultancy services, and am available to hire!

It has been an exciting (not to mention very busy) few weeks, and we are now entering the final approach towards the release of Elgg 1.0.

We have had some very positive initial response from our beta tester group, and from the screenshots that Dave posted the other day.

Elgg 1.0 features some rather advanced features such as the much improved object model which I’ve blogged about before (also see Ben’s post) as well as native support for OpenDD.

A lot of work has been done to make development for the new platform a breeze; with a view system separating code and logic, widgets and streams virtually for free, and many more functions in core that take much of the strain.

As well as all the work done under the hood, Pete has done great work in making the new version graphically pleasing. There has been a big focus on the UI experience which everyone so far has said is a big improvement over Elgg Classic.

Watch this space for more!

Whew, well it’s been a monumentally busy development week on the new Elgg 1.0 codebase. The whole team has been working hard putting things together, and I’ve written so much cool stuff its hard to know where to begin.

Much of the really cool stuff I’ve been working on has been under the hood (XML-RPC, PAM, API etc), but I’ll start with giving a brief summary of what I was working on today – plugin administration.

As with Elgg Classic, Elgg 1 supports plugins modules. However, these modules can be turned on and off by the administrator (in much the same way as wordpress plugins can be). They can also have settings edited.

There are two things as a plugin writer to do to take full advantage of this:

Manifests

Manifests tell Elgg a little bit about your plugin. Your plugin will still work without them, but I highly recommend you use them.

Simply create a file called manifest.xml in your plugin’s top level directory that looks something like this:

<?xml version="1.0" encoding="UTF-8"?>
<plugin_manifest>
<field key="author" value="Marcus Povey" />
<field key="version" value="1.0" />
<field key="description" value="My first plugin!" />
<field key="website" value="http://www.marcus-povey.co.uk/" />
<field key="copyright" value="(C) MyCorp 2008" />
<field key="licence" value="GNU Public License version 2" />
</plugin_manifest>

Per-plugin settings

These let you provide some admin controlled configuration options for your plugin. Adding these is relatively simple.

  1. Create a file in your plugin’s view folder called settings/PLUGINNAME/edit.php, where PLUGINNAME is the name of your plugin’s directory in the mod hierarchy.
  2. Fill this file with the form elements you want to display together with internationalised text labels. Note: you don’t need to add a save button or the form, this will be handled by the framework.
  3. Set the name attribute in your form components to param[VARNAME] where VARNAME is the name of the variable. These will be saved as metadata attached to a plugin entity. So, if your variable is called param[myparameter] your entity (which is also passed to this view as $vars['entity']) will be called $vars['entity']->myparameter.

Here is an example of this view:

<p>
<?php echo elgg_echo('myplugin:settings:limit'); ?>

<select name="params[limit]">
<option value="5" <?php if ($vars['entity']->limit == 5) echo " selected=\"yes\" "; ?>>5</option>
<option value="8" <?php if ((!$vars['entity']->limit) || ($vars['entity']->limit == 8)) echo " selected=\"yes\" "; ?>>8</option>
<option value="12" <?php if ($vars['entity']->limit == 12) echo " selected=\"yes\" "; ?>>12</option>
<option value="15" <?php if ($vars['entity']->limit == 15) echo " selected=\"yes\" "; ?>>15</option>
</select>
</p>

Fun! fun!