The end of 2014 and roadmap after 1.10

While we are hard at work releasing 1.10 and running through all the tickets i can see us ending up with 700 tickets open at the end of 2014! That's a big reduction on tickets compared to 3 months ago (1000+). Thanks to everyone for helping to get all that work done.

However this still means that there are a lot of tickets left. For 1.11 i consider the following topics important to work on (in no particular order):

  • performance / caching (memcache)
  • ajaxifiing stuff (pagination, comments etc)
  • pull discussion out into its own plugin
  • general way of handling icons (dev usability)

This is just my personal interest, i would like to hear more people about what should be the focus for 1.11

  • comment/discussion threading and ajaxed replies/comments are primary missing features that turn people away from using elgg sites (they are commonly experienced with facebook which has refined this significantly).

    i would also like to see juho's push server integration and realtime notifications get some attention. he has got it mostly working and so with some refinement and bugfixing we could have fully functional notifications, inbox messages and realtime chat running from his code,

    i intend to finish the supajax plugin that ajaxifies the tabbed lists in elgg nicely, once i get my site upgraded to 1.9. it would be helpful to communicate on this topic so that i can make my code useful to core and also do not replicate what core coders are doing.

  • Hi!

    You could also take a look here :
    It's an intense use of History HTML5 API that make elgg full ajax, GET and POST request. It's use History.js lib for old browser compatibility.
    There are some functions to do :
    - store a page (like river page) in the DOM to restore it very fastly (like gmail).
    - store tabs and change url.
    - register direct action. It perform action without change url and register some code when this action is done or fail.

    - execute javascript hook when url click, page loading, page done, submit form...

    And I made a plugin with node.js for elgg.
    It's a bi-directional integration, elgg to node and node to elgg. I use it only for easyRTC (live video chat) and realtime notification (websocket).

    Hope it could be useful to ajaxify elgg...

  • We use HistoryAPI too (thanks @ManUtopiK for fantastic startpoint for us ;) ) and I think that it could be integrate in Elgg Core

  • Make async file uploads and entity icons dead easy for devs.

    I still think entity lists is an important API, and I think I've got it 95% ready for core (already fine as a plugin) but I'm getting tired of pushing the boulder.

    I'd love to get the standard core bootstrap down to near 0 queries when persistent caching (memcached/APC/files) is on.

    Come up with a design pattern and components for efficiently (pre)loading data that will be used when rendering lists. See the likes refactoring in 1.10 for example. -- On that note I have an experimental proof-of-concept of an API that would would allow "late-binding" view rendering so that the system could defer expensive data fetches in hopes they they can be fetched in batches. E.g. rendering a list of 100 entities with whom the user may have a relationship. The fetch could be done in 1 query and the results beamed into finish rendering.

  • So awesome that we've been able to clear out almost 25% of our tickets.
    That's just... incredible. Definitely helps with the focus. 
    We're also well on our way to dealing with the duplication issues that
    Brett brought up some time ago. We're quite close to being able to
    decommission Our code health is increasing steadily with the
    refactoring that's been happening. Switching off of SimpleTest feels more
    and more within reach.

    We could also stand to just focus on making common Dev needs really easy. 
    Most common thing I can think you'd want to do with your new site is change
    a given page. We even have a plugin showing how to do this. IMO it is too
    convoluted. We should make this dead simple by moving page handler scripts
    to standardized view locations. Either "pages/*" or "resources/*". I lean
    toward " resources " as a nod to HTTP terminology and pages could be
    confused with page/*. However, pages is probably accessible to a wider
    audience. In any case, No hooks required. Just plop a file at the right
    view location and customize to your heart's content. If we give people
    this, that makes implementing a custom ajax solution far more trivial,
    because you clearly have full control over the whole HTML output of the

    Site specific customization is another one of those things I've been
    thinking about a little bit. Ideally we'd allow elgg to be installed as a
    composer dependency of an app, and the root of the app is treated like a
    plugin that always loads last. Unfortunately I feel this ideal is much
    further out of reach for now.

    Agreed that associating entity icons is another one that is unnecessarily
    painful. Uploading them smoothly is yet another related task to consider... 
    Unfortunately I still don't see ajax happening **in core** any time soon.
    We should definitely make it easier for plugins, though. I just feel it
    will need so much work and tweaking and baking to get right. And the
    JavaScript world is much more modular now, but doesn't seem to have settled
    on a dependency management system like composer and php. It's also changing
    extremely rapidly. Maybe faster than we can keep up... Native web
    components might be the way to go rather than any js framework simply for
    interop's sake. Do we need our own API to shield us from the change? I just
    don't know...  Add to that the fact that elgg is a huge app. There are many
    many pages and components that we'd have to convert. Designing a way to
    make menus work in a backwards compatible way has been a fun challenge.
    Part of it is also just embracing the fact that most elgg code is written
    in php. Is there a way to bring that to the client without totally
    rewriting everything? Could we have something that knows how to render
    menus registered with the current php API?

    One thing I've thought is we could start with just converting the
    installer, for example. That's a relatively small, isolated piece that
    would give us some experience with framework X without forcing us to commit
    to it whole hog. Could also really improve that experience. But then it
    would be weird to have a nice slick installer and an old, janky Web 1.9
    experience after that.

    I'll keep thinking... Want other folks' ideas here too... I just don't want
    something half baked. Whatever we do I want to to be good, or not do it at

  • [Rats, when I edited Evan's post I hit this bug and didn't notice before saving.]

  • i perceive that what is needed for ajax advancement is to define/expand a solid and reliable core approach to converting page elements to ajax (moreso than what is currently available) and then having some way of orchestrating the conversion of elgg features to be ajaxed.
    an ajaxed installer as a testbed is a decent idea, i agree. however, elgg is sorely missing the type of rapid conversation that is possible in facebook and other sites - so much so that people simply refuse to use my site because it is not on there. in the time that one comment is posted and the page is reloaded in elgg, there can be 2 or more comments posted in facebook in the same thread. putting focus into threading/organising comments/replies in the river and in general - plus ajaxing the the whole process - will continue to be, for me, by far the most valuable introduction of ajax into elgg and the most necessary. text communication is the core of social networking (until video replaces it at some point) and to not optimise this part of the system is to have a failing system.

  • Admin performance and troubleshooting page with tips and tricks

  • oh and improve dev usability of input/autocomplete / livesearch

Feedback and Planning

Feedback and Planning

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