Moodle Add-on Evaluations

During my second talk at the 2013 Canadian Moodle Moot in Vancouver, someone in the audience asked me about how my team at Remote-Learner evaluates Moodle plug-ins. We have a checklist that a developer must go through when trying to make a determination as to whether an add-on is suitable for installation on a Moodle site for one of our clients.

In general we will only disapprove a Moodle add-on if it fails for security reasons or it completely breaks some part of core Moodle functionality.

General

• Search forums and tracker for issues with the module.
• Check for recent updates or other indications of continuing maintenance.

Security

• Ensure that scripts call require_login() or require_course_login() somewhere near the top of user-accessible file.
• Ensure that capabilities are checked against the proper contexts using require_capability() or has_capability().
• Look in all scripts that have directly executable code - that is not just functions or class definitions.
  • Technique - use an IDE (Eclipse, Netbeans, Sublime Text, etc.) and open all files with folding enabled and “collapse all”.
• Ensure that all html parameters are retrieved using required_param() or optional_param() and never from globals.
• Ensure that the proper Moodle database calls (get_records(), get_records_sql()) are being used and that hard coded table prefixes aren’t.
• Search all code for occurrences of $_ and $HTTP for potential abuses.
• Ensure that the data type given to required_param() and optional_param() is appropriate for the data expected. If PARAM_RAW is used, ensure this does not get used in a db call.

Structure

• Ensure that proper plug-in structure is provided (i.e. /db/ and/lang/``` directories are used).

Moodle activity modules

• Ensure that the module includes the required files, API hooks, and database table as defined in the official Moodle documentation.
  • All of the above that are not met must be documented as some requirements are more important than others.
• Does the code require modification of any core files?
  • If so does it just contain the modified core files or does it contain patches or unmodified copies of the source files?
• Test the module on a local development site:
  1. Install the module on the site (record any warnings or errors).
  2. Add an instance of the activity module to a sample course.
  3. Backup and restore the test course to make sure that the module does not cause any errors during either part of the process and that the restored course contains the data from the module instance.

Moodle blocks

• Ensure that if the block is installing database tables that it is using the correct naming format for the database tables:
  • All of the block database tables must be prefixed with the block class name. So if the block class is called block_my_block then all of the database table names must start with block_my_block eg.:
  • block_my_block
  • block_my_block_table1
  • <code>block_my_block_table2
  • etc.

Special considerations

• If something modifies core code we need to evaluate the impact this will have, especially for ELIS clients.
• If there is cron code included, perform a test cron run to make sure it doesn’t break anything.