Moodle Developers Quick Reference

From MoodleDocs
Revision as of 05:06, 7 June 2013 by Marina Glancy (talk | contribs) (Created page with "This is work-in-progress! Welcome Moodle Developers. So you don't get scared by many APIs and entities Moodle has here is a quick reference for you. === User === Global variab...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This is work-in-progress!

Welcome Moodle Developers. So you don't get scared by many APIs and entities Moodle has here is a quick reference for you.


Global variable $USER contains information about current user. Useful functions: isloggedin(), isguestuser(), session_is_loggedinas(), require_login()


Useful functions: is_siteadmin()


Course category


Frontpage in Moodle is a course with id SITEID. Also this is the only course that does not have a parent category. The actual "Home" page may be redirected to /my/ or user preferences. The word "frontpage" in Moodle refers to the actual page /index.php

Frontpage course assumes that everybody is automatically enrolled in it.



Artificial but very important entity in Moodle that allows to treat different spaces similarly. Depending on property contextlevel in may refer to: system, user, course category, course, module or block instance. Each context is uniquely identified either by id or by combination of contextlevel+instanceid. Each context have parent context(s). System is top-most parent context for anything. Course is the parent context for it's modules, etc.



Role is a set of capabilities that can be assigned on certain context level. There are default roles created when Moodle is installed but names and ids or roles are not fixed and admin can create new or delete existing. Roles are mostly used as UI for admins to assign capabilities except for special cases, such as participants lists or course contacts.

Role archetypes (authenticated user, student, editingteacher, etc.) are used by plugins to set the default capabilities set on install/upgrade.


Capability is the permission granted to the user to perform particular action in particular context. Capabilities are inherited from the parent context i.e. in a module from course, in course from course categori(es), unless user have a role in child context that prohibits particular capability from parent context.

Developer usually does not need to know which roles the user has but it always need to check if user has the proper capability. Useful functions has_capability(), has_all_capabilities(), has_any_capability(), require_capability()


Please note that from DB or development point of view enrollments are not connected with roles and capabilities. User may have capabilities inside the course but not be enrolled and vice versa. Enrollment is the separate entity connecting user to the course. Function require_login() with course argument will check that user is enrolled in the course (note, everybody is enrolled in frontpage course, in many checks including require_login() admins are considered to be "enrolled")


Output renderers

Settings and preferences

Stored files

Database operations