Administration hacks

Jump to: navigation, search

Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Administration hacks.

Here are some hacks or tweaks to Moodle code that administrators have found useful on their sites to fill specific needs.

Approve account creation by self-registration before the new user gains access

In /lib/moodlelib.php, search for the function send_confirmation_email. Change this line of the function (around line 4339 in 1.9.1+):

   return email_to_user($user, $supportuser, $subject, $message, $messagehtml);

to:

  return email_to_user($supportuser, $supportuser, $subject, $message, $messagehtml);

The confirmation e-mail is sent to the administrator (and not to the new user). Checking the list of user accounts (as Admin on the site), there is link to confirm the account (edit/delete/confirm). Once this is done the administrator can forward the e-mail to the new user (but the account is already approved). (1)

Send a duplicate of the registration email to the administrator

(Moodle 1.8) In /lib/moodlelib.php, search for the function send_confirmation_email (around line 3629 in 1.8.4+). At the end of the function there is a line that reads (2):

  return email_to_user($user, $from, $subject, $message, $messagehtml);

Just before that line, add a line like this:

  email_to_user($from, $from, $subject, $message, $messagehtml);

(Moodle 1.9) In /lib/moodlelib.php, search for the function send_confirmation_email (around line 4468 in 1.9.4+). At the end of the function there is a line that reads:

  return email_to_user($user, $supportuser, $subject, $message, $messagehtml);

Just before that line, add a line like this:

  email_to_user($supportuser, $supportuser, $subject, $message, $messagehtml);

Set default course blocks rather than using sticky blocks

In moodle/config.php, change lines 20-25:

Find the defaultblocks_topics line and replace with this. Also change the string for defaultblocks_weeks. Don’t change social though (3).

  $CFG->defaultblocks_topics = ‘course_menu,myCourses:activity_modules,calendar_upcoming,quickmail’;
  $CFG->defaultblocks_weeks = ‘course_menu,myCourses:activity_modules,calendar_upcoming,quickmail’;

Turn quickgrade on as default, increase default number of assignments shown to 20, and remove instructor from the list

In moodle/mod/assignment/lib.php, change line 682 (3):

  $perpage = get_user_preferences(’assignment_perpage’, 20);

In line 684:

  $quickgrade = get_user_preferences(’assignment_quickgrade’, 1);

In line 982:

  $teacherattempts = false; /// Temporary measure

Increase the number of course summaries displayed before going to collapsed mode in category view

The following change was made in course/lib.php. Line 13 should read (3):

  define(’COURSE_MAX_SUMMARIES_PER_PAGE?‘, 25); // courses

Allow admins to edit posts after closing

In moodle/config.php file, add the following two lines (3):

  // Setting this to true will enable admins to edit any post at any time
  // $CFG->admineditalways = true;

except uncomment the second line (remove the two slashes):

  // Setting this to true will enable admins to edit any post at any time
  $CFG->admineditalways = true;

This is now in moodle/config-dist.php and just needs uncommenting

Change the default course settings to create topic courses instead of weekly courses

In course/edit.php, change line 98 (3):

  $mform->setDefault(’format’, ‘weeks’);

to:

  $mform->setDefault(’format’, ‘topics’);

If you wanted to, you could change the default number of topics/weeks in a course. Change line 104 in this same file according to your needs:

  $mform->setDefault(’numsections’, 10);

Increase shortname field length in the course request form and the course creation form

In moodle/course/edit_form.php, change line 72 (3):

  $mform->addElement(’text’,’shortname’, get_string(’shortname’),’maxlength=”25″ size=”25″‘);

In moodle/course/request_form.php, change line 13:

  $mform->addElement(’text’, ’shortname’, get_string(’shortname’), ‘maxlength=”25″ size=”25″‘);

Access courses with a permanent user friendly URL

The idea is to access a course with a user friendly URL instead of the usual cryptic way. In this example we will propose URLs for courses based on their short names, in the form:

http://moodle.some.where.org/pages/SHORTNAME

where SHORTNAME is the exact name defined on the course settings (case sensitive).

There are, however, some limitations on the characters that can be used to achieve this due to URL special characters. In this example the allowed set of characters is [ A-Z a-z 0-9 - _ . @ ].

So you have to change apache configuration in the global or VirtualHost section:

  RewriteEngine on
  #uncomment the following two lines if you want to debug
  #RewriteLog "/var/log/httpd/rewrite.log"
  #RewriteLogLevel 9
  
  #pages@moodle
  RewriteRule ^/pages/([A-Za-z0-9\-\_\.\@]+)/?$ /course/view.php?name=$1 [R,L]
  RewriteRule ^/pages/ / [R,L]

Prevent "Welcome to course" emails

Note: Since 1.9.3 it is possible to disable welcome messages from the enrolment configuration page: Courses->Enrolments->"Send course welcome message"

In earlier versions of Moodle, you can stop moodle sending enrolment emails by changing two lines in the file /enrol/enrol.class.php(4).

The line (occuring twice in the file!) reads:

      email_to_user($USER, $teacher, $subject, $message);

It must be changed to:

      //     email_to_user($USER, $teacher, $subject, $message);

That way, moodle ignores the e-mail-command until you change back to the original line. The setting works for all courses at the same time. It does not affect other e-mails being sent (e.g. the login confirmation).

Display Performance Info to admins only

Moodle can be set to display some useful performance information in the footer (Site Administration -> Server -> Debugging -> Performance info), but sometimes you may not want users to see this information on a production site. Follow these steps to only display this information to administrators:

  • Using your editor, open the file /lib/weblib.php and search for the first occurrence of the text $performanceinfo = ; (around line 2957).
  • Add this text as the next line
if ($CFG->adminonlyperfinfo and isadmin()) {
  • Look further down the code a few lines for the last brace character (}) and add an extra one on its own. Your text should now look like this (the added lines are shown in bold):
/// Provide some performance info if required
$performanceinfo = ;
if ($CFG->adminonlyperfinfo and isadmin()) {
if (defined('MDL_PERF') || (!empty($CFG->perfdebug) and $CFG->perfdebug > 7)) {
         $perf = get_performance_info();
         if (defined('MDL_PERFTOLOG') && !function_exists('register_shutdown_function')) {
             error_log("PERF: " . $perf['txt']);
         }
         if (defined('MDL_PERFTOFOOT') || debugging() || $CFG->perfdebug > 7) {
             $performanceinfo = $perf['html'];
         }
     }
}
  • Save the file /lib/weblib.php
  • Edit your moodle/config.php file and add the line
$CFG->adminonlyperfinfo = true;

This sets the flag to make the code display the performance info only for admins.

Login Securely with Admin Account even without "true" HTTPS support

On the Powweb commercial web server I use for Moodle, HTTPS is supported. However, the server has a security certificate marked *.powweb.com which earns a complaint from the browser that the certificate doesn't match. Since I do not have control of Apache on this commercial hosting service, it wasn't obvious to me how to have it serve a certificate with my web site's name instead of Powweb's.

(You can get certificates from a number of places, including free ones. Those services describe how to deploy the certificate on your server if you have control of Apache.)

My desire was to avoid a web sniffer in my classroom from eavesdropping on my admin password. So I simply bookmarked this address to manually enter my admin login: https://www.mymoodlesite.org/login/index.php

The obvious solution is to enable HTTPS support in Moodle for the login pages. The drawback to that is that all my students would then be confronted with the certificate warnings, leading to continuous confusion. I would be forced to figure out how to implement authentic certificate support.

The first time I used this "forced HTTPS" hack the browser complained that the certificate was in all probability a fake one. I overrode that complaint so the browser would accept the "wrong" certificate henceforth.

I have verified this security measure with the free sniffer program SmartSniff. I monitored the packets with regular HTTP and HTTPS and found that HTTPS successfully encrypts my login page so spies presumably cannot determine my admin login.

References

  1. Discussion forum in moodle.org: Admin approving self registrations?
  2. Discussion forum in moodle.org: Self registration with validation
  3. Blog post: Republishing favorite Moodle hacks by A. Wyatt
  4. Discussion forum in moodle.org: Stopping "Welcome to the course" emails