• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Moodle Development Best Pracitces

Moodle Development Best Pracitces



Learn about best practices for developing Moodle code from custom plugins to submitting bug fixes for core Moodle code. Topics covered will include: ...

Learn about best practices for developing Moodle code from custom plugins to submitting bug fixes for core Moodle code. Topics covered will include:

Overview of Moodle plugin systems and available API's
Working with the Moodle tracker
Peer review process
Maintaining a custom plugin using Github
Submitting core patches / bug fixes to Moodle HQ



Total Views
Views on SlideShare
Embed Views



18 Embeds 3,986

http://www.scoop.it 2324
http://jfilip.ca 781
http://cidspotlight.wordpress.com 401
http://www.moodlenews.com 290
http://moodletuts.com 75
https://twitter.com 48
http://kineo.learningzone.me 29
http://ec2-54-213-144-225.us-west-2.compute.amazonaws.com 15
http://translate.googleusercontent.com 6
http://feedly.com 4
http://thinkup.jfilip.ca 4
http://rcollop.jfilip.ca 2
https://cidspotlight.wordpress.com 2 1
http://www.365dailyjournal.com 1
http://webcache.googleusercontent.com 1
http://hetsorg.tumblr.com 1
http://www.symbaloo.com 1



Upload Details

Uploaded via as OpenOffice

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.


14 of 4 previous next Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • @corestaples It's called Behat. Here is the forum post from David at Moodle HQ who has been working on this which also includes a link to the-very detailed-instructions on the MoodleDocs wiki -- https://moodle.org/mod/forum/discuss.php?d=221638
    Are you sure you want to
    Your message goes here
  • Justin, what was the plugin you mentioned the uses plain english for testing with Selenium? It starts with an 'H' I believe. Thanks
    Are you sure you want to
    Your message goes here
  • Great presentation, Justin. Very informative.
    Are you sure you want to
    Your message goes here
  • I have updated this presentation to fix the missing slide in the testing section and the problems with two slides being copies of each other for the start and end of the performance section.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Moodle Development Best Pracitces Moodle Development Best Pracitces Presentation Transcript

    • Moodle Development Best Practices Presented by: Justin Filip
    • Presentation outline● Intro / development environment● Best practices● Peer reviews● Working with the Moodle tracker● Maintaining a plugin with Github● Submitting a core patch to Moodle HQ
    • Development environment● Web server: – Apache – Lighttpd – Nginx● Database server: – MySQL – PostgreSQL● PHP (5.3.2 or later for Moodle 2.2)● Code editor: – Console (vim, Emacs) – IDE (Eclipse, Netbeans, Sublime Text)
    • Console editor - Emacs
    • IDE - Netbeans
    • General development settings● Enable developer debugging from Debugging section of the Development section of the Site administration menu● If working with real user data, prevent emails from being sent out by adding $CFG->noemailever = true; to your config.php file● If working on theme / CSS changes, enable Theme designer mode from the Theme settings section of the Site administration menu – Important! Do not leave this setting enabled on production sites as it has a large performance hit
    • Best practices● Correct usage of plugins and APIs● Security● Performance● Testing● Coding style
    • Key concepts: Correct usage ofplugins and APIs
    • Correct usage of plugins and APIs● Key concepts: – Plugin types – Core APIs – Database system
    • Key concepts: Moodle plugins● http://docs.moodle.org/dev/Plugins – Activity modules – Authentication plugins – Blocks – Course formats – Enrolment plugins – Filters – Local plugins – Reports – Repository plugins – Themes
    • Extra: Moodle 2.3 plugin changes● Assignment module – /mod/assign/submission/ – /mod/assign/feedback/● Repository plugins – Support for alias / shortcut to external content – supported_returntypes() should add FILE_REFERENCE to the return values to indicate this
    • Key concepts: database system● http://docs.moodle.org/dev/Data_definition_API● Plugin specific documentation – http://tinyurl.com/a3gvpjj● Always use a primary key column called id● Add indexes and foreign keys to your database tables● If writing full SQL queries make sure to put table names within braces without the prefix – {assignment_submissions} instead of mdl_assignment_submissions● Use the built-in XMLDB editor in Moodle for managing your XML install files
    • Key concepts: Moodle core APIs● Access● Data manipulation (DML)● File● Form● Logging● Navigation● Page● Strings● Upgrade● Extra: data definition (DDL)
    • Correct usage of plugins and APIs:Summary ● Key concepts: – Plugin types – Core APIs – Database system
    • Security
    • Security● Key concepts: – Authentication – Roles and capabilities – User input
    • Key concepts: authentication● How users get into the system● Can connect to external systems: – Problems if that system is unavailable – SSO & SSI● Confirming users and deletion
    • Key concepts: roles and capabilities● Context levels: – CONTEXT_SYSTEM, CONTEXT_COURSE, CONTEXT_USER, etc.● Roles: – Definitions – Applicable contexts● Capabilities – Use the most specific capability possible – Check in the most specific context level
    • Extra: context hierarchy
    • Key concepts: user input● Never ever trust user input!!! – Common web application problem – Always sanitise input data – required_param() & optional_param() – required_param_array() & optional_param_array()● Input parameter types: – PARAM_ALPHA, PARAM_ALPHANUM, PARAM_NOTAGS, PARAM_CLEANHTML – PARAM_EMAIL, PARAM_URL, PARAM_SAFEDIR● Moodle form API (formslib) and SESSKEY validation
    • Extra: protecting access to your code● Command-line only scripts: – define(CLI_SCRIPT, true);● Preventing directly loading a PHP file: – defined(MDL_INTERNAL) || die();
    • Security: Summary● Authentication● Roles and capabilities● User input
    • Performance
    • Performance● Key concepts: – Database IO – Profiling
    • Key concepts: database IO● Limit returned dataset using $fields parameter● Use result set paging with $limitfrom and $limitnum● Use record sets to not load all returned data into memory● Writing custom SQL queries – Database agnostic – Caution when using JOINs and subqueries
    • Key concepts: profiling● Use good testing data – Try to use a large dataset – If at all available, use a copy of data from a production site ● Set $CFG->noemailever = true; in your Moodle config.php file – Enable performance output on each Moodle page ● Displays execution time, memory usage, DB read / write, etc. ● http://tinyurl.com/axkuqjz
    • Key concepts: profiling with XHProf● Facebook-developed live profiling of PHP code● Built into Moodle● Quantitative analysis of results from a page execution● Pin-pointing performance problems● Critical execution path● http://techportal.inviqa.com/2009/12/01/profiling-with-xhprof/ – Ignore everything before the How to use XHProf section
    • XHProf: summary data
    • XHProf: execution call graph
    • Performance: Summary● Database IO● Profiling
    • Testing
    • Testing● Key concepts: – Unit testing – Functional testing – Performance testing
    • Key concepts: unit testing● PHPUnit – https://github.com/sebastianbergmann/phpunit/● Testing single functions and methods in isolation● Added to Moodle core in 2.3.0● PHPUnit tests menu in the Development section of the Site administration menu contains more information how to setup and use them● See examples from other core code and plugins
    • Key concepts: functional testing● Testing interaction with your code via web browser or a simulated web browser● Can be used to find UI display problems across multiple browsers / OSs● Selenium – http://seleniumhq.org/● Moodle HQ Behat testing – https://moodle.org/mod/forum/discuss.php?d=221638 – To be available for plugin authors as well as used in core Moodle
    • Key concepts: performance testing● Jmeter – http://jmeter.apache.org/● Stress testing● Simulates load from many concurrent users
    • Extra: Moodle Universal Cache (MUC)● http://tinyurl.com/by7gs3p● A generic caching system that any code can use● Can plug into different back-end caching systems● Introduced in Moodle 2.4.0● Available to add-ons now, core components to use it in Moodle 2.0
    • Testing: Summary● Unit testing● Functional testing● Performance testing
    • Coding style
    • Coding style● More about how you write your code, not necessarily what you write● Consistency allows for familiarity when looking at new areas● Can prevent “bad” or sub-optimal code from being released● CodeChecker plugin: – http://tinyurl.com/a9z9d8o
    • Best practices: Summary● Correct usage of plugins and APIs● Security● Performance● Testing● Coding style
    • Peer reviews● Attempt to find problems before testing● Ensure consistency in new code● Make sure required information is present and correct● Teaching tool for new developers● Enforces style and correctness of solution● Verify that new code is not using deprecated functionality
    • Peer review checklist● Syntax● Whitespace● Output● Language● Databases● Testing● Security● Documentation● Git● Sanity check
    • Working with the Moodle tracker● Key concepts: – Creating new issues – Working on an existing issue
    • Key concepts: creating new issues● Always make sure to see if the issue you want to create already exists● Make sure to report as much information as possible – Affects Version/s – Database – Testing instructions – Workaround● Important! Always include debugging messages and screenshots if reporting a bug
    • Key concepts: working on an existing issue● Make sure nobody is working on it already● Put in a comment to ask for the issue to be assigned to you● Put your work in a publicly available Git repository and provide this information in the issue● Make sure that you provide testing instructions for your work● Request peer review when your work is finished
    • Maintaing a plugin with Github● Use correct repository name (see Moodle Frankenstyle) – http://docs.moodle.org/dev/Frankenstyle● Create branches for supported Moodle versions (e.g. MOODLE_23_STABLE, MOODLE_24_STABLE)● Provide documentation in the MoodleDocs wiki● Submit the plugin to the Moodle.org plugins database● Keep track of bugs and new features in the official tracker – Request a component be created for your plugin in the Non-core contributed modules project – http://tinyurl.com/b7xc7nv
    • Submitting core patches to HQ● Fork the Moodle Github repository – https://github.com/moodle/moodle● Create branches for affected versions● If this is for an existing issue, post the information for your repository into the issue● If this is for something new, create a new issue and start a discussion in the Moodle.org forums
    • Thank you● This presentation is available on SlideShare – http://tinyurl.com/a3w7m2f● Find me on Twitter – @jfilip