Questions about Elgg's future

I've been working on a project using Elgg for the last 8 months.

1. I'd like to know if the team ever considered replacing the core Database library with an open source ORM such as Doctrine which already implements Memcache and a slew of other useful features (such as event listeners).  http://www.doctrine-project.org/

2. I'm also curious to know if a tool like php_debug was ever considered? It creates a visual tool bar with debugging information right in your page. http://www.php-debug.com/www/

3. Are there any plans to generate a static version of the CSS and Javascript rather than using simplecache? Or plans for database caching rather than file caching?

4. Will there be a type of routing system in the future? In order to eliminate the use of keywords like pg, tag, action and export in the URLS?

5. Will Elgg continue to forward() (to home page) rather than display a 404 page (or appropriate error) in the future?

  • Hi Jon:

    1. I'd like to know if the team ever considered replacing the core Database library with an open source ORM such as Doctrine which already implements Memcache and a slew of other useful features (such as event listeners).  http://www.doctrine-project.org/

    There are no plans to incorporate an ORM into Elgg.

     

    2. I'm also curious to know if a tool like php_debug was ever considered? It creates a visual tool bar with debugging information right in your page. http://www.php-debug.com/www/

    There are plans to enhance debug and developer tools in Elgg, but php_debug isn't one of them.  This is mostly because incorporating it would mean Elgg is dependent upon PEAR, which is a beast.  A plugin could easily be written to provide this functionality, though...

     

    3. Are there any plans to generate a static version of the CSS and Javascript rather than using simplecache? Or plans for database caching rather than file caching?

    Simplecache has many problems and will be re-examined for 1.8.  One of the problems in producing static cached files is that the data directory lives outside the doc root, so the files must be read by PHP to be sent to the browser.  We'll have to do some benchmarking to see if caching to a database is more efficient than caching to a file, but my inclination is that it will be.

     


    4. Will there be a type of routing system in the future? In order to eliminate the use of keywords like pg, tag, action and export in the URLS?

    hrm...I'm not sure I'm following this one.  All URL-routing apps I'm familiar with use keywords...some are just a bit clever about it.

     

    5. Will Elgg continue to forward() (to home page) rather than display a 404 page (or appropriate error) in the future?

    This is something that should be fixed.  Might be worth putting in trac.

  • Brett,

    Thanks for the quick reply

    There are plans to enhance debug and developer tools in Elgg, but php_debug isn't one of them.  This is mostly because incorporating it would mean Elgg is dependent upon PEAR, which is a beast.  A plugin could easily be written to provide this functionality, though...

    I've already developed a module for php_debug that is not dependent on PEAR. I am using it in my current project. However I am required to add code to Elgg's core files. This obviously is not ideal. If Elgg were to come with such a tool no core changes would be required. This is why I ask.

    hrm...I'm not sure I'm following this one.  All URL-routing apps I'm familiar with use keywords...some are just a bit clever about it.

    I'm looking for something along the lines of what Drupal does. Registering URL paths and assigning functions to them (to put it simply).

  • I think a better routing system would be a good addition to Elgg. I wouldn't expect too much overhead and it creates a lot of flexibility. It would also mean no more complicated mod_rewrite rules in .htaccess

    On debugging tools, I've thought about adding a visual toolbar to the Elgg developer tools, but have been happy with FirePHP/Firebug. If you haven't tried it: http://community.elgg.org/pg/plugins/costelloc/read/384962/elgg-developer-tools

    What changes to the core did you need to make?

  • Cash,

    On debugging tools, I've thought about adding a visual toolbar to the Elgg developer tools, but have been happy with FirePHP/Firebug. If you haven't tried it: http://community.elgg.org/pg/plugins/costelloc/read/384962/elgg-developer-tools

    To be clear. I was using PHP_Debug as an example above. FirePHP works just as well In most cases.

    What changes to the core did you need to make?

    In my case (with PHP_Debug) I had to add a couple lines of code (to the database lib) to capture the execution times of queries as well as total query count and query string. I could have done this by looking at the logs but a toolbar or similar is more convenient. Especially when testing the count differences between Memcache on and off.

  • If FirePHP is acceptable, then the Elgg developer tools plugin should work for you.

    FYI: in Elgg 1.7 the query log is being removed because it was causing memory usage issues. I think we have options though on putting something together to accomplish the same purpose in future releases: whether a specific query debug flag or adding events on each query. If you'd like to see this in Elgg, please open a Trac ticket.

  • Cash,

    I'll give it a try. See if it meets my needs.

    Thanks.

  • I'm looking for something along the lines of what Drupal does. Registering URL paths and assigning functions to them (to put it simply).

    Ahhh I see what you mean.  I though the objection was to having to base the routing on the url. I thought you wanted someone to code up sentience.  ;)

    I agree the page handling can be improved.  There's another thread about improving how the pagehandler dispatches pages, but this is slightly different.  I'm all for suggestions on improving the page routing in Elgg.  I'm not a huge fan of the hefty .htaccess file anyway.

    Also, Cash's debug tools are pretty good.  I'm hoping we can start pulling parts of them into core for 1.8+.  I'll be interested to hear how they work for you.

  • Cash,

    Thanks for the link

  • Core modules can be turned off...they're exactly like any other plugin except they ship with core.  They generally provide some low-level, required features like input filtering and garbage collection.

    You can see a list of them here: http://code.elgg.org/elgg/trunk/mod/

Feedback and Planning

Feedback and Planning

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