Out-of-the-box, Moodle’s default user interface is pretty gregorian, and by that I mean old-fashioned. As soon as you log in, no matter what kind of user you are, you see the same thing: A list of the courses that you are enrolled in. That’s the only power that Moodle gives the front page: You only see the courses that only you are enrolled in.

In this day and age of using websites for content management, that’s sort of like booting up your computer and being met with the command line instead of a desktop. So from the get-go I set out to change all that, instead of simply making the different courses you’re enrolled in the default “view” when you log in to Moodle, instead you are presented with some text that indicates your role at the school (e.g. “Secondary teacher”, “High School Student”) and be presented with portal-like links to commonly used tools and features, like so:

First, the menus

To get to that point, though, the first thing to solve is what to do about the list of courses, because users will very, very often have to get themselves there. In the portal image above, they could opt to click “My DragonNet” which is just the “My Moodle” feature, and by default they get a list of courses that they can click on. However, I also wanted to provide a menu that followed them everywhere they went. Hence, a menu called “Teaching & Learning”:

Notice how the “Teaching & Learning” menu contains the list of courses? Also notice that there are other menus, like “Navigate,” “Activities” and so on? That’s because we’re using Moodle beyond just providing a Learning Management System, we’re also using it for managing content, and providing some administrative functions. In other words, the traditional use of Moodle, which gives users a bunch of classes to participate in, has been codified into a single menu, which, combined with the portal-like buttons, provides a very different impression when the user logs in:

The only part of that front page that I have yet to point out is the notification box sitting between the header and the buttons, which I elaborate upon in the last section below. What’s most notable about that, though, is we can put up announcements, either for everyone, or just for secondary teachers, by adding the appropriate content. Sweet.

Redirect

So, getting back to the whole implementing the portal thing… how did I get it so that users are presented with different things upon login. Did I rework the Moodle codebase, adjust the database, or some other black magic? No, I went with the simplest and most obvious solution.

I just wrote a few if statements in

/index.php

code that checks to see what cohorts the user is logged into, and throws them to the right course. In other words, there are courses set up just for log in purposes, and Moodle redirects them to the right place, depending on which site-wide group they have been enrolled in.

First I set up the variables I need:

$sec_teacher_cohort = $DB->get_record('cohort', 
           array('idnumber'=>'teachersSEC'
    ))->id;
$frontpage_course_id = 1395;  // DragonNet Frontpage

I do that after all of the Moodle-defined checks for updates, which for Moodle 2.5 at the time of writing means I start this code at line 72. Now, you could set it so that each kind of user has its own course, which is actually what I did in the first iteration. But then I realized that what I really wanted was for them to be redirected to a different sub-section of the same course. So, using topic format, I can simply pass the redirect function a section identifier, like so:

if (cohort_is_member($sec_teacher_cohort, 
                  $USER->id)) {
    redirect($CFG->wwwroot . 
        '/course/view.php?id='.
        $frontpage_course_id.
        '&section=7');
    }

This works like a charm, assuming that you have your users enrolled into the right cohorts, right? Probably shouldn’t assume that without some thought to it. So, we should check to ensure that the user has access to the course it’s about to redirect to, but I decided against that. For one thing, I didn’t enjoy the thought of hitting the database that hard for a simple redirect. Besides — and this is the main thing —behind the scene, I’ve guaranteed that users are enrolled into the right cohorts with a script that I’ve prepared behind the scenes that does all the hard work. I’ll have to explain that bit in a subsequent article.

So, all that’s left is to define the cohorts, which is a simple matter of using the Cohorts GUI provided in Moodle’s through-the-web administration.

Last bits

What about the buttons? That part is really easy. I just use html buttons,  fontawesome.io for the icons, and a bit of CSS I’ve defined in the theme.

As for the notification system, those also deploy a bit of CSS:

.dnet-notification {
    margin-left:150px;
    margin-right:150px;
    margin-bottom:10px;
    padding: 15px 20px 15px 20px; 
    background-color: #fff; 
    border-top: 2px solid #4D63A3; 
    border-bottom: 2px solid #4D63A3;
}

What is not so obvious, though, is what to do about the “Frontpage” course that I’ve created. I don’t want that course to appear in the menus system, so much, because “Home” is what they ought to think of it as being, and not “Dragonnet Frontpage” or whatever. So, what I did was make an “Invisible” course category, and my theme skips it whenever it encounters a menu with that name. Funnily enough, I use the Invisible menu for loads of things that I want to hide from the user.

Speaking of making the Frontpage function as “Home”, we have to take a close look at the breadcrumbs. Without further modification, when the user finds himself at the front page, the breadcrumb will state “Home -> Frontpage”. Overriding the navbar function in the theme, and putting the appropriate line to skip it, does the trick nicely:

if ($item->title === 'DragonNet Frontpage') { continue; }

Voila, we have a fully functional portal system set up for Moodle. When users log in, they jump to a page that is formatted just for them. To get to their courses, they have two ways, a la the menu or the big juicy button system.