Elgg Ajax

Hi, everyone,

Brett and I have been tossing ideas back and forth about how Elgg could better support AJAX functionality.  We wanted to open it up for community discussion and see what kinds of use cases people are looking for.  We'd like to get a first version of this into Elgg 1.8. There are no hard promises (yet) with regard to which of these things get implemented/released in 1.8 or ever.

So far, here's what we've come up with (in no particular order):

  1. Action token renewal - refresh action tokens on the page so that forms don't time out
  2. Message/error display - display system messages without refreshing the page
  3. Language translations - Avoid having to echo from php into javascript
  4. AJAX form validation/submission - integrating this functionality with the input views
  5. Ajax actions - especially recycling actions so that they can be called via ajax.
  6. Scope core javascript under an 'elgg' javascript object.
  7. Replacement for the friendpicker 

    And while I was typing this up I remembered some more possible ajax-related enhancements (neither of which are originally my idea):

  8. AJAX pagination - saves page refresh and allows multiple paginations on a single page.
  9. Support for live feeds (e.g. auto-updating river/wire).

    Finally, the following are some suggestions made by the community:

  10. (Milan) Conditional inclusion of jQuery UI components, with all components available in core.
  11. (Cim) Auto-update message counter/timestamps
What we'd like from you is simply more ideas for ajax support as well as which ones you think are most important/useful to you.  We're looking for suggestions more along the lines of making ajax development easier (e.g. action token refresh) than for particular ajaxy features that you'd like to see (e.g., a chat plugin). That said, brainstorming about the kinds of features you'd like to see might help us find a common ajax-related need.  Excited to get your feedback!
You can view my current progress at http://code.google.com/p/elgg-ajaxify.  Please note that everything there is experimental, not fit for production environments (or even development environments), and may or may not make it into Elgg core. The "plugin" is simply meant to be a playground where we can experiment with implementation ideas.
  • Lovegin John

    A better user administration in the admin console, as the spamming on elgg sites are high now. Will be a good addition if we can select many users and delete at once or add a ban/delete option shown with the users list and works with ajax. This really saves a lot of time.

    Tool/Plugin management & rearrangement with ajax - There is a 3ed party plugin that does most of it.

    Provision for opt out the richness of ajax in member pages, as some webmasters may wish to increase the page visits. An admin configuration will be good to define the ajaxed components.


    These are some thoughts. I will fill in more as I get refreshed...


    Lovegin John

  • finally a relevant discussion that strikes my interest! ajax really does make a website more "fun" to use. i must agree with you evan, the tokens for the forms needed to be "ajaxified". i tend to type a long blog and all my stuff is gone, so yeah that should be a for sure feature. generate a new token maybe before the old token's time is up? here's a list of features that i'd like to see on 1.8, besides the obvious that i've already seen on 1.8. sorry if i mentioned the ajax request you guys did but it's a list i go by in order.

    here's a list i made up of ajax functionality for 1.8:

    • riverdashboard activity river, refresh when new entries are detected in the river table in the database. timed interval refreshes are cool but it's a bit vague.
    • i agree with you on the pagination refresh via ajax
    • messages in the inbox, deleting and also paginations
    • message counter, shows the message counter without refreshing the page
    • timestamps refreshes per minute without reloading the page
    • pop up wire reply box
    • a simple chat room showing user's icons and display names. also option to add mods via /op or /deop command
    • the ability to add a friend straight from the river without reloading the whole page and also comment someone's message board via pop up box
    • simple chat bar like fb, i've found a instant messaging framework at http://ajaxim.com
    • internal notifications that pops up on the corner of the site notifyin the user that they have a new message board comment, message, blog comments, etc.

    and that's it for now, i'll probably add more when i get enough sleep. hope this helps out your brainstorming guys!

  • Evan,

    AJAX form validation and AJAX actions sound excellent! I'd implement those first if it was my decision :) Making actions to support AJAX calls would make it easier for any plugin developer to add some fancy AJAX stuff without duplicating code. I really like the sound of that!

    Pagination and live feeds also sound like great improvements, although from my point of view they're not a high priority.

  • Hi everyone,

    It is not AJAX form validation but my plugin libforms_utils help form validation using the jQuery validate plugin. It could be a first step in the via of make more client side validations eventually merged with AJAX server side ones.

    I put my votes on:

    • AJAX pagination
    • Action token renewal
    • Messages error display
  • Hi,

    As for the rest I'll add my 2c point by point:

    1. I've already written a plugin to renew action tokens, but your action requests will need to be updated to make use of it http://community.elgg.org/pg/plugins/milan/read/398781/ajax-action-token-regenerator
    2. That would be good, I'm already doing a lot more client side validation using jQuery validate
    3. This is a pain, but I don't think it'll be good to put the whole language file into javascript (not sure if you meant that). Also sometimes I have to include the current user guid into a request, so i've set up three levels of javascript (and css) on my site via views (i.e. site wide, session scope and page scope), which can be cached (http://trac.elgg.org/ticket/2002) and compacted (JSMin).
    4. *snap*
    5. I'd like to see something like this myself, moving from 1.6 to 1.7 is going to be a real pain for me as a lot of my actions are ajax actions!
    6. I have no idea what you mean about that, can you explain in more detail?
    7. The friend picker is pretty bad in my view, I was thinking if elgg's jQuery is updated to 1.4 (which looking at svn attempts are being made to do so) and updating to jQuery UI 1.8 (UI 1.7 is currently incompatible with jQuery 1.4) then the new UI 1.8 autosuggest feature could in used as a replacement with a populated options/select box.
    8. I like this idea, but as long as pagination would still work without javascript as otherwise this would effect how search engines would crawl sites.
    9. Do you mean an auto updating activity feed, as it's something i'm planning to work on anyway (as well as collapsing multiple items i.e. multiple blog posts by one user etc). On a side note it would be nice to see all modules included with Elgg to use the river features, as at the moment most don't. 
    Expanding on #7 Currently Elgg comes with a incomplete jQuery UI lib (which is understandable as it's all the features the core uses). What i've done is to download the complete jQuery UI lib, strip out the bits which are already included and then separate the features into a different files. Then create views for each file i.e.
    jquery/datepicker view:

    <?php global $CONFIG; ?>

    <script type="text/javascript"

    src="<?php echo $CONFIG->url; ?>vendors/jquery/jquery-ui-1.7.2.datepicker.min.js">


    and finally i'd load them in each of my modules which a function that would make sure that each extra script is only called once ...

    function extend_javascript($view) {


    if (! is_array ( $JAVASCRIPT_VIEWS )) {

    $JAVASCRIPT_VIEWS = array ();


    if (! in_array ( $view, $JAVASCRIPT_VIEWS )) {

    extend_view ( 'javascript', $view );

    array_push ( $JAVASCRIPT_VIEWS, $view );

    return true;

    } else {

    return false;




    where the 'javascript' is something I put into the header view. I then can call extend_javascript('jquery/datepicker'); in each module that uses it (normally surrounded by a if 'context' - which in hindsight should be part of the function).
    Think that's it for now ;-)


  • @Milan,

    1. Your plugin happens to be the foundation/inspiration for my implementation, here!  Thanks for doing that.
    2. -
    3. We realize that this has the potential to add a lot of bloat.  Currently the plan is to lazy load the translations only for the in-use language.  This would maintain page load time and be cacheable.  We'll have to do some benchmarking to see how it affects client-side performance.
    4. -
    5. -
    6. All of the core javascript is in the global scope.  We want to effectively namespace it under a javascript object named 'elgg'. i.e...

      var elgg = elgg || {};

      elgg.func_name = function(arg1, arg2) {
      //function body

      This is a best practice and will be even more necessary once we start adding more core javascript code to Elgg.

    7. Sounds like a good idea to me.
    8. We will strive to maintain graceful degradation as much as possible.
    9. Yes, that's precisely the idea.  If we decide that it's worth working on for core, you and I may want to coordinate this so that we don't duplicate efforts too much.
    Perhaps I will add the jQuery UI issue you brought up to the list.
  • @Lovegin

    Can you explain more what you mean on your third point about "opting out?"  What are the "member pages" you're referring to?

  • I think what he means is that if an admin wants to count page views (and see them updated regularly) then loads of different Ajax calls on a page won't help this. 

Feedback and Planning

Feedback and Planning

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