POET Plugin Review Guidelines

POET Plugin Review Guidelines

Evaluation process

Is it a Moodle Plugin?

  • Is it one of the many Moodle plugin types? If not it's an automatic no.

  • Is it in the Moodle Plugin Database? If it is, it has already passed the plugin validation tests that make it valid to be in the database. If not, it will need these tests.

  • Ensure that proper plug-in structure is provided - 'db' and 'lang' directories.

  • YUI modules written for Javascript (not necessary, should be a warning only)

  • Ensure that the plugin includes the required files, API hooks, and database tables as defined in the official Moodle documentation for that plugin type.

  • Ensure that there are no required core code changes.

Does it Follow the Coding Guidelines?

Moodle has detailed coding guidelines that should be followed as closely as possible. These guidelines describe structure, naming convention, style and testing rules as well as others. Look for obvious violations, or consider running it through the code-checker plug-in.

Is it Secure?

Moodle has strict security guidelines to make code secure. Ensure that the code is following these.

Specifically,

  • User Authentication - ensure that scripts call require_login or require_course_login somewhere near the top of web-accessible scripts.

    • Look in all scripts that have directly executable code - that is not just functions or class definitions

    • Technique - use an IDE, like Eclipse, and open all files with "folding" enable and "collapse all".

  • User Permissions - ensure that capabilities are checked against the proper contexts using require_capability or has_capability.

  • Clean User Input - ensure that all html parameters are retrieved using either using required_param or optional_param, or from moodleforms, and never from globals such as $_GET, $_POST or $_REQUEST.

    • 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.

    • If moodleforms is being used, ensure that data_submitted and confirm_sesskey functions are being used correctly.

  • Clean Data for DB Storage - ensure that the proper Moodle database calls (e.g. update_record, insert_record, get_record) are being used and that hard coded table prefixes are not used.

  • Clean Data for Output - ensure proper use of Moodle output functions, such as format_string and format_text before any data from user input or the database is output to the screen. If using forms, use proper setType form calls.

Does it Perform Well?

Performance can be hard to measure. Code that runs well when tested in development environments, might not do so well in a large or heavily used system. Moodle provides some good performance and scalability guidelines to consider when you create your plug-in. Specifically, look for:

  • Use of get_records* instead of get_recordset*. If the data returned from a get_records call has the potential to be large, it should be written as a get_recordset call instead.

  • DB operations within loops (especially writes). This can indicate database activity that could be optimized better. JOINS and subqueries could improve database operations in loops.

  • events_trigger calls within a loop. These functions often have database operations in the handlers, and there can be many handlers, causing a cascading performance issue.

Does it Pass Basic Functional Testing?

Run the plugin through some basic functional testing on a Moodle site and verify its functionality. Make sure when this is done, that full developer Moodle debug output is enabled, to capture any errors or warnings.

  • Install the plugin new. Does it install without problem?

  • If there is a setup function, does it work properly?

  • If a new version of this plugin has been released, does it upgrade properly from older versions?

  • Can you add the plugin to its proper Moodle context (e.g. block to a page, module to a course, etc)?

  • Try and use it for its intended purpose. Any problems?

  • Can it be backed up and restored with a course backup properly?

  • Can you remove the plugin from the context it was added to without problem?

  • Can you delete the context with the plugin added (e.g. delete a course with a module plugin in it)?

  • If the plugin has cron functions, do they work properly when the Moodle cron runs?

  • Can you delete the entire plugin from the site?

Other Considerations?

  • Is it being maintained by a reliable source? For example, someone from HQ? Another Moodle Partner? A known, reliable Moodle user? A third party with a vested interest in its continuation? Check for recent updates or other indications of continuing maintenance.

  • How reliable and stable is it? Search forums and tracker for issues with the module.


Last modified: Monday, 27 July 2015, 4:31 PM