Time for realistic long-term Roadmap?

Well, anybody can see starting of big rework in repo, appearing "Version 1.8.0" chapter in CHANGES.txt. What about informal, preliminary ROADMAP for Elgg's future? Any decision-maker abobe ordinary hobbyist want to know

  • What
  • When
  • How

he can get (anything) from selected core-platform. Will be informing you somehow some type of "fair play", isn't it?

When I say about roadmap, I don't keep in mind Trac-type roadmap (as overdetailed programmer's roadmap) and Dave notes (as abstract short-time ideas), I want to see smth. inbetween these borders: some more global (but still descriptive in terms of use-cases and|or tasks) changes and addons for application

I, personally, have interests in such areas (just partial dirty example):

  • Application in common
  1. Replaceable natively translation engine;
  2. Using alternative template engines (real templaters);
  3. Native and full i18n
  4. UserGroups, ACLs as method of movement from "formal anarchy" to "manageable hierarhy";
  • Social Networking
  1. Smart Search (multicriterial, parametrized probably);
  2. Full user's actions history (with access to all UGC);
  3. Content aggregation and separation (methods to get wanted content from any site's user and eliminanate unwanted);




  • I'm curious about the translation engine. What would you suggest instead of the current PHP strings system?

  • My needs can seems exotic and uncommon, but as any other user, if current system is bad for me, I want to use good solution and preferrable way is to do it without dirty hacks on hacks on hacks, which produce fork as final result.

    For me, as for any user  which language have plural forms, *gettext is (AFAIK) a single right solution for today. I know about some speed overhead coming with it, but it counted (me) as minimal impact and, with better manageability of pot/po sources and translation process in common, it's fair price (from my POV).

    From other side, maybe somebody prefer to use Linquist, f.e, or some other engines, which just don't know. To have choice is better than have nothing. If user don't care - it uses default values, if care - he can do that he want, not that dictated for some unclean reasons.

    My position about template engine is the same - current template are (ideologically) worse than terrible. Instead of tips and tricks giveto the end-user freedom of choice and clean rules, which he must follow. Drupal (fast example) supports 4 or 5 (if my memory servers me right) TEs and it doesn't broke anything

  • The following is what I'd like to focus on for the next few versions of Elgg.  Specificity decrease as ETA increases.

    Elgg 1.8 - Q3 2010


    1. UI/UX - (A new default theme, drag-n-drop plugin reordering, UI consistency)
    2. Improved views model with semantic view names.
    3. Improved markup and CSS to allow CSS-only themes.
    4. CSS primitives.
    5. Improved plugin subsystem with plugin dependencies, generic testing of a plugin's functionality before allowing it to be enabled, uploading a zipped plugin.
    6. Rewritten bundled plugins.  (Not all of the...Blog is in the works, groups would be awesome but we'll see).
    7. Sticky forms
    8. Performance improvements by making better use of query caches, eliminating redundant caching, and possibly extending memcache support.
    9. Better debugging.
    10. Full RSS, JSON, and XML support.  (ODD will be gone, and JS will likely be removed, too.  Anyone use it?).
    11. elgg_echo() passing through sprintf() with argument swapping for easier string translations.
    12. "Friendly time" customization support.
    13. Better search on users (profile information) and options to sort by most recent time.  Advanced search features.
    14. Elgg JS object to solve a few common problems with using JS in Elgg (token renewal, Ajax handling, popup messages, string translation).
    Elgg 1.9 - Q1 2011
    1. Better hooks to allow plugins to implement roles and permissions.
    2. A moderator-level user (possibly, very much still in early talks)
    3. All bundled plugins rewritten.
    4. Replace simplecache with something less fussy.
    5. Denormalize the metadata and annotations tables.
    6. Re-examine the indexes in the DB schema with hopes to optimise it.
    7. Introducing "something between ElggEntity and ElggAnnotation" to allow annotations on annotations ("I like this" on a comment) and metadata on relationships.
    8. Queue metadata write operations until an object is saved.  Provide implicit save for backward compatibility.
    Elgg 2.0 - Q3 2011
    1. DB query and recordset classes.
    2. Better URL routing.  (I've been known to say some unkind things about Rails, but this is something it definitely does right...)
    3. Massive code cleanup.  There's lots of vestigial code.
    4. gettext support.  (I was not around for the pre-1.0 dev planning, so I'm not sure why this was removed.  If there was a good reason, it may not be re-introduced.  I do agree that it is the easiest way to localize language strings and any overhead is inconsequential.)
    5. Object oriented plugin architecture.  (Will allow core to call methods on plugins like onEnable() and onDisable() for set up and garbage collection.  Good times...)


    The optional templating system Alexander mentions would be interesting, but probably couldn't happen until 2.0.  Elgg does have the ability to change the template handler (see http://reference.elgg.org/elgglib_8php.html#003f835e40d55c410dfe0c4b51a0a858), but I doubt its usefulness for what Alexander wants.  Has anyone used this at all?

    This list is, of course, neither comprehensive nor fixed.  It's my hope the community will drive the improvements with discussion, testing, and development.

  • Will this new default theme be a plugin or part of core?  I would vote plugin...

  • The default theme will be part of core.

  • Who is helping with/doing the design? Are you taking outside opinions/help with the new skin and CSS? The reason I ask it the skin is one of the first things I change, I am a designer, and I would love to help.

  • @Ben - there have been two discussion threads so far. One focused on cleaning up Elgg's default markup: http://community.elgg.org/mod/groups/topicposts.php?topic=397103&group_guid=212846

    The other on Elgg's default css: http://community.elgg.org/mod/groups/topicposts.php?topic=424690&group_guid=212846

    There has already been some work done on this and I'm sure that Brett and Pete would love feedback. You can grab the latest at http://elgg.org/download/nightly/trunk/ (Note: this is the beginning of Elgg 1.8 and is very unstable. It is not for production environments.)

  • Brett, I am curious about your longer term goal to "Denormalize the metadata and annotations tables."

    Would this be something that happens behind the scenes as a kind of automatic database tuning or would the idea be to essentially abandon the current completely flexible entity-attribute-value design and go back to the more traditional approach of having plugins declare a fixed table structure with one or more separate tables for each plugin?

    If it is the second, do you have any performance information suggesting the speed-ups that might be gained with the more traditional multiple table approach?

  • @Kevin - It is absolutely not the second approach.  The annotations and metadata tables are normalized with a foreign key (two, actually) to the metastrings table.  This means requesting the value of a metadata name for an entity requires either 2 joins or 3 queries or some combination thereof.  There is already at least 1 join between the entities and objects_entity (or users, groups, or sites) tables, and probably another join / query between entities and entity_subtypes.  Joins 

    Denormalizing these tables is wholly transparent to anyone using the API, and makes life simpler for anyone writing their own SQL because it means 2 fewer joins on every metadata and annotation call.

  • @Brett - Couldn't agree more with the denormalizing those tables due to my experience whilst creating my threaded forums plugin.  The queries can become quite long and tedious so makes sense to me.

    And judging by your list above - the future of Elgg looks great with lots of exiciting improvements to come.

Feedback and Planning

Feedback and Planning

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