The document outlines best practices for Moodle development, covering essential topics such as setting up a development environment, coding styles, security, performance, and testing. It emphasizes the importance of peer reviews and proper usage of APIs and plugins, while providing guidelines for maintaining plugins with GitHub and submitting patches to Moodle HQ. Key components include authentication, user input sanitation, and performance profiling techniques.

1. Moodle Development Best Practices
Presented by:
Justin Filip

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. 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. Console editor - Emacs

5. IDE - Netbeans

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. Best practices
●
Correct usage of plugins and APIs
●
Security
●
Performance
●
Testing
●
Coding style

8. Key concepts: Correct usage of
plugins and APIs

9. Correct usage of plugins and APIs
●
Key concepts:
– Plugin types
– Core APIs
– Database system

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

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

13. Key concepts: Moodle core APIs
●
Access
●
Data manipulation (DML)
●
File
●
Form
●
Logging
●
Navigation
●
Page
●
Strings
●
Upgrade
●
Extra: data definition (DDL)

14. Correct usage of plugins and APIs:
Summary
●
Key concepts:
– Plugin types
– Core APIs
– Database system

15. Security

16. Security
●
Key concepts:
– Authentication
– Roles and capabilities
– User input

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. 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. Extra: context hierarchy

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. 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. Security: Summary
●
Authentication
●
Roles and capabilities
●
User input

23. Performance

24. Performance
●
Key concepts:
– Database IO
– Profiling

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

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
●
http://techportal.inviqa.com/2009/12/01/profiling-with-xhprof/
– Ignore everything before the How to use XHProf section

28. XHProf: summary data

29. XHProf: execution call graph

30. Performance: Summary
●
Database IO
●
Profiling

31. Testing

32. Testing
●
Key concepts:
– Unit testing
– Functional testing
– Performance testing

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

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 – 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

35. Key concepts: performance testing
●
Jmeter
– http://jmeter.apache.org/
●
Stress testing
●
Simulates load from many concurrent users

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

37. Testing: Summary
●
Unit testing
●
Functional testing
●
Performance testing

38. Coding style

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:
– http://tinyurl.com/a9z9d8o

40. Best practices: Summary
●
Correct usage of plugins and APIs
●
Security
●
Performance
●
Testing
●
Coding style

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. Peer review checklist
●
Syntax
●
Whitespace
●
Output
●
Language
●
Databases
●
Testing
●
Security
●
Documentation
●
Git
●
Sanity check

43. Working with the Moodle tracker
●
Key concepts:
– Creating new issues
– Working on an existing issue

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

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

48. Thank you
●
This presentation is available on SlideShare
– http://tinyurl.com/a3w7m2f
●
Find me on Twitter
– @jfilip