Moodle

In my quest to make Moodle as easy to use and as efficient as possible, I’ve made two changes to the Login Page.

Reorder Login Fields

The first thing that I did was to reorder the Login fields. Generally, we want users to use the Login with Google button. Thus, I want this the topmost option.

I’ve already written this up, so suffice it to say that putting the best option first is important.

Button Color

Changed the button color of the Google Login button. Added the following code to the RAW SCSS intial field:

a.btn.login-identityprovider-btn.btn-block {
background-color:#ffff00;
}

Note that the color (#ffff00) is a bright yellow.

Summary

I’ve added the following code to the CSS portion of our Moodle theme:

.loginform {
display: flex;
flex-direction: column;
}

login.login-form

{
order: 2;
}
.login-identifyproviders
{
order: 1;
}
a.btn.login-identityprovider-btn.btn-block {
background-color:#ffff00;
}

This accomplishs my goals of highlighting the action that I want my participants to take.

More and more schools are transitioning to using Oauth for logins. Moodle allows for Oauth logins. However, by default, the Moodle Login box appears first, above the button to login using a service.

This causes lots of people to enter their credentials into the box. In our case, they are entering the “wrong” credentials (i.e. they enter their Google username and password instead of their district account username and password). This leads to frustration on the end user’s part. Signing in is a really bad place to frustrate users.

Knowing that Moodle is customizable, I know there has to be a way to fix this. A little bit of research leads to a couple of different options:

• customize the CSS
• use a Plugin

I start with the plugin (Login Splash Page). However, upon installing it, I realize that I need to redirect the login page. I decided that I’d rather not do that.

I found a couple of posts with ideas to customize the CSS. The best of which was a post by Steven A. Although the post says that you have to account for each section, my attempts didn’t support that.

I opened our Login page and right-clicked on it to select “Inspect”. This allowed me to verify the different elements present. (Plus, you can drag them around to change the order, which is useful and kind of cool). Anyway, I could now be sure what the name of each element was. Since the post indicated that you needed to account for all of the elements, I did so. However, the elements still didn’t appear in the order that I wanted. So, back to BBedit (where I had entered the appropriate code). I deleted everything but the two elements and Ta-Da!

In the end, I put the following code:

.loginform {
display: flex;
flex-direction: column;
}

login.login-form

{
order: 2;
}
.login-identifyproviders
{
order: 1;
}

into the SCSS Raw box in the theme that we. That is, in Moodle, I went to :

• Site Administration | Themes | LearnR | Look
  then clicked on the SCSS tab. I entered the code above into the “Raw initial SCSS” box, scrolled down, and clicked “Save”. (*Note that this needs to be done for each Theme that you use if you use more than one. Or, if you change themes in the future, this must also be updated in that theme.) Now, end users will see the Login with Google Button first.

Whew!

Given the prevalence of utilizing Oauth, I hope that someone at Moodle will make this a checkbox preference in the future. However, at least for now, this is set for me.

On Friday, I upgraded Moodle as the newest version fixes an issue with the Lesson Module. Great. Except, the site crashed during the upgrade cycle.

Great! Time to do some research. I headed over the Moodle Forums to see if this was a known issue. Yep. Yep, it is. That led to a Bug Report. Here I got enough information to get some things running again. I tried deleting different plugins, and adding them back in. No full fix, but I had access to my site.

Then, I flew too close the sun. I used the “uninstall” link from the Plugins Overview page, and broke everything.

Drats.

I’ve been able to return access to my site. I don’t have everything fixed yet though.

I found an article on enabling “disable auto update” while installing. This involved uncommenting out a specific command in .config.php file. For me this was line 457:

$CFG->disableupdateautodeploy = true;

It is commented out. By uncommenting it (removing the //), it has allowed by site to update.

After doing this, I can uninstall plugins from the Plugins Overview page.

By deleting the // at the beginning of the line (those symbols comment out the line, which means that the program won’t run that command), the command is active and, tada!, I can complete the upgrade process.

So, a partial fix. I can now uninstall plugins, but I can’t install them. I’m going through to uninstall plugins that could be the problem, but I’m not completely convinced that this is going to solve the problem. At least the site is back up and available.