Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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:

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

Moodle Development Best Pracitces

  1. 1. Moodle Development Best Practices Presented by: Justin Filip
  2. 2. 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
  3. 3. 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)
  4. 4. Console editor - Emacs
  5. 5. IDE - Netbeans
  6. 6. 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
  7. 7. Best practices● Correct usage of plugins and APIs● Security● Performance● Testing● Coding style
  8. 8. Key concepts: Correct usage ofplugins and APIs
  9. 9. Correct usage of plugins and APIs● Key concepts: – Plugin types – Core APIs – Database system
  10. 10. Key concepts: Moodle plugins● – Activity modules – Authentication plugins – Blocks – Course formats – Enrolment plugins – Filters – Local plugins – Reports – Repository plugins – Themes
  11. 11. 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
  12. 12. Key concepts: database system●● Plugin specific documentation –● 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
  13. 13. Key concepts: Moodle core APIs● Access● Data manipulation (DML)● File● Form● Logging● Navigation● Page● Strings● Upgrade● Extra: data definition (DDL)
  14. 14. Correct usage of plugins and APIs:Summary ● Key concepts: – Plugin types – Core APIs – Database system
  15. 15. Security
  16. 16. Security● Key concepts: – Authentication – Roles and capabilities – User input
  17. 17. 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
  18. 18. 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
  19. 19. Extra: context hierarchy
  20. 20. 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
  21. 21. Extra: protecting access to your code● Command-line only scripts: – define(CLI_SCRIPT, true);● Preventing directly loading a PHP file: – defined(MDL_INTERNAL) || die();
  22. 22. Security: Summary● Authentication● Roles and capabilities● User input
  23. 23. Performance
  24. 24. Performance● Key concepts: – Database IO – Profiling
  25. 25. 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
  26. 26. 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. ●
  27. 27. 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● – Ignore everything before the How to use XHProf section
  28. 28. XHProf: summary data
  29. 29. XHProf: execution call graph
  30. 30. Performance: Summary● Database IO● Profiling
  31. 31. Testing
  32. 32. Testing● Key concepts: – Unit testing – Functional testing – Performance testing
  33. 33. Key concepts: unit testing● 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
  34. 34. 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 –● Moodle HQ Behat testing – – To be available for plugin authors as well as used in core Moodle
  35. 35. Key concepts: performance testing● Jmeter –● Stress testing● Simulates load from many concurrent users
  36. 36. Extra: Moodle Universal Cache (MUC)●● 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
  37. 37. Testing: Summary● Unit testing● Functional testing● Performance testing
  38. 38. Coding style
  39. 39. 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: –
  40. 40. Best practices: Summary● Correct usage of plugins and APIs● Security● Performance● Testing● Coding style
  41. 41. 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
  42. 42. Peer review checklist● Syntax● Whitespace● Output● Language● Databases● Testing● Security● Documentation● Git● Sanity check
  43. 43. Working with the Moodle tracker● Key concepts: – Creating new issues – Working on an existing issue
  44. 44. 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
  45. 45. 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
  46. 46. Maintaing a plugin with Github● Use correct repository name (see Moodle 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 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 –
  47. 47. Submitting core patches to HQ● Fork the Moodle Github repository –● 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 forums
  48. 48. Thank you● This presentation is available on SlideShare –● Find me on Twitter – @jfilip