Elgg 2.0 Wish List

I might have missed a discussion on Elgg 2.0 roadmap somewhere on this site, if I did please post the link here.

As we eagerly anticipate the release of Elgg 1.7, perhaps it is time to have an active discussion on what the new features should be and gauge interest from the community so developers interested in developing those features would have some encouragement to move forward.  Since we don't yet have a threaded discussion here, this may not be the right tool/forum for this, but better than nothing.

One request: Please no political elgg posts here.  Let's keep it focused on features not there that you would like to have.  Obviously, this discussion should be for people familiar with what the latest released version of Elgg already have.

This holiday season, be careful what you wish for, it may just come true. 

HaPpY HoLiDaYs and a WoNdErFuL 2010 !!!


  • A native forum with RSS, notifications, threaded comments and so on.

    Thanks for all the developers of the Elgg!

    Merry X'mas and happy new year!


  • Blue - I think you are confusing core Elgg with plugins. Core Elgg is an engine, not an application.

    Curverider is responsible for core Elgg. If you want a forum plugin, you don't need to wait for Curverider - you can write it yourself. Look at what has been done for Tidypics by non-Curverider developers to give just one of a hundred examples.

  • To me the possiblity to run elgg in a closed user environment is one of the prime reasons for using it.

    So it would really be great, if this feature would become part of core. The security implication is such, that doing it by plugins seems to me not adequate. Siteaccess plugin could be a good starting point.

  • @sawjer - You are not alone.  I think many users of elgg choose this platform because they want to create a secure/closed environment.  This is why this platform is different than the hosted models.  I certainly share the same interest.


    However, I am very interested in federating elgg so it can be networked with other elgg sites BY CHOICE.  I am working on a design for federating elggs and hope to start coding soon.  


    The first feature I would like to request for elgg 2.0 core is a truly global unique ID (guid) using perhaps a SHA2 hash of the site id/secret and the sequential database guid.  This will help facilitate what I would like to do.

    The Second feature is the ability to send and receive GoogleWaves.  I think this will help ensure that elgg continues to be compelling and relevant to the evolving social media landscape.

  • I just would add the post about plugin management. Any Software that relies so heavily on plugins for its functionality should have a solid pluginmanagement, see the plugin management post.


  • Trac is the place to describe enhancements if you want the developers to see it: http://trac.elgg.org/elgg/

  • @Cash

    Do I understand Alex Tanchoco right? He would like to see a discussion about the road future development should take . Trac is for submitting errors and patches. My comment is neither submitting errors nor submitting patches. But I would like to help to make elgg useable for a larger audience.

  • @Kevin Jardine

    Speaking about elgg core, excuse me for taking this word more broadly. I am aware of the basic elgg engine. From the user point of view core is what a system implementor sees when he downloads the elgg1.6.1 package.

    My most urgent wishes

    Simpler and more intuitive navigation.  It should not be necessary to learn all sorts of tricks just to go back from this group to the overview of groups. I am an engineer myself and I know about the temptation of creating funtions around technical solutions. Really, it has to be the other way round. The user and the user-admin need to have more say in defining future development. Let's concentrate on this before adding more very specialised functions or features.

    Easier and more consistent language support.

    For people living in a multilingual country (Switzerland) like me with 5 languages I am looking for a better management of translations. Every plugin creator spawns a language plugin. A new release requires a new language plugin. If you ever had to do translations (it is part of my job) you would appreciate the difficulties of insuring a consistent and clear translations. The user is not aware that elgg consists of many plugins with independent translators. He is just puzzled or annoyed by sloppy or cryptic wording.
    Therefore lets add a core admin button that lets the admin download, install and update languages for all plugins installed. Find a person or team that is willing to receive all submitted translation fragments and maintain a central repository for a particular language.

    Easy integration into an existing web presence
    Most Organisations have their web presence. They do not want to start all over again. In such an environment elgg should by easy to integrate. Api's for single user management (also where user management is done outside elgg) and sharing of data for the various web applications should be core functionalities
    To me elgg is an impressiv engineering effort and I apreciate it. But my target users will not see all the ingenuity that makes elgg tick. They just want an easy, pleasant, stylish interface and functions that are useable for a non technical people (Thats why I hope to use elgg for my community project) .

    I get the impression, that elgg developers do not hear the users and system integrators. Has Elgg lost it's steam? I hope not!


  • @sawjer - discussions about improving Elgg on this community site are a good thing. If good ideas come out of those discussions, the best way to capture them for the core developers is to submit them to trac. Trac allows you to select "feature request" and "enhancement" as a type of ticket. Obviously, the best case is to include a patch along with the feature request, but not every one is a developer. Those who submit enhancement ideas without a patch definitely have to be the most patient (fixing bugs takes priority).

    The core elgg development team is small. It would be difficult for them to follow/participate in every discussion on the community site and the elgg developers google group while still getting everything else done that they need to do.

    To give you a positive example of a feature request, someone submitted a patch to add the ability to update a file that was previously uploaded with the file plugin. That patch was integrated into the plugin and is now in the plugin svn repository and should be a part of Elgg 1.7. 

     Kevin's point is very valid. People often expect the core developers to add all sorts of features that really should be/could be community developed plugins. Elgg really is a framework for building social sites. It can be used out of the box as an application, but its power is how it makes it easy to develop social applications.

  • Sorry ahead of time if I'm posting a "wish list" request that doesn't fit into the category of this discussion. Reading the previous posts I am a bit confused about what belongs here and what belongs in the topic of community plugins.

    Anyway, my wish is for more informative subject lines for group discussion email notifications.

    Right now, all email notifications just say "New discussion post."

    It would be helpful, when seeing a bunch of these in my email client,  if the subject also included the site name, group name and discussion name. Or at least some of those. For example, instead of

    Subject: New discussion post

    It would be nice to see something with a bit more information such as:

    Subject: The Elgg Community: new post in Getting Started / Posts by Email




Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.