Firstly, I would like to thank Brett Profitt, Elgg's recently appointed Lead Developer, for his outstanding work on the core engine: introducing coding standards, improving the core API and working closely with developers in the community. This has been the most successful release of Elgg ever in terms of community participation.

We took our time over v1.7 which was required to sort out a few long term core bugs and to rectify some architecture decisions taken early on in the project, which proved problematic. Now that we have reached this milestone, the most stable version of Elgg yet, attention is on the interface and end-user features.

Our aim over the next few months is to simplify Elgg's interface, make it standards compliant and improve the features we all use and expect on our Elgg networks. We want to make theming much easier and ensure the user experience is consistant as we know this is an area where Elgg needs to improve.

Interface work has already started and is being committed into SVN. Discussion has begun in the community and we welcome all thoughts/ideas/input:

Part one: http://community.elgg.org/mod/groups/topicposts.php?topic=397103&group_guid=212846
Part two:http://community.elgg.org/mod/groups/topicposts.php?topic=424690&group_guid=212846

The core and extensions Tracs have been consolidated into a single Trac installation, now located at http://trac.elgg.org/. Previous Trac tickets for extensions have been merged in and special rewrite rules will make sure that links to the old extensions trac tickets and changesets will keep pointing to the correct places.

The SVN repositories have also been merged and standardized into a branches, tags, and trunk layout. Also, bundled plugins are now included in the trunk/mods directory--No more cross-repository or svn externals work to have a full copy of Elgg in SVN!

For developers currently running trunk, though the URL looks the same, you must either check out a new version of trunk or svn switch to the new SVN repo. To switch, issue the following commands in your working copy:

svn switch --relocate http://code.elgg.org/elgg http://code.elgg.org/
svn switch http://code.elgg.org/elgg/trunk

If you have moved mods from the extensions repo into trunk/mods/, the above command will fail.

For those following us on github, the SVN->git mirroring is broken for the moment, but I will fix it as soon as I can.

For 1.7, the core team focused development on improving the core API, correcting long-standing bugs, and enhancing security. During the development of 1.7, we have had an unprecedented amount of community involvement in trac. In fact, over 250 issues were resolved in trac for this release!

Much of the development time was spent improving the core API to make Elgg a stable platform for development. As I have mentioned, this means that there are very few new features in Elgg 1.7--most of the improvements are behind the scenes and will be visible only to developers.

Some of the larger changes in 1.7 include:

• Proper UTF8 support in the database -- This allows developers to use MySQL's native string functions in queries
• A new data directories layout to work with standard filesystems
• Full-text search
• A new core API for retrieving entities
• A functional REST API
• Unit tests

I'd like to personally thank the following people for their contributions to 1.7:

• Cash Costello for endless testing, developing, bug reporting, and feedback
• Justin Richer, Nathan Rackliffe, and Tom Read from MITRE for the basics of the new search
• Mike Lietz, Patrick McSweeny, and Kevin McCollough from eTech Ohio for bug reports and patches
• thomas, sammykanan, gv, coldtrick, jaakko.naakka, markharding, milan, and twall for testing against SVN, submitting trac tickets, and submitting patches

This list is by no means all-inclusive, so for anyone I mistakenly left out, thank you too!

With more people joining the effort to test, to patch, and to develop, Elgg is really gaining momentum. This is absolutely great news and I'm very excited about what the future holds! The increase in developers has, however, demonstrated that we need to change how our SVN repositories are organized. To simplify the development process, the separate core and extensions SVN repositories and tracs will be merged into a single repository and trac system. The SVN repositories will be updated to a standard branches, tags, and trunk layout to allow concurrent development and support for multiple versions of Elgg.

To implement these changes, Elgg's SVN and trac will be unavailable until March 3rd, 2010 at 9:00am EST. Watch this blog space for information on how to switch to the new SVN layout.

The road to 1.7 has been an exciting one for me, and I hope that 1.8 is just as interesting!

Client Applications

Ever use an application like Tweetdeck or Tweetie? Those applications use Twitter's API to provide a richer user experience than you get with the web interface. The same can be done with Elgg. As a developer, you can expose functionality through the REST API by building a plugin and then either publish the API for other developers to build clients or provide your own. Here is a simple example of exposing a method so that a client app can post a status update to the wire in Elgg:

1. Write your function that creates the wire post

function rest_wire_post($username, $text) {

    $user = get_user_by_username($username);

    if (!$user) {

        throw new InvalidParameterException("Bad username");

    }

    $obj = new ElggObject();

    $obj->subtype = "thewire";

    $obj->owner_guid = $user->guid;

    $obj->access_id = ACCESS_PUBLIC;

    $obj->method = "api";

    $obj->description = elgg_substr(strip_tags($text), 0, 140);
    $guid = $obj->save();
    add_to_river('river/object/thewire/create',

                 'create',

                 $user->guid,

                 $obj->guid

                );
    return "success";

}

2. Expose it

expose_function('wire.post',

                "rest_wire_post",

                array( 'username' => array ('type' => 'string'),

                       'text' => array ('type' => 'string'),

                     ),

                "Post a status update to the wire",

                'GET',

                false,

                false);

3. Use it
Type this into your browser's address bar making the obvious replacements for your site:

http://mysite.com/services/api/rest/xml/?method=wire.post&username=cash&text=hello

Now, in a real application you would want to make this a POST request rather than a GET and protect it with user and API authentication. For more information on that see the Elgg REST wiki page.

Mashups

Ever wonder how those cool mashups that use Google Maps and some other data source work? A key component to those mashups is that just about any Web 2.0 application provides a web services API. Now that you know that Elgg provides a framework for this kind of functionality, you can start imaging the possibilities of what you can do with your Elgg-powered site.

Integration

You have another open source application that you want to integrate with Elgg but you don't want a lot of ugly dependencies between the two code bases. One way to achieve a clean integration is to use web services APIs. You can create plugins for one or both platforms that push and pull data so that it is available on both platforms. This could be the authentication of users, activity on the other application showing up in Elgg's river, or content being synchronised between the platforms.

Those are three ways the API can be used. I'm sure you can come up with other ways. If you're looking for inspiration when designing your API, check out Twitter and Flickr. Elgg's implementation has a similar interface. And oh, if you do find any bugs, be sure to post them to Trac!

This means that all new functionality is finalized and only bug fixes will be made in SVN. We think all major bugs have been resolved and the core is ready to be beta tested, but want a few more days of testing before we are comfortable releasing a beta to the general public. If you have a spare minute, please grab the latest SVN and give it a try. Note that this is not yet ready to be used on a production server!

It will especially be helpful for plugin and theme developers to download the latest SVN and check that their plugins work correctly. One part that plugin authors should especially check are the actions tokens. As stated in my previous blog post, action tokens are required in Elgg to ensure the security of Elgg sites.

It is not difficult to add security tokens to your plugins. Two input values need to be set for actions: __elgg_ts and __elgg_token. There are a few helper views and functions to simplify this:

elgg_view('input/form')
elgg_view('output/confirmlink') - When is_action is passed as true in $vars
elgg_view('output/url') - When is_action is passed as true in $vars
elgg_view('input/securitytoken') - For forms
elgg_validate_action_url($url) - For URLs

If setting the fields manually, use the current time stamp to generate the token.

$ts = time();
$token = generate_action_token($ts);

$action_url = "server/action/myaction?__elgg_ts=$ts&__elgg_token=$token";

Again, tokens are required for the security of Elgg sites. Please update plugins accordingly. If you have any problems implementing security tokens, please post to the development list or community site and I will do my best to answer your question.

Subversion branching is a cumbersome process at best: "svn copy" commands are executed at some revision number, which you must keep track of for later merging. Any time you port trunk changes into your branch, you have to again carefully note from X to Y revision. Add to the mix multiple developers each with their own branches and maintenance becomes a nightmare.

Your Git repository, however, is itself a branch of the original project! Each developer has a full copy of the entire project, including file history, in their local branch. (This is what makes Git "distributed".) Commits to your branch are all local. You can queue up as many commits as you want, even while offline, before merging your changes back to the remote repository. A single "git push" command is all that is needed to take care of all merging at this point; no need to remember revision numbers or paths!

Worried about navigating through all these distributed branches and commits? No need: Git comes with powerful command line and graphic tools already built into your repository. If that's not enough, check out GitHub for (potentially) free hosting space. You might even notice that Elgg is already hosted here. That's right, all Elgg trunk commits go into both Subversion and Git!

To learn more about Git, I strongly recommend checking out the Pro Git book by Scott Chacon. It's released under a Creative Commons license, meaning it's absolutely free to read online!

I know far too much of my development time has been wasted in counting function arguments. How often have you tried to get, for example, the number of blog posts, only to have to find the get_entities() function definition, then count the number of arguments between the 'subtype' and 'count' parameters (remembering to include the defaults if you don't want to change them) just to put in a TRUE? You don't care about the owner_guid, order_by, limit, or offset parameters, so why should you have to think about them? 1.7's API changes that function call from:

$entities = get_entities($type = 'object', $subtype = 'blog', $owner_guid = 0, $order_by = '', $limit = 10, $offset = 0, $count = TRUE);

to:
$entities = elgg_get_entities(array(
'type' => 'object',
'subtype' => 'blog',
'count' => TRUE
));

This part of 1.7 is done and ready to be used by all plugin developers. Like I previously said, though 1.7 introduces this new API, it does not break compatibility with the previous API. All the old get_entities*() functions wrap to the new API and including any previous bugs (container_guid, I'm talking about you).

[Edit] One thing I forgot to mention was that these new functions are the beginning of function namespacing in Elgg. Instead of using the namespacing introduced in PHP 5.3 (because we like keeping Elgg running on as many servers as possible), we've decided to begin prefixing functions with elgg_. The biggest implication is that this will eventually allow for easier integration with 3rd party apps.

In general 1.7 news, there is one outstanding issue that needs to be resolved before a beta for 1.7 will be released. For those interested, it is ticket #750, a long-standing bug for a security enhancement concerning actions. Once that is complete, a beta of 1.7 will run for a few weeks. Assuming testing goes well, 1.7 final will be released following the beta.

Once again, I'd like to thank everyone for their patience and understanding with 1.7's development. The developers and Elgg administrators Dave and I have spoken to each gave overwhelming support on the decision to take a release to solidify core. I am extremely happy with the progress of 1.7, and hope to have a beta for everyone soon.

If you have been following the commit timeline, you will know that there has been significant development on the core. The aim is to sort out some of the annoying issues which have persisted in Elgg since v1.0 and to introduce better coding standards. We feel that it is worth taking the time to make sure v1.7 is the most stable version of Elgg so far and a solid platform for you to build upon.

We are currently working with developers in the community to test, debug and patch any remaining or unexpected issues that arise during testing. If you would like to help out, please feel free to grab the nightly build or latest from SVN and report back any issues you find. Patches are also welcome and can be uploaded to Elgg's trac. I need to stress - DO NOT USE THE NIGHTLY BUILD OR LATEST SVN ON A PRODUCTION SERVICE.

We would like to thank everyone for their patience.

We are specifically interested in testing, feedback, and bug reports of the following:

• Backward compatibility with 1.6's plugins.
• Correct support for UTF8 in the database for new and upgraded installations.
• Correct migration of user data files from username-based storage to GUID-based storage.
• Services APIs
• New search plugin

In order to provide the best release possible, we must have a large number of test cases. Many people use Elgg in clever and unique ways that we can't always anticipate, so please, developers, test.

Test new installations; test migrated installations (Need to duplicate your live site?); test installations with the core only; test installations using all the plugins you can find. Just test! The more people testing, the fewer bugs there will be in 1.7 final!

Collaboration is what makes an open source product tick, and I'm happy to have had the opportunity to work with some community volunteers on this version of Elgg. Cash Costello has been a very active member of the community for a while, and has spent the last month fixing Elgg's Services API. He's working hard to make sure Elgg's services APIs are up-to-date, bug-free, and consistently easy to use. Thanks Cash!

Justin Richer and his team at MITRE introduced the base of what is the new search. While there are still details to sort and bugs to squash, this new search is factors better. Justin and I are keeping in close contact to make sure the new search is easily extensible for plugin authors, and simple for users. Thanks to Justin and everyone at MITRE!

Elgg Camp Buenos Aires is quickly approaching! I'm flying down tomorrow to meet up with the guys from Keetup, Condiminds, and Farmsphere. I'm honored to be giving the keynote and am very excited to meet other Elgg developers! Be on the lookout for pics, tweets from (me and the official Elgg account), and hopefully some SVN commits from the southern hemisphere!

Sorry for the delay in posting--I've been busy in both my developer and personal life and haven't had a chance to sit down over the weekend to write a wrap-up. I've received quite a few emails from people asking after 1.7. No need to worry: development of 1.7 is going well and I'm hopeful to have a developer's preview release out the door by the end of this week, with 1.7 final out sometime in December.

As I mentioned in a previous post, Elgg 1.7 will have no new features, but will focus on standardizing the API, correcting long-standing bugs, and generally making sure that Elgg is a solid platform to develop on. Some of the major bugs that are corrected in already include:

• Rest and services API work now (Thanks Cash Costello!)
• File storage based upon GUID instead of username
• Unit tests added (Yes, this could be considered a feature, but YAY UNIT TESTS!!!!)
• Availability and order of parameters in get_entities*() functions normalised
• UTF8 support added in the database

As I said on the developer's mailing list, even though the new functions will be available for developers, the old functions will still work. There seems to have been some confusion, misinformation and FUD spread around concerning this point so I'll make it again: Elgg 1.7's API will be backward compatible with Elgg 1.6. Feel free to quote me on that. :)

In an effort to help answer the question "What changed in this version of Elgg?" we have started listing major bugfixes and changes in the CHANGES.txt file. It's a good read!

Moving along, this is just a reminder that as of November 2nd, 2009 the Elgg Users Google Group has closed to new members and messages. Existing content is still available to read, but please use the Community Site for all user troubleshooting and discussion. Please read the origina announcement for more information.

Now to the fun: ElggCamp Buenos Aires! Pedro Prez with Keetup Development, Susana Cipriota with Condiminds.com, and the folks from farmsphere.com have organized ElggCamp Buenos Aires on November 19th, 2009. Following ElggCamp Boston this past August, I'm really looking forward to heading to BA and meeting some of the Elgg users and developers in the southern hemisphere! Not to mention it's spring there, and a chilly autumn here in Ohio.

The ElggCamp BA site has loads more information that Google Translate can help with if your Spanish is rusty. If you happen to be in or near Buenos Aires, stop in!