Moodle For Admins

Jason

Jason

— 5 min read
Moodle For Admins
Photo by Tim Gouw / Unsplash

If you've ever spent any time with Moodle as an admin, you'll probably appreciate the words of affirmation in this post. For those unfamiliar with Moodle, let me take a brief moment to paint the picture for you:

Moodle is an open-source Learning Management System (LMS). It's a mature platform that has been actively developed for 22 years now (as of this writing). Moodle is written in PHP and boasts a rather robust management system for users, courses, content, activities, and other college or learning related stuff.

However, what it does not do well is simple, straightforward management of the very things I mentioned. In my opinion, it's stuck between early 2000s web and modern web design trends because of its age. At some point, Moodle should have been rewritten from scratch rather than continue on building on top of systems and standards that have evolved over the length of its lifetime. But I digress...

The Problem

To put things into perspective, I have undertaken a project to build out a Moodle site for my church. They have 48 individual classes planned for, so this is not a light undertaking. The budget is low, the help is sparse, and the technical staff is me. This presents a little bit of a challenge. Central user management will need to be handled by Moodle, course management, student management, site management will need to be handled by me and delegated as applicable. As I said before, managing Moodle is not for the faint of heart. It does require a lot of learning (but not a course provided by my Moodle install 😂). After spending a long while updating course material, better understanding course lifecycle (still learning), user management, site management, etc. I realized that because of the previous era design, this seems much harder than it should be. Not every link you click in the admin control panel is useful or well laid out. Sometimes you click the word "edit," sometimes you click a pencil, and sometimes you go to a completely separate area. Sometimes the edit button takes you to micro-focused options. Sometimes the edit button takes you to macro-focused options.

Moodle API Woes

Moodle doesn't really have a true API. It does not conform to pure RESTful standards and everything is funneled through a single PHP script that handles the requests. A typical request might look something like this:

POST /webservice/rest/server.php?wstoken=YOURTOKEN&wsfunction=core_user_get_users&moodlewsrestformat=json HTTP/1.1
Host: yourmoodlesite.org
Content-Type: application/x-www-form-urlencoded

Which, if you haven't guessed at this point, is not RESTful. Thankfully, the responses are in JSON if you request it. This is hard to work with when dealing with API requests since you basically have to send URL encoded web requests every call.

My Plans

The plan here is I've already spent a considerable amount of time working on a dashboard system that integrates with Moodle WebServices and performs actions in a straightforward and expected way. Over the course of development I have come up with a tentative plan for development and thought I'd share where I want to develop for aspiring Moodle admins. It really breaks down into 3 distinct projects:

  • Moodle Dashboard (name TBD) - This will be the front-end that Admins will use to help manage their Moodle installations.
  • Moodle WebServices API Wrapper (name TBD) - A drop-in Python package that will allow you to make API calls like standard Python functions.
  • Third-party API gateway (name, you guessed it, TBD)- A way to allow third-party systems and services to conveniently access Moodle without extra setup in Moodle. For this I envision third-party services able to use the API gateway to tell your Moodle installation something happened (like new user payment and automatic course enrollment).

I currently have no plans to expand the dashboard to control course content creation. I feel like that is a problem currently not worth solving. With that said, here is a bit of detail about the expectation for each project.

Moodle Dashboard

This will be the core of everything I have been working on. It is a Python and Flask dashboard system that will allow low funds Admins to better manage their Moodle instances. It won't be a fancy React-based project. I'm not there yet with my React knowledge. The dashboard will have the following abilities and controls (in no particular order):

  • Course Control - Ability to perform manual enrollments, unenrollment, and view students/courses from an overview perspective. Eventually would like to extend this to pull reports by student or course.
  • User Control - Ability to suspend, send reset password links, edit user profiles, delete and create users.
  • Role-Based Access Control (RBAC) - Teachers will have access to courses where they are assigned. Admins will have access to everything. Students will not have access (for now).
  • Audit Logs -
  • OAuth2 provider (not implemented yet) - The Moodle Dashboard will be the authority for user accounts and provide API calls to Moodle to provision user accounts. The students will eventually have their own dashboard with basic user controls.

This is what I have have planned right now. As I continue to use Moodle I will probably want to add abilities to the dashboard.

Moodle WebService API Wrapper for Python

The API Wrapper has been a labor of love. It provides uniform access to the WebServices API without having to create a unique web request every time. Each function is set up to handle its unique parameters for the web request it will eventually make. A standard requests library call is made and the results are optionally cached through redis. Some of these calls can be very expensive if done in bulk, so redis is highly recommended. When I have done code quality control and placed a few more things into options, I will release this as a standalone resource to GitHub and figure out the process for setting up in PIP/UV package managers.

There is a tedious setup process for ensuring the API wrapper can work uninhibited. The admin will have to ensure a WebServices user is created in Moodle, it has the correct API access enabled, and it has the correct permissions in the user side of things. I will create documentation to go along with this so the setup process isn't too painful.

Third-party API gateway

This is the least realized part of the project yet. It will be a standalone service that the dashboard will integrate with, but run as an independent service. I want the API gateway to be something that third-party apps like payment gateways, auditing systems, or anything else an admin might want to hook up to Moodle in a sane way that doesn't involve writing PHP plugins and maintaining them for every update that happens on the Moodle side.

Theoretically, the API gateway will just be a middleware for third-party services. If something changes on the Moodle WebServices side, it can be handled by an update to the underlying gateway code. The API gateway will rely on modules that can be added for functionality. I realize this is similar to how Moodle already works, but without having to manage plugins for Moodle.

Wrapping Up

It's an ambitious project, but something I very much want to release into the wild considering how much setup Moodle already requires to make a functioning site. I want to abstract, at least in part, some of the overhead of managing and controlling a Moodle instance and organize some of the chaos.

Read more