I would like to remind everyone that while many bugs have been corrected, Elgg 1.7 is still beta quality software and should not be used in a production environment. When upgrading, be sure to back up your current installation and closely follow the documented procedures in UPGRADE.txt. In addition to these instructions, Cash has written an informative series of posts on the community site about preparing for the 1.7 upgrade.

As previously mentioned, Elgg 1.7 enhances security by requiring security tokens on all actions. Plugins that have not been updated to use security tokens will produce a "Form is missing __token or __ts fields" error. For authors of plugins that do not have security tokens, please review the documentation on actions and security for information about how to add tokens to your plugins.

Some of the biggest changes in Elgg 1.7 include:

• Full UTF8 support in the database
• Full text search (as a joint effort between Curverider and the MITRE corporation)
• More manageable user data directories
• A new entity-fetching API
• Working and re-written REST API (thanks to Cash Costello).
• Tons and tons of bugfixes!

I ask everyone evaluating Elgg 1.7 beta to please make bug reports to the appropriate Trac. For Elgg core, bug reports should be made at http://trac.elgg.org/elgg while any problems with extensions should be submitted to http://trac.elgg.org/extensions.

Again, I want to thank everyone who has helped to bring Elgg this far! In the last couple weeks there have been some great bug reports and information from users like Thomas, gv, and Mike Lietz. Please keep up the great bug reports and feedback!

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!

How is everyone finding the new plugin area on the community site? Since its launch last week there have been generally positive reviews of it. I am pleased with how it functions but know there are a few oddities and hope to continually improve it. The new plugin area features simpler ways for plugin authors to showcase their plugin, recommend releases to their users, request donations, and link to an external project home page.

Because of these improvements and to help clean away some of the clutter, the following new policies will soon go into effect for plugins:

• Projects must contain a functional plugin. Projects with downloads that contain only images, text files, or other non-plugin files will be deleted.
• Use the built-in images feature. Images in the project description or release notes will not be permitted.
• Use the built-in links for donations, home page address, and code repository address. There is no need to duplicate this information in your description or release notes.

As always, plugins uploaded to the community site must be released under an Open Source license. There are many projects that create an open source version of the plugin but also offer a paid or professional version. This is absolutely fine when it is done tastefully, which I'm happy to say is the case with the current authors of such plugins.

Starting January 29th, 2010, plugins that do not adhere to this policy will be given a warning and then deleted if the policies are not followed. This is the first step we're taking to clean up the community site. In the end, we hope to make the community site a place where Elgg users, developers, and newcomers can trade information easily and without distraction. Be watching for more changes next week!

Plugin and theme authors may want to review the documentation on actions and security to make sure their plugins are correctly using the views to generate tokens. To supplement this page, I have written a brief description of when to use actions, page handlers, or include a file directly.

This was the last outstanding issue for 1.7. I will be testing and bugfixing this change before issuing an official beta for 1.7.

Late last year we soft launched a supported version of Elgg aimed at the education market called ElggCampus. Shortly after releasing information about ElggCampus, it became clear that a supported version of Elgg was required by a wider audience so we made the decision to launch an enterprise edition aimed at any individual or organisation requiring a supported version of Elgg.

Note: If you signed up for a demo of ElggCampus, we will add you to the list for elgg.com and make sure you get an invite shortly.

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!