Well, I think the overall result of the votes and the discussions seems to be oriented towards working on nWiki (hope most of you agree!) so that's what we'll be doing. Just a warning though, we'll be refactoring nWiki quite a lot to bring it up to scratch before handing it back to Ludo's team for maintenance.
It would really really help if everyone could complete this list to help give us an overview of what it should end up like:
http://docs.moodle.org/en/Development:Wiki_features
Martin Dougiamas
Posts made by Martin Dougiamas
Please put all your wishes here (or they definitely will not happen):
http://docs.moodle.org/en/Development:Wiki_features
And please enjoy Mediawiki's way of doing tables
http://docs.moodle.org/en/Development:Wiki_features
And please enjoy Mediawiki's way of doing tables
I'm hoping to have some really interesting general numbers of this kind later this week.
I simplified the descriptions last night a bit too.
Turn off "cachetype" (set it to internal) in the Moodle admin settings. You don't need it to take advantage of eaccelerator, and as the info next to that setting says, it can make your site much slower.
Most of what eaccelerator does is works with PHP to cache processed scripts, and Moodle has no say in that.
On top of this, Moodle 1.8.x can take up a little more CPU than 1.6 did (because of new features), depending on your configuration. However Moodle 1.9 (final release is next week) has had a lot of optimisation work and is somewhat faster than 1.8 all around.
I would also make sure query caching is turned on in MySQL and slim down your PHP a lot ... do you really need all those modules taking up your memory?
moodle.org looks like this:
./configure --with-apxs2=/usr/sbin/apxs --enable-mbstring --with-libdir=lib64 --with-mysql=/usr --with-pear --enable-sockets --with-gd --with-jpeg-dir=/usr --with-ttf --with-freetype-dir=/usr --with-zlib-dir=/usr --with-iconv --with-curl --with-openssl --with-mysqli --enable-soap --with-xmlrpc
Most of what eaccelerator does is works with PHP to cache processed scripts, and Moodle has no say in that.
On top of this, Moodle 1.8.x can take up a little more CPU than 1.6 did (because of new features), depending on your configuration. However Moodle 1.9 (final release is next week) has had a lot of optimisation work and is somewhat faster than 1.8 all around.
I would also make sure query caching is turned on in MySQL and slim down your PHP a lot ... do you really need all those modules taking up your memory?
moodle.org looks like this:
./configure --with-apxs2=/usr/sbin/apxs --enable-mbstring --with-libdir=lib64 --with-mysql=/usr --with-pear --enable-sockets --with-gd --with-jpeg-dir=/usr --with-ttf --with-freetype-dir=/usr --with-zlib-dir=/usr --with-iconv --with-curl --with-openssl --with-mysqli --enable-soap --with-xmlrpc