You can now hide/show individual activity modules and even delete them completely!
For example, if you hide the "choice" module, then all choice activities
will be hidden throughout the whole site, and "Choice" will not
appear on any "Add..." menu.
Deleting a module is a complete deletion of all data from the database.
If you want to try out the deletion on a real module, I suggest the
pgassignment module, since it will soon be deleted from CVS anyway
(because it's being replaced with workshop).
Look for "Manage modules" on the admin menu.
Now these are saved in a new table called course_display,
each user and each course can have independent settings.
I'm intending to expand this table later for all the other
course display stuff (like hidden topics etc)
still producing too much data and overflowing PHP memory on busier
sites (eg moodle.org).
Now, there are more database queries, which is unfortunate, but the
data is much more specific, and no sorting needs to be done, so
this is a performance boost.
I don't know how these will cancel out ... my guess is that very
small sites may be very slightly slower on the course page, but
that large sites will be much faster.
Let's see.
Moved COURSE_TEACHER_COLOR out to style sheets where it belongs (.teacheronly)
Added some efficiency when printing recent activity
- don't print more than one weeks worth of updates
- don't keep re-parsing logs once they've been used
Course creators are managed by /admin/creator.php , same way that admins.
Or if authetication module have 'auth_iscreator'-function (right now only ldap-module have) ,
users are added to creators at login time.
Firstly, I'm replacing all use of old-style global variables like
$HTTY_REFERER with their new-style equivalent $_SERVER["HTTP_REFERER"]
Also using $_POST instead $HTTP_POST_VARS etc
Secondly, if gdversion == 0 (ie GD is not installed) then:
- users are not even allowed to upload new images
- graphs now just print a message instead of failing.
this allows Moodle to still be used even if GD is not present
Moodle tables.
ie user -> userid in many tables, plus in user_students
start -> starttime and end -> endtime
I've just done all this as carefully as I could ... I don't think
I missed anything but it's pretty intensive work and I'd be fooling myself
if I didn't think I'd missed a couple.
Note that this version should pretty much be able to bootstrap itself
using PostgreSQL now ... but this is untested
Basically all the Database functions are in lib/datalib.php
and the web functions are all in lib/weblib.php, so
moodlelib.php is much thinner than it was.
Data functions have been extended ... most old calls will
still work, but now many more SQL commands can be performed
using the datalib functions rather than using SQL. I'm
currently moving through the whole tree replacing SQL
calls or at least concentrating them in one section of
mod/xxx/lib.php
Still working on forums, quizzes, surveys, resources.
The tree is currently not full working ... some things are
half-completed ... will resume tomorrow.
