I’ve spent the last months of workdays inside the source code and db structure of Moodle, an interesting e-learning platform. My first impression was confusion. Some of the code is procedural, some is object-oriented, some global variables are used, and the database is a forrest of related tables. The illustration below gives an idea of that. But it is a worthwile experience. I’ve learned to read and write Moodle, to modify it and expand it with custom plugins, to debug it and figure out what is going on even when the log files aren’t helping at all.
MESS VIEW CONTROLLER 🙂
Moodle has its upsides and downsides. Coming to it after the Model-View-Controller world of CodeIgniter based portals was a shock. It isn’t Model-View-Controller at all! I thought OMG everything is just all over the place. The logic was being mixed with presentation in ways that for me were absurd. I even searched the forums to understand more and found out that the Moodle coders don’t see changing this as a priority and aren’t interested in aggressive criticisms on this account (not that it ever came from me). So I just got used to it and moved on. Sometimes I still get irritated when I see how functions and classes and libraries seam put together to fit the purpose of the moment and not planned out for possible future uses. But I can’t be too harsh. Moodle was written for teachers, not for programmers, and it has made many valuable online courses possible and enriched learning experiences of so many people, and keeps to do so. So I humbly keep exploring it and being inspired by it, and hope to be able to contribute to it some day too. Probably soon.
In Moodle things happen in three basic places: the source code, the database and the moodledata folder. The database plays a huge role: it keeps it all together, “knows” all about the plugins and logs and users and their activities. The source code is complex and lego-like. The moodledata folder keeps files.
Click “Continue reading” for some detail.
THE SOURCE CODE
As with all web frameworks and platforms and CMS’s, the first thing to do is to download the source code. Then you create an empty database with a user that has privileges on it, an empty moodledata directory, and run the installation script which creates a config.php file.
Personalizing Moodle is a bit like playing with lego, or adding new pieces to a puzzle as you are composing it. If you want to make a change, the first thing is to figure out how Moodle already handles that type of activity you want to deal with. Then you decide what to do – write an enrol or auth plugin, ad a question type or a custom user profile field type, extend a class and override a function, or something else. Writing a plugin or extending a class is clearly, as always, favourable to editing the core files. If you want to add a new way of enrolling users to courses, you’ll write an enrol plugin similar to the ones provided by default and Moodle will make it available in the same way it does with other enrolment plugins.
The basic directory structure is somewhat complex, this is the listing for the 2.2 version:
admin – various procedures used by the administrator
auth – authentication plugins
blocks – blocks you can add to the layouts to present data to users
cohort – a type of user group
course – all the course related stuff, like organizing course contents on a page
enrol – enrolment to courses plugins
lib – all kinds of libraries, fundamental
local – place to put your plugins if there isn’t a better place for them (enrol, block or auth)
mod – all kinds of modules
theme – place where you customize the look and feel
user – user related stuff like profiles and custom fields
THE ROLE OF THE DATABASE
But knowing the code is not enough to work with Moodle, the database is fundamental. The db doesn’t only hold the contents such as the students and the course descriptions and such, but it also holds logs, traces of student activities, access control configurations, informations about plugins etc. It ties together the user and course activities and events, but also the platform system itself – the plugins and blocks and bits and pieces and roles and contexts. In fact when adding code for new plugins you have to also go to the admin home page so it gets installed and registered into the database so it can work properly. In order to work with the code you need to learn how the tables are related and which ids are foreign keys to other ids. You’ll need to figure out what needs to be modified to consider a course completed, or a user enroled, or a certificate released or deleted.
For example, the courses are found in mdl_course. Users in mdl_user. Modules are composed of modules (resources, activities, etc.) and these can be found in mdl_course_modules. Modules can be ‘completed’ like when a user successfully finishes a quiz, and this is kept in mdl_course_modules_completion. Each entry relates to a user, and to a course module, and keeps track of the completion state and modification time. There is a separate table that keeps track of users finishing whole courses, mdl_course_completion. And you also have to distinguish from modules in the abstract sense, in mdl_modules, and instances of modules for courses in mdl_course_modules. A lot of how Moodle works is based on this concept of instances. Things that happen in Moodle create “instances”, which are basically rows in database tables. I’ll likely get into more detail about this in future posts. You can also read more about it in Moodle documentation.
If some aspects of this interest you in particular, I would be very interested to read and answer your questions. Happy learning!