This was a Google Summer of Code 2007 Project.
This introduces two new files, admin/cliupgrader.php and lib/installlib.php.
It also introduces a new PEAR library, Console_GetOpt. I have recieved permission from the upstream author to include this in GPL Moodle (essentially dual license it) - notes in lib/pear.
Most stuff that outputs html during install gets suppressed by the use of a constant.
Run the script like php admin/cliupgrade.php --help for info.
Note that this all uses strings from install/ rather than lang, so I have updated stringnames.txt accordingly and they'll all be broken until the cronjob that generates them runs.
continue being used as previously until we finish all the required
DDL functions.
Also, this implies that *.sql files aren't needed anymore. Now all we have to do
is to maintain the install.xml files from the editor.
More cleanups to come from Ed.
This isn't actually working for me right now but he'll fix it now.
This is completely optional and won't affect any other code right now.
=======================================
WARNING: DEV IS CURRENTLY VERY UNSTABLE.
This is a mega-checkin of the new Roles system. A lot of changes have
been made in core and modules.
Currently there are a lot of rough edges and known problems. We are
working hard on these .. .the reason for getting this into HEAD at this
stage is enable us to move faster (our branch was diverging from HEAD
too much).
Please keep an eye on http://docs.moodle.org/en/Roles for current status
and information for developers on how to use the new Roles system.
Now blocks_have_content() caches instantiated block objects inside $pageblocks
and blocks_print_blocks() uses them if available. This behaviour now matches
the documentation: blocks instances are created only once, get_content()
may be invoked several times.
A better fix would be to cache the _output_ of the block (the ->content
property) but it may bite us if any block is counting on being called twice.
Discussion at: http://moodle.org/mod/forum/discuss.php?d=45867
and from blocks admin page and their instances haven't been deleted.
We should build some sort of check to do all the house-cleaning of "orphaned"
blocks, perhaps each time we arrive to the blocks admin page.
Per-block access controls for creating and editing block instances. Defaults
behave the same as before, and the framework has final say as before.
See relevant discussion at http://moodle.org/mod/forum/discuss.php?d=36444
Other minor changes: Converted "continue" to "break" inside switch statements
(more to the point, although equivalent), change erroneous (but harmless)
"return false" to "break" on failed addition of block instance, removed some
inline comments from block_base (they were duplicated in PHPdoc)
