Dan Poltawski Integrator Moodle HQ How to guarantee your change is integrated to Moodle core @dan_p
How to guarantee your change is integrated to Moodle core
May 19, 2015
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Dan PoltawskiIntegrator
Moodle HQ
How to guarantee your change is integrated to Moodle core
dan_p
Who am Ibull Core developer in Moodle community since 2005
bull Worked with schools universities and businesses around UK
bull Moved to Australia and joined Moodle HQ in 2012 as an Integrator and Developer
bull Since joining HQ irsquove spent a lot of my time complaining about the price of beer in Perth
$10pound7euro8
(httpwwwquoracomBeerDoes-Perth-Australia-have-the-most-expensive-beer-prices-in-the-world)
Who am IIrsquom also part of the Integration Team
bull Experienced group of Moodle developers at HQ who act as the final lsquogatekeepersrsquo
bullConducting final checks before code makes it into Moodle release
bullBring historical context and try to facilitate communication between interested parties
bullConsider the whole communities point of view
bull httpdocsmoodleorgdevIntegration_Review
How to guarantee your change is integrated to Moodle core
How to guarantee your change is integrated to Moodle core
You canrsquot
Why notbull The Moodle community is diverse and we need to support a
large community in a generic way
bull Wersquore maintaining a lsquoplatformrsquo with core tools
bull We donrsquot have unlimited resources to maintain every feature anyone can think of
use moodleorgpluginsbull Plugins to support as many types of customisations as possible
bull Tightly integrated to Moodle for easy install and upgrades [DEMO]
bull Infrastructure will continue to be improved in this direction
Why contribute anything to core
bull Itrsquos a bugbull You canrsquot fix core bugs in
pluginsbull There isnrsquot an appropriate
plugin pointbull Yoursquore confident the Moodle
community will be on boardbull Its rewardingbull Dan core contributorsbull (wersquove got 2800 open bugs and
appreciate help)
0
25
50
75
100
28
51
76
84
93
21 22 23 24 25
Non-Moodle HQ core contributorsper release
But if you fit the bill
Here are some ways to increase your chances of success
1 Processbull Same for any developer even Moodle
HQ
Simplified
bull Make code available as a git branch
bull Multiple rounds of code review
bull Pulled into main Moodle repository and tested
bull If successful closed and change is deployed
httpdocsmoodleorgdevProcess
1 ProcessPitfalls
bull Learning the ropes can be daunting donrsquot be afraid to ask for help
bull Some aspects of the process involve waiting for feedback
bullOther parts of the process request your feedback quickly in a time limited way (eg lsquotesting failedrsquo state)
2 Trackerbull All developments start with a tracker
issue The lsquohomersquo of developers lots of knowledge recorded on issues
bull Be sure to search for and link together related issues
bull Record your thoughtsdecisions while developing code is useful reference
bull Be sure to link to related forum discussions docs and materials which are relevant else a developer may not aware of this
2 Tracker
Pitfalls
bull Commenting on an already closed issue
bull Useful in some cases but if new work is required a new issue is needed
bull Creating duplicate issues
bull Please search make use of component fields to narrow down issues
bull Some actions need additional permissions see Moodle Docs Tracker Guide
3 Community supportbull Gather support from the community for your
changes
bull Announce and publicise on forums twitter moots etc
bull For major changes construct a specification on the developer docs wiki and solicit feedback
bull Be sure to consider use cases other than your own
bull Once yoursquove gathered tracker votes comments and support be sure to link from the tracker
3 Community support
Pitfalls
bull Not soliciting any feedback
bull Bumping forum posts to get attention
bull If you are not getting interest it may actually indicate that nobody else is interested which might not be a good fit
bull Ignoring a use case which doesnrsquot fit with yours
bull We canrsquot ignore specific use cases in core
4 Coding Stylebull Moodle has nearly 1 million lines of code which have
evolved over 10+ years from hundreds of developers
bull The Moodle coding style was created to improve consistency and should be followed for all new code httpdocsmoodleorgdevCoding_style
bull Lots of old code sucks donrsquot copy it
bull The codechecker and moodlecheck plugins allow you to check your code against coding style rules automatically
bull Try to take a sensible approach to any code you are modifying Its often sensible to match the surrounding style for better readability
4 Coding StyleCommon Pitfalls
bull Not checked against code checker at all
bull Gives suggestion of poor attention to detail donrsquot give us that excuse
bull Use of underscores in variable names
bull Incorrect spacing on control statements
bull Developing without DEBUG_DEVELOPER
5 Code Reviewbull All Moodle Code is reviewed multiple times before making it into the
final release
bull Moodle is so huge and has been evolving for so long that no one person knows everything
bull The code review serves as a way to both improve the code and to share the historical context which might apply to each change
bull Ideally for the best chance of success someone experienced with the area you are coding would review the code (eg component maintainer)
bull Code review is a two way process donrsquot be afraid to justify your decisions (an important part of the process is to extract the rationale for others to see)
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
Who am Ibull Core developer in Moodle community since 2005
bull Worked with schools universities and businesses around UK
bull Moved to Australia and joined Moodle HQ in 2012 as an Integrator and Developer
bull Since joining HQ irsquove spent a lot of my time complaining about the price of beer in Perth
$10pound7euro8
(httpwwwquoracomBeerDoes-Perth-Australia-have-the-most-expensive-beer-prices-in-the-world)
Who am IIrsquom also part of the Integration Team
bull Experienced group of Moodle developers at HQ who act as the final lsquogatekeepersrsquo
bullConducting final checks before code makes it into Moodle release
bullBring historical context and try to facilitate communication between interested parties
bullConsider the whole communities point of view
bull httpdocsmoodleorgdevIntegration_Review
How to guarantee your change is integrated to Moodle core
How to guarantee your change is integrated to Moodle core
You canrsquot
Why notbull The Moodle community is diverse and we need to support a
large community in a generic way
bull Wersquore maintaining a lsquoplatformrsquo with core tools
bull We donrsquot have unlimited resources to maintain every feature anyone can think of
use moodleorgpluginsbull Plugins to support as many types of customisations as possible
bull Tightly integrated to Moodle for easy install and upgrades [DEMO]
bull Infrastructure will continue to be improved in this direction
Why contribute anything to core
bull Itrsquos a bugbull You canrsquot fix core bugs in
pluginsbull There isnrsquot an appropriate
plugin pointbull Yoursquore confident the Moodle
community will be on boardbull Its rewardingbull Dan core contributorsbull (wersquove got 2800 open bugs and
appreciate help)
0
25
50
75
100
28
51
76
84
93
21 22 23 24 25
Non-Moodle HQ core contributorsper release
But if you fit the bill
Here are some ways to increase your chances of success
1 Processbull Same for any developer even Moodle
HQ
Simplified
bull Make code available as a git branch
bull Multiple rounds of code review
bull Pulled into main Moodle repository and tested
bull If successful closed and change is deployed
httpdocsmoodleorgdevProcess
1 ProcessPitfalls
bull Learning the ropes can be daunting donrsquot be afraid to ask for help
bull Some aspects of the process involve waiting for feedback
bullOther parts of the process request your feedback quickly in a time limited way (eg lsquotesting failedrsquo state)
2 Trackerbull All developments start with a tracker
issue The lsquohomersquo of developers lots of knowledge recorded on issues
bull Be sure to search for and link together related issues
bull Record your thoughtsdecisions while developing code is useful reference
bull Be sure to link to related forum discussions docs and materials which are relevant else a developer may not aware of this
2 Tracker
Pitfalls
bull Commenting on an already closed issue
bull Useful in some cases but if new work is required a new issue is needed
bull Creating duplicate issues
bull Please search make use of component fields to narrow down issues
bull Some actions need additional permissions see Moodle Docs Tracker Guide
3 Community supportbull Gather support from the community for your
changes
bull Announce and publicise on forums twitter moots etc
bull For major changes construct a specification on the developer docs wiki and solicit feedback
bull Be sure to consider use cases other than your own
bull Once yoursquove gathered tracker votes comments and support be sure to link from the tracker
3 Community support
Pitfalls
bull Not soliciting any feedback
bull Bumping forum posts to get attention
bull If you are not getting interest it may actually indicate that nobody else is interested which might not be a good fit
bull Ignoring a use case which doesnrsquot fit with yours
bull We canrsquot ignore specific use cases in core
4 Coding Stylebull Moodle has nearly 1 million lines of code which have
evolved over 10+ years from hundreds of developers
bull The Moodle coding style was created to improve consistency and should be followed for all new code httpdocsmoodleorgdevCoding_style
bull Lots of old code sucks donrsquot copy it
bull The codechecker and moodlecheck plugins allow you to check your code against coding style rules automatically
bull Try to take a sensible approach to any code you are modifying Its often sensible to match the surrounding style for better readability
4 Coding StyleCommon Pitfalls
bull Not checked against code checker at all
bull Gives suggestion of poor attention to detail donrsquot give us that excuse
bull Use of underscores in variable names
bull Incorrect spacing on control statements
bull Developing without DEBUG_DEVELOPER
5 Code Reviewbull All Moodle Code is reviewed multiple times before making it into the
final release
bull Moodle is so huge and has been evolving for so long that no one person knows everything
bull The code review serves as a way to both improve the code and to share the historical context which might apply to each change
bull Ideally for the best chance of success someone experienced with the area you are coding would review the code (eg component maintainer)
bull Code review is a two way process donrsquot be afraid to justify your decisions (an important part of the process is to extract the rationale for others to see)
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
Who am IIrsquom also part of the Integration Team
bull Experienced group of Moodle developers at HQ who act as the final lsquogatekeepersrsquo
bullConducting final checks before code makes it into Moodle release
bullBring historical context and try to facilitate communication between interested parties
bullConsider the whole communities point of view
bull httpdocsmoodleorgdevIntegration_Review
How to guarantee your change is integrated to Moodle core
How to guarantee your change is integrated to Moodle core
You canrsquot
Why notbull The Moodle community is diverse and we need to support a
large community in a generic way
bull Wersquore maintaining a lsquoplatformrsquo with core tools
bull We donrsquot have unlimited resources to maintain every feature anyone can think of
use moodleorgpluginsbull Plugins to support as many types of customisations as possible
bull Tightly integrated to Moodle for easy install and upgrades [DEMO]
bull Infrastructure will continue to be improved in this direction
Why contribute anything to core
bull Itrsquos a bugbull You canrsquot fix core bugs in
pluginsbull There isnrsquot an appropriate
plugin pointbull Yoursquore confident the Moodle
community will be on boardbull Its rewardingbull Dan core contributorsbull (wersquove got 2800 open bugs and
appreciate help)
0
25
50
75
100
28
51
76
84
93
21 22 23 24 25
Non-Moodle HQ core contributorsper release
But if you fit the bill
Here are some ways to increase your chances of success
1 Processbull Same for any developer even Moodle
HQ
Simplified
bull Make code available as a git branch
bull Multiple rounds of code review
bull Pulled into main Moodle repository and tested
bull If successful closed and change is deployed
httpdocsmoodleorgdevProcess
1 ProcessPitfalls
bull Learning the ropes can be daunting donrsquot be afraid to ask for help
bull Some aspects of the process involve waiting for feedback
bullOther parts of the process request your feedback quickly in a time limited way (eg lsquotesting failedrsquo state)
2 Trackerbull All developments start with a tracker
issue The lsquohomersquo of developers lots of knowledge recorded on issues
bull Be sure to search for and link together related issues
bull Record your thoughtsdecisions while developing code is useful reference
bull Be sure to link to related forum discussions docs and materials which are relevant else a developer may not aware of this
2 Tracker
Pitfalls
bull Commenting on an already closed issue
bull Useful in some cases but if new work is required a new issue is needed
bull Creating duplicate issues
bull Please search make use of component fields to narrow down issues
bull Some actions need additional permissions see Moodle Docs Tracker Guide
3 Community supportbull Gather support from the community for your
changes
bull Announce and publicise on forums twitter moots etc
bull For major changes construct a specification on the developer docs wiki and solicit feedback
bull Be sure to consider use cases other than your own
bull Once yoursquove gathered tracker votes comments and support be sure to link from the tracker
3 Community support
Pitfalls
bull Not soliciting any feedback
bull Bumping forum posts to get attention
bull If you are not getting interest it may actually indicate that nobody else is interested which might not be a good fit
bull Ignoring a use case which doesnrsquot fit with yours
bull We canrsquot ignore specific use cases in core
4 Coding Stylebull Moodle has nearly 1 million lines of code which have
evolved over 10+ years from hundreds of developers
bull The Moodle coding style was created to improve consistency and should be followed for all new code httpdocsmoodleorgdevCoding_style
bull Lots of old code sucks donrsquot copy it
bull The codechecker and moodlecheck plugins allow you to check your code against coding style rules automatically
bull Try to take a sensible approach to any code you are modifying Its often sensible to match the surrounding style for better readability
4 Coding StyleCommon Pitfalls
bull Not checked against code checker at all
bull Gives suggestion of poor attention to detail donrsquot give us that excuse
bull Use of underscores in variable names
bull Incorrect spacing on control statements
bull Developing without DEBUG_DEVELOPER
5 Code Reviewbull All Moodle Code is reviewed multiple times before making it into the
final release
bull Moodle is so huge and has been evolving for so long that no one person knows everything
bull The code review serves as a way to both improve the code and to share the historical context which might apply to each change
bull Ideally for the best chance of success someone experienced with the area you are coding would review the code (eg component maintainer)
bull Code review is a two way process donrsquot be afraid to justify your decisions (an important part of the process is to extract the rationale for others to see)
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
How to guarantee your change is integrated to Moodle core
How to guarantee your change is integrated to Moodle core
You canrsquot
Why notbull The Moodle community is diverse and we need to support a
large community in a generic way
bull Wersquore maintaining a lsquoplatformrsquo with core tools
bull We donrsquot have unlimited resources to maintain every feature anyone can think of
use moodleorgpluginsbull Plugins to support as many types of customisations as possible
bull Tightly integrated to Moodle for easy install and upgrades [DEMO]
bull Infrastructure will continue to be improved in this direction
Why contribute anything to core
bull Itrsquos a bugbull You canrsquot fix core bugs in
pluginsbull There isnrsquot an appropriate
plugin pointbull Yoursquore confident the Moodle
community will be on boardbull Its rewardingbull Dan core contributorsbull (wersquove got 2800 open bugs and
appreciate help)
0
25
50
75
100
28
51
76
84
93
21 22 23 24 25
Non-Moodle HQ core contributorsper release
But if you fit the bill
Here are some ways to increase your chances of success
1 Processbull Same for any developer even Moodle
HQ
Simplified
bull Make code available as a git branch
bull Multiple rounds of code review
bull Pulled into main Moodle repository and tested
bull If successful closed and change is deployed
httpdocsmoodleorgdevProcess
1 ProcessPitfalls
bull Learning the ropes can be daunting donrsquot be afraid to ask for help
bull Some aspects of the process involve waiting for feedback
bullOther parts of the process request your feedback quickly in a time limited way (eg lsquotesting failedrsquo state)
2 Trackerbull All developments start with a tracker
issue The lsquohomersquo of developers lots of knowledge recorded on issues
bull Be sure to search for and link together related issues
bull Record your thoughtsdecisions while developing code is useful reference
bull Be sure to link to related forum discussions docs and materials which are relevant else a developer may not aware of this
2 Tracker
Pitfalls
bull Commenting on an already closed issue
bull Useful in some cases but if new work is required a new issue is needed
bull Creating duplicate issues
bull Please search make use of component fields to narrow down issues
bull Some actions need additional permissions see Moodle Docs Tracker Guide
3 Community supportbull Gather support from the community for your
changes
bull Announce and publicise on forums twitter moots etc
bull For major changes construct a specification on the developer docs wiki and solicit feedback
bull Be sure to consider use cases other than your own
bull Once yoursquove gathered tracker votes comments and support be sure to link from the tracker
3 Community support
Pitfalls
bull Not soliciting any feedback
bull Bumping forum posts to get attention
bull If you are not getting interest it may actually indicate that nobody else is interested which might not be a good fit
bull Ignoring a use case which doesnrsquot fit with yours
bull We canrsquot ignore specific use cases in core
4 Coding Stylebull Moodle has nearly 1 million lines of code which have
evolved over 10+ years from hundreds of developers
bull The Moodle coding style was created to improve consistency and should be followed for all new code httpdocsmoodleorgdevCoding_style
bull Lots of old code sucks donrsquot copy it
bull The codechecker and moodlecheck plugins allow you to check your code against coding style rules automatically
bull Try to take a sensible approach to any code you are modifying Its often sensible to match the surrounding style for better readability
4 Coding StyleCommon Pitfalls
bull Not checked against code checker at all
bull Gives suggestion of poor attention to detail donrsquot give us that excuse
bull Use of underscores in variable names
bull Incorrect spacing on control statements
bull Developing without DEBUG_DEVELOPER
5 Code Reviewbull All Moodle Code is reviewed multiple times before making it into the
final release
bull Moodle is so huge and has been evolving for so long that no one person knows everything
bull The code review serves as a way to both improve the code and to share the historical context which might apply to each change
bull Ideally for the best chance of success someone experienced with the area you are coding would review the code (eg component maintainer)
bull Code review is a two way process donrsquot be afraid to justify your decisions (an important part of the process is to extract the rationale for others to see)
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
How to guarantee your change is integrated to Moodle core
You canrsquot
Why notbull The Moodle community is diverse and we need to support a
large community in a generic way
bull Wersquore maintaining a lsquoplatformrsquo with core tools
bull We donrsquot have unlimited resources to maintain every feature anyone can think of
use moodleorgpluginsbull Plugins to support as many types of customisations as possible
bull Tightly integrated to Moodle for easy install and upgrades [DEMO]
bull Infrastructure will continue to be improved in this direction
Why contribute anything to core
bull Itrsquos a bugbull You canrsquot fix core bugs in
pluginsbull There isnrsquot an appropriate
plugin pointbull Yoursquore confident the Moodle
community will be on boardbull Its rewardingbull Dan core contributorsbull (wersquove got 2800 open bugs and
appreciate help)
0
25
50
75
100
28
51
76
84
93
21 22 23 24 25
Non-Moodle HQ core contributorsper release
But if you fit the bill
Here are some ways to increase your chances of success
1 Processbull Same for any developer even Moodle
HQ
Simplified
bull Make code available as a git branch
bull Multiple rounds of code review
bull Pulled into main Moodle repository and tested
bull If successful closed and change is deployed
httpdocsmoodleorgdevProcess
1 ProcessPitfalls
bull Learning the ropes can be daunting donrsquot be afraid to ask for help
bull Some aspects of the process involve waiting for feedback
bullOther parts of the process request your feedback quickly in a time limited way (eg lsquotesting failedrsquo state)
2 Trackerbull All developments start with a tracker
issue The lsquohomersquo of developers lots of knowledge recorded on issues
bull Be sure to search for and link together related issues
bull Record your thoughtsdecisions while developing code is useful reference
bull Be sure to link to related forum discussions docs and materials which are relevant else a developer may not aware of this
2 Tracker
Pitfalls
bull Commenting on an already closed issue
bull Useful in some cases but if new work is required a new issue is needed
bull Creating duplicate issues
bull Please search make use of component fields to narrow down issues
bull Some actions need additional permissions see Moodle Docs Tracker Guide
3 Community supportbull Gather support from the community for your
changes
bull Announce and publicise on forums twitter moots etc
bull For major changes construct a specification on the developer docs wiki and solicit feedback
bull Be sure to consider use cases other than your own
bull Once yoursquove gathered tracker votes comments and support be sure to link from the tracker
3 Community support
Pitfalls
bull Not soliciting any feedback
bull Bumping forum posts to get attention
bull If you are not getting interest it may actually indicate that nobody else is interested which might not be a good fit
bull Ignoring a use case which doesnrsquot fit with yours
bull We canrsquot ignore specific use cases in core
4 Coding Stylebull Moodle has nearly 1 million lines of code which have
evolved over 10+ years from hundreds of developers
bull The Moodle coding style was created to improve consistency and should be followed for all new code httpdocsmoodleorgdevCoding_style
bull Lots of old code sucks donrsquot copy it
bull The codechecker and moodlecheck plugins allow you to check your code against coding style rules automatically
bull Try to take a sensible approach to any code you are modifying Its often sensible to match the surrounding style for better readability
4 Coding StyleCommon Pitfalls
bull Not checked against code checker at all
bull Gives suggestion of poor attention to detail donrsquot give us that excuse
bull Use of underscores in variable names
bull Incorrect spacing on control statements
bull Developing without DEBUG_DEVELOPER
5 Code Reviewbull All Moodle Code is reviewed multiple times before making it into the
final release
bull Moodle is so huge and has been evolving for so long that no one person knows everything
bull The code review serves as a way to both improve the code and to share the historical context which might apply to each change
bull Ideally for the best chance of success someone experienced with the area you are coding would review the code (eg component maintainer)
bull Code review is a two way process donrsquot be afraid to justify your decisions (an important part of the process is to extract the rationale for others to see)
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
Why notbull The Moodle community is diverse and we need to support a
large community in a generic way
bull Wersquore maintaining a lsquoplatformrsquo with core tools
bull We donrsquot have unlimited resources to maintain every feature anyone can think of
use moodleorgpluginsbull Plugins to support as many types of customisations as possible
bull Tightly integrated to Moodle for easy install and upgrades [DEMO]
bull Infrastructure will continue to be improved in this direction
Why contribute anything to core
bull Itrsquos a bugbull You canrsquot fix core bugs in
pluginsbull There isnrsquot an appropriate
plugin pointbull Yoursquore confident the Moodle
community will be on boardbull Its rewardingbull Dan core contributorsbull (wersquove got 2800 open bugs and
appreciate help)
0
25
50
75
100
28
51
76
84
93
21 22 23 24 25
Non-Moodle HQ core contributorsper release
But if you fit the bill
Here are some ways to increase your chances of success
1 Processbull Same for any developer even Moodle
HQ
Simplified
bull Make code available as a git branch
bull Multiple rounds of code review
bull Pulled into main Moodle repository and tested
bull If successful closed and change is deployed
httpdocsmoodleorgdevProcess
1 ProcessPitfalls
bull Learning the ropes can be daunting donrsquot be afraid to ask for help
bull Some aspects of the process involve waiting for feedback
bullOther parts of the process request your feedback quickly in a time limited way (eg lsquotesting failedrsquo state)
2 Trackerbull All developments start with a tracker
issue The lsquohomersquo of developers lots of knowledge recorded on issues
bull Be sure to search for and link together related issues
bull Record your thoughtsdecisions while developing code is useful reference
bull Be sure to link to related forum discussions docs and materials which are relevant else a developer may not aware of this
2 Tracker
Pitfalls
bull Commenting on an already closed issue
bull Useful in some cases but if new work is required a new issue is needed
bull Creating duplicate issues
bull Please search make use of component fields to narrow down issues
bull Some actions need additional permissions see Moodle Docs Tracker Guide
3 Community supportbull Gather support from the community for your
changes
bull Announce and publicise on forums twitter moots etc
bull For major changes construct a specification on the developer docs wiki and solicit feedback
bull Be sure to consider use cases other than your own
bull Once yoursquove gathered tracker votes comments and support be sure to link from the tracker
3 Community support
Pitfalls
bull Not soliciting any feedback
bull Bumping forum posts to get attention
bull If you are not getting interest it may actually indicate that nobody else is interested which might not be a good fit
bull Ignoring a use case which doesnrsquot fit with yours
bull We canrsquot ignore specific use cases in core
4 Coding Stylebull Moodle has nearly 1 million lines of code which have
evolved over 10+ years from hundreds of developers
bull The Moodle coding style was created to improve consistency and should be followed for all new code httpdocsmoodleorgdevCoding_style
bull Lots of old code sucks donrsquot copy it
bull The codechecker and moodlecheck plugins allow you to check your code against coding style rules automatically
bull Try to take a sensible approach to any code you are modifying Its often sensible to match the surrounding style for better readability
4 Coding StyleCommon Pitfalls
bull Not checked against code checker at all
bull Gives suggestion of poor attention to detail donrsquot give us that excuse
bull Use of underscores in variable names
bull Incorrect spacing on control statements
bull Developing without DEBUG_DEVELOPER
5 Code Reviewbull All Moodle Code is reviewed multiple times before making it into the
final release
bull Moodle is so huge and has been evolving for so long that no one person knows everything
bull The code review serves as a way to both improve the code and to share the historical context which might apply to each change
bull Ideally for the best chance of success someone experienced with the area you are coding would review the code (eg component maintainer)
bull Code review is a two way process donrsquot be afraid to justify your decisions (an important part of the process is to extract the rationale for others to see)
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
Why contribute anything to core
bull Itrsquos a bugbull You canrsquot fix core bugs in
pluginsbull There isnrsquot an appropriate
plugin pointbull Yoursquore confident the Moodle
community will be on boardbull Its rewardingbull Dan core contributorsbull (wersquove got 2800 open bugs and
appreciate help)
0
25
50
75
100
28
51
76
84
93
21 22 23 24 25
Non-Moodle HQ core contributorsper release
But if you fit the bill
Here are some ways to increase your chances of success
1 Processbull Same for any developer even Moodle
HQ
Simplified
bull Make code available as a git branch
bull Multiple rounds of code review
bull Pulled into main Moodle repository and tested
bull If successful closed and change is deployed
httpdocsmoodleorgdevProcess
1 ProcessPitfalls
bull Learning the ropes can be daunting donrsquot be afraid to ask for help
bull Some aspects of the process involve waiting for feedback
bullOther parts of the process request your feedback quickly in a time limited way (eg lsquotesting failedrsquo state)
2 Trackerbull All developments start with a tracker
issue The lsquohomersquo of developers lots of knowledge recorded on issues
bull Be sure to search for and link together related issues
bull Record your thoughtsdecisions while developing code is useful reference
bull Be sure to link to related forum discussions docs and materials which are relevant else a developer may not aware of this
2 Tracker
Pitfalls
bull Commenting on an already closed issue
bull Useful in some cases but if new work is required a new issue is needed
bull Creating duplicate issues
bull Please search make use of component fields to narrow down issues
bull Some actions need additional permissions see Moodle Docs Tracker Guide
3 Community supportbull Gather support from the community for your
changes
bull Announce and publicise on forums twitter moots etc
bull For major changes construct a specification on the developer docs wiki and solicit feedback
bull Be sure to consider use cases other than your own
bull Once yoursquove gathered tracker votes comments and support be sure to link from the tracker
3 Community support
Pitfalls
bull Not soliciting any feedback
bull Bumping forum posts to get attention
bull If you are not getting interest it may actually indicate that nobody else is interested which might not be a good fit
bull Ignoring a use case which doesnrsquot fit with yours
bull We canrsquot ignore specific use cases in core
4 Coding Stylebull Moodle has nearly 1 million lines of code which have
evolved over 10+ years from hundreds of developers
bull The Moodle coding style was created to improve consistency and should be followed for all new code httpdocsmoodleorgdevCoding_style
bull Lots of old code sucks donrsquot copy it
bull The codechecker and moodlecheck plugins allow you to check your code against coding style rules automatically
bull Try to take a sensible approach to any code you are modifying Its often sensible to match the surrounding style for better readability
4 Coding StyleCommon Pitfalls
bull Not checked against code checker at all
bull Gives suggestion of poor attention to detail donrsquot give us that excuse
bull Use of underscores in variable names
bull Incorrect spacing on control statements
bull Developing without DEBUG_DEVELOPER
5 Code Reviewbull All Moodle Code is reviewed multiple times before making it into the
final release
bull Moodle is so huge and has been evolving for so long that no one person knows everything
bull The code review serves as a way to both improve the code and to share the historical context which might apply to each change
bull Ideally for the best chance of success someone experienced with the area you are coding would review the code (eg component maintainer)
bull Code review is a two way process donrsquot be afraid to justify your decisions (an important part of the process is to extract the rationale for others to see)
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
But if you fit the bill
Here are some ways to increase your chances of success
1 Processbull Same for any developer even Moodle
HQ
Simplified
bull Make code available as a git branch
bull Multiple rounds of code review
bull Pulled into main Moodle repository and tested
bull If successful closed and change is deployed
httpdocsmoodleorgdevProcess
1 ProcessPitfalls
bull Learning the ropes can be daunting donrsquot be afraid to ask for help
bull Some aspects of the process involve waiting for feedback
bullOther parts of the process request your feedback quickly in a time limited way (eg lsquotesting failedrsquo state)
2 Trackerbull All developments start with a tracker
issue The lsquohomersquo of developers lots of knowledge recorded on issues
bull Be sure to search for and link together related issues
bull Record your thoughtsdecisions while developing code is useful reference
bull Be sure to link to related forum discussions docs and materials which are relevant else a developer may not aware of this
2 Tracker
Pitfalls
bull Commenting on an already closed issue
bull Useful in some cases but if new work is required a new issue is needed
bull Creating duplicate issues
bull Please search make use of component fields to narrow down issues
bull Some actions need additional permissions see Moodle Docs Tracker Guide
3 Community supportbull Gather support from the community for your
changes
bull Announce and publicise on forums twitter moots etc
bull For major changes construct a specification on the developer docs wiki and solicit feedback
bull Be sure to consider use cases other than your own
bull Once yoursquove gathered tracker votes comments and support be sure to link from the tracker
3 Community support
Pitfalls
bull Not soliciting any feedback
bull Bumping forum posts to get attention
bull If you are not getting interest it may actually indicate that nobody else is interested which might not be a good fit
bull Ignoring a use case which doesnrsquot fit with yours
bull We canrsquot ignore specific use cases in core
4 Coding Stylebull Moodle has nearly 1 million lines of code which have
evolved over 10+ years from hundreds of developers
bull The Moodle coding style was created to improve consistency and should be followed for all new code httpdocsmoodleorgdevCoding_style
bull Lots of old code sucks donrsquot copy it
bull The codechecker and moodlecheck plugins allow you to check your code against coding style rules automatically
bull Try to take a sensible approach to any code you are modifying Its often sensible to match the surrounding style for better readability
4 Coding StyleCommon Pitfalls
bull Not checked against code checker at all
bull Gives suggestion of poor attention to detail donrsquot give us that excuse
bull Use of underscores in variable names
bull Incorrect spacing on control statements
bull Developing without DEBUG_DEVELOPER
5 Code Reviewbull All Moodle Code is reviewed multiple times before making it into the
final release
bull Moodle is so huge and has been evolving for so long that no one person knows everything
bull The code review serves as a way to both improve the code and to share the historical context which might apply to each change
bull Ideally for the best chance of success someone experienced with the area you are coding would review the code (eg component maintainer)
bull Code review is a two way process donrsquot be afraid to justify your decisions (an important part of the process is to extract the rationale for others to see)
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
1 Processbull Same for any developer even Moodle
HQ
Simplified
bull Make code available as a git branch
bull Multiple rounds of code review
bull Pulled into main Moodle repository and tested
bull If successful closed and change is deployed
httpdocsmoodleorgdevProcess
1 ProcessPitfalls
bull Learning the ropes can be daunting donrsquot be afraid to ask for help
bull Some aspects of the process involve waiting for feedback
bullOther parts of the process request your feedback quickly in a time limited way (eg lsquotesting failedrsquo state)
2 Trackerbull All developments start with a tracker
issue The lsquohomersquo of developers lots of knowledge recorded on issues
bull Be sure to search for and link together related issues
bull Record your thoughtsdecisions while developing code is useful reference
bull Be sure to link to related forum discussions docs and materials which are relevant else a developer may not aware of this
2 Tracker
Pitfalls
bull Commenting on an already closed issue
bull Useful in some cases but if new work is required a new issue is needed
bull Creating duplicate issues
bull Please search make use of component fields to narrow down issues
bull Some actions need additional permissions see Moodle Docs Tracker Guide
3 Community supportbull Gather support from the community for your
changes
bull Announce and publicise on forums twitter moots etc
bull For major changes construct a specification on the developer docs wiki and solicit feedback
bull Be sure to consider use cases other than your own
bull Once yoursquove gathered tracker votes comments and support be sure to link from the tracker
3 Community support
Pitfalls
bull Not soliciting any feedback
bull Bumping forum posts to get attention
bull If you are not getting interest it may actually indicate that nobody else is interested which might not be a good fit
bull Ignoring a use case which doesnrsquot fit with yours
bull We canrsquot ignore specific use cases in core
4 Coding Stylebull Moodle has nearly 1 million lines of code which have
evolved over 10+ years from hundreds of developers
bull The Moodle coding style was created to improve consistency and should be followed for all new code httpdocsmoodleorgdevCoding_style
bull Lots of old code sucks donrsquot copy it
bull The codechecker and moodlecheck plugins allow you to check your code against coding style rules automatically
bull Try to take a sensible approach to any code you are modifying Its often sensible to match the surrounding style for better readability
4 Coding StyleCommon Pitfalls
bull Not checked against code checker at all
bull Gives suggestion of poor attention to detail donrsquot give us that excuse
bull Use of underscores in variable names
bull Incorrect spacing on control statements
bull Developing without DEBUG_DEVELOPER
5 Code Reviewbull All Moodle Code is reviewed multiple times before making it into the
final release
bull Moodle is so huge and has been evolving for so long that no one person knows everything
bull The code review serves as a way to both improve the code and to share the historical context which might apply to each change
bull Ideally for the best chance of success someone experienced with the area you are coding would review the code (eg component maintainer)
bull Code review is a two way process donrsquot be afraid to justify your decisions (an important part of the process is to extract the rationale for others to see)
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
1 ProcessPitfalls
bull Learning the ropes can be daunting donrsquot be afraid to ask for help
bull Some aspects of the process involve waiting for feedback
bullOther parts of the process request your feedback quickly in a time limited way (eg lsquotesting failedrsquo state)
2 Trackerbull All developments start with a tracker
issue The lsquohomersquo of developers lots of knowledge recorded on issues
bull Be sure to search for and link together related issues
bull Record your thoughtsdecisions while developing code is useful reference
bull Be sure to link to related forum discussions docs and materials which are relevant else a developer may not aware of this
2 Tracker
Pitfalls
bull Commenting on an already closed issue
bull Useful in some cases but if new work is required a new issue is needed
bull Creating duplicate issues
bull Please search make use of component fields to narrow down issues
bull Some actions need additional permissions see Moodle Docs Tracker Guide
3 Community supportbull Gather support from the community for your
changes
bull Announce and publicise on forums twitter moots etc
bull For major changes construct a specification on the developer docs wiki and solicit feedback
bull Be sure to consider use cases other than your own
bull Once yoursquove gathered tracker votes comments and support be sure to link from the tracker
3 Community support
Pitfalls
bull Not soliciting any feedback
bull Bumping forum posts to get attention
bull If you are not getting interest it may actually indicate that nobody else is interested which might not be a good fit
bull Ignoring a use case which doesnrsquot fit with yours
bull We canrsquot ignore specific use cases in core
4 Coding Stylebull Moodle has nearly 1 million lines of code which have
evolved over 10+ years from hundreds of developers
bull The Moodle coding style was created to improve consistency and should be followed for all new code httpdocsmoodleorgdevCoding_style
bull Lots of old code sucks donrsquot copy it
bull The codechecker and moodlecheck plugins allow you to check your code against coding style rules automatically
bull Try to take a sensible approach to any code you are modifying Its often sensible to match the surrounding style for better readability
4 Coding StyleCommon Pitfalls
bull Not checked against code checker at all
bull Gives suggestion of poor attention to detail donrsquot give us that excuse
bull Use of underscores in variable names
bull Incorrect spacing on control statements
bull Developing without DEBUG_DEVELOPER
5 Code Reviewbull All Moodle Code is reviewed multiple times before making it into the
final release
bull Moodle is so huge and has been evolving for so long that no one person knows everything
bull The code review serves as a way to both improve the code and to share the historical context which might apply to each change
bull Ideally for the best chance of success someone experienced with the area you are coding would review the code (eg component maintainer)
bull Code review is a two way process donrsquot be afraid to justify your decisions (an important part of the process is to extract the rationale for others to see)
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
2 Trackerbull All developments start with a tracker
issue The lsquohomersquo of developers lots of knowledge recorded on issues
bull Be sure to search for and link together related issues
bull Record your thoughtsdecisions while developing code is useful reference
bull Be sure to link to related forum discussions docs and materials which are relevant else a developer may not aware of this
2 Tracker
Pitfalls
bull Commenting on an already closed issue
bull Useful in some cases but if new work is required a new issue is needed
bull Creating duplicate issues
bull Please search make use of component fields to narrow down issues
bull Some actions need additional permissions see Moodle Docs Tracker Guide
3 Community supportbull Gather support from the community for your
changes
bull Announce and publicise on forums twitter moots etc
bull For major changes construct a specification on the developer docs wiki and solicit feedback
bull Be sure to consider use cases other than your own
bull Once yoursquove gathered tracker votes comments and support be sure to link from the tracker
3 Community support
Pitfalls
bull Not soliciting any feedback
bull Bumping forum posts to get attention
bull If you are not getting interest it may actually indicate that nobody else is interested which might not be a good fit
bull Ignoring a use case which doesnrsquot fit with yours
bull We canrsquot ignore specific use cases in core
4 Coding Stylebull Moodle has nearly 1 million lines of code which have
evolved over 10+ years from hundreds of developers
bull The Moodle coding style was created to improve consistency and should be followed for all new code httpdocsmoodleorgdevCoding_style
bull Lots of old code sucks donrsquot copy it
bull The codechecker and moodlecheck plugins allow you to check your code against coding style rules automatically
bull Try to take a sensible approach to any code you are modifying Its often sensible to match the surrounding style for better readability
4 Coding StyleCommon Pitfalls
bull Not checked against code checker at all
bull Gives suggestion of poor attention to detail donrsquot give us that excuse
bull Use of underscores in variable names
bull Incorrect spacing on control statements
bull Developing without DEBUG_DEVELOPER
5 Code Reviewbull All Moodle Code is reviewed multiple times before making it into the
final release
bull Moodle is so huge and has been evolving for so long that no one person knows everything
bull The code review serves as a way to both improve the code and to share the historical context which might apply to each change
bull Ideally for the best chance of success someone experienced with the area you are coding would review the code (eg component maintainer)
bull Code review is a two way process donrsquot be afraid to justify your decisions (an important part of the process is to extract the rationale for others to see)
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
2 Tracker
Pitfalls
bull Commenting on an already closed issue
bull Useful in some cases but if new work is required a new issue is needed
bull Creating duplicate issues
bull Please search make use of component fields to narrow down issues
bull Some actions need additional permissions see Moodle Docs Tracker Guide
3 Community supportbull Gather support from the community for your
changes
bull Announce and publicise on forums twitter moots etc
bull For major changes construct a specification on the developer docs wiki and solicit feedback
bull Be sure to consider use cases other than your own
bull Once yoursquove gathered tracker votes comments and support be sure to link from the tracker
3 Community support
Pitfalls
bull Not soliciting any feedback
bull Bumping forum posts to get attention
bull If you are not getting interest it may actually indicate that nobody else is interested which might not be a good fit
bull Ignoring a use case which doesnrsquot fit with yours
bull We canrsquot ignore specific use cases in core
4 Coding Stylebull Moodle has nearly 1 million lines of code which have
evolved over 10+ years from hundreds of developers
bull The Moodle coding style was created to improve consistency and should be followed for all new code httpdocsmoodleorgdevCoding_style
bull Lots of old code sucks donrsquot copy it
bull The codechecker and moodlecheck plugins allow you to check your code against coding style rules automatically
bull Try to take a sensible approach to any code you are modifying Its often sensible to match the surrounding style for better readability
4 Coding StyleCommon Pitfalls
bull Not checked against code checker at all
bull Gives suggestion of poor attention to detail donrsquot give us that excuse
bull Use of underscores in variable names
bull Incorrect spacing on control statements
bull Developing without DEBUG_DEVELOPER
5 Code Reviewbull All Moodle Code is reviewed multiple times before making it into the
final release
bull Moodle is so huge and has been evolving for so long that no one person knows everything
bull The code review serves as a way to both improve the code and to share the historical context which might apply to each change
bull Ideally for the best chance of success someone experienced with the area you are coding would review the code (eg component maintainer)
bull Code review is a two way process donrsquot be afraid to justify your decisions (an important part of the process is to extract the rationale for others to see)
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
3 Community supportbull Gather support from the community for your
changes
bull Announce and publicise on forums twitter moots etc
bull For major changes construct a specification on the developer docs wiki and solicit feedback
bull Be sure to consider use cases other than your own
bull Once yoursquove gathered tracker votes comments and support be sure to link from the tracker
3 Community support
Pitfalls
bull Not soliciting any feedback
bull Bumping forum posts to get attention
bull If you are not getting interest it may actually indicate that nobody else is interested which might not be a good fit
bull Ignoring a use case which doesnrsquot fit with yours
bull We canrsquot ignore specific use cases in core
4 Coding Stylebull Moodle has nearly 1 million lines of code which have
evolved over 10+ years from hundreds of developers
bull The Moodle coding style was created to improve consistency and should be followed for all new code httpdocsmoodleorgdevCoding_style
bull Lots of old code sucks donrsquot copy it
bull The codechecker and moodlecheck plugins allow you to check your code against coding style rules automatically
bull Try to take a sensible approach to any code you are modifying Its often sensible to match the surrounding style for better readability
4 Coding StyleCommon Pitfalls
bull Not checked against code checker at all
bull Gives suggestion of poor attention to detail donrsquot give us that excuse
bull Use of underscores in variable names
bull Incorrect spacing on control statements
bull Developing without DEBUG_DEVELOPER
5 Code Reviewbull All Moodle Code is reviewed multiple times before making it into the
final release
bull Moodle is so huge and has been evolving for so long that no one person knows everything
bull The code review serves as a way to both improve the code and to share the historical context which might apply to each change
bull Ideally for the best chance of success someone experienced with the area you are coding would review the code (eg component maintainer)
bull Code review is a two way process donrsquot be afraid to justify your decisions (an important part of the process is to extract the rationale for others to see)
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
3 Community support
Pitfalls
bull Not soliciting any feedback
bull Bumping forum posts to get attention
bull If you are not getting interest it may actually indicate that nobody else is interested which might not be a good fit
bull Ignoring a use case which doesnrsquot fit with yours
bull We canrsquot ignore specific use cases in core
4 Coding Stylebull Moodle has nearly 1 million lines of code which have
evolved over 10+ years from hundreds of developers
bull The Moodle coding style was created to improve consistency and should be followed for all new code httpdocsmoodleorgdevCoding_style
bull Lots of old code sucks donrsquot copy it
bull The codechecker and moodlecheck plugins allow you to check your code against coding style rules automatically
bull Try to take a sensible approach to any code you are modifying Its often sensible to match the surrounding style for better readability
4 Coding StyleCommon Pitfalls
bull Not checked against code checker at all
bull Gives suggestion of poor attention to detail donrsquot give us that excuse
bull Use of underscores in variable names
bull Incorrect spacing on control statements
bull Developing without DEBUG_DEVELOPER
5 Code Reviewbull All Moodle Code is reviewed multiple times before making it into the
final release
bull Moodle is so huge and has been evolving for so long that no one person knows everything
bull The code review serves as a way to both improve the code and to share the historical context which might apply to each change
bull Ideally for the best chance of success someone experienced with the area you are coding would review the code (eg component maintainer)
bull Code review is a two way process donrsquot be afraid to justify your decisions (an important part of the process is to extract the rationale for others to see)
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
4 Coding Stylebull Moodle has nearly 1 million lines of code which have
evolved over 10+ years from hundreds of developers
bull The Moodle coding style was created to improve consistency and should be followed for all new code httpdocsmoodleorgdevCoding_style
bull Lots of old code sucks donrsquot copy it
bull The codechecker and moodlecheck plugins allow you to check your code against coding style rules automatically
bull Try to take a sensible approach to any code you are modifying Its often sensible to match the surrounding style for better readability
4 Coding StyleCommon Pitfalls
bull Not checked against code checker at all
bull Gives suggestion of poor attention to detail donrsquot give us that excuse
bull Use of underscores in variable names
bull Incorrect spacing on control statements
bull Developing without DEBUG_DEVELOPER
5 Code Reviewbull All Moodle Code is reviewed multiple times before making it into the
final release
bull Moodle is so huge and has been evolving for so long that no one person knows everything
bull The code review serves as a way to both improve the code and to share the historical context which might apply to each change
bull Ideally for the best chance of success someone experienced with the area you are coding would review the code (eg component maintainer)
bull Code review is a two way process donrsquot be afraid to justify your decisions (an important part of the process is to extract the rationale for others to see)
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
4 Coding StyleCommon Pitfalls
bull Not checked against code checker at all
bull Gives suggestion of poor attention to detail donrsquot give us that excuse
bull Use of underscores in variable names
bull Incorrect spacing on control statements
bull Developing without DEBUG_DEVELOPER
5 Code Reviewbull All Moodle Code is reviewed multiple times before making it into the
final release
bull Moodle is so huge and has been evolving for so long that no one person knows everything
bull The code review serves as a way to both improve the code and to share the historical context which might apply to each change
bull Ideally for the best chance of success someone experienced with the area you are coding would review the code (eg component maintainer)
bull Code review is a two way process donrsquot be afraid to justify your decisions (an important part of the process is to extract the rationale for others to see)
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
5 Code Reviewbull All Moodle Code is reviewed multiple times before making it into the
final release
bull Moodle is so huge and has been evolving for so long that no one person knows everything
bull The code review serves as a way to both improve the code and to share the historical context which might apply to each change
bull Ideally for the best chance of success someone experienced with the area you are coding would review the code (eg component maintainer)
bull Code review is a two way process donrsquot be afraid to justify your decisions (an important part of the process is to extract the rationale for others to see)
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
5 Code ReviewPitfalls
bull Difficulty finding a peer reviewer
bull Try to be patient and when your patience runs out consider campaigning politely on the forums
bull Reviewers can be critical and sometimes frank
bull Try not to take it personally the goal of everyone is to find the best technical solution for each issue
bull Disagreement with reviewer
bull Feel free to state your case and if necessary disregard their advice But be sure to justify your rationale for final integration
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
6 Cross-DB Compatibility
bull Moodle supports PostgreSQL MySQL Oracle and MS SQL Please try to test against another db to your usual environment as a minimum
bull Pay special attention when writing custom SQL
bull At this time transactions cannot be relied upon in core because we still support myisam
bull Can be useful for constructing complex queries against different engines httpsqlfiddlecom
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
6 Cross-DB CompatibilityCommon pitfalls
bull Forgetting $DB-gtsql_compare_text() or $DB-gtsql_concat()
bull Using DISTINCT on text columns (not compatible with Oracle)
bull Adding LIMIT clauses rather than using the function params
bull Not including all GROUP BY items in the SELECT field-list (MySQL vs PostgreSQL)
bull Not using placeholders for user input
bull Not using the XMLDB editor for creating schema definitions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
7 Performancebull Donrsquot decrease performance
bull Database queries are by far one of the most expensive things you can do try not to increase them ensure that they are constant
bull If you improve performance please record and share your results on the tracker We love integrating performance improvements
bull profile profile profile (see Tim Huntrsquos recent blogpost Performance-testing Moodle )
bull Make use of the Cache API for adding caching donrsquot create your own caches httpdocsmoodleorgdevCache_API
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
7 PerformanceCommon pitfalls
bull DB Queries in loops or widely called functions
foreach ($courseids as $courseid) do stuff foreach ($studentids as $studentid) $DB-gtget_record(user array(id =gt $studentid) Could be called 500000 times even on small sites
bull Loading a large amount of data into RAMbull Try to use $DB-gtget_recordset() on large datasets
bull Be mindful with file inclusions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
8 Securitybull You should know and be using at least
bull optional_param() required_param() or formslib to validate user input
bull PARAM_xxx types for cleaning user input
bull XSRF protection using session keys
bull s() p() format_string() and format_text() for outputting user-inputted text
bull How to control access using capabilities the context hierarchy and require_login() etc
bull Our process for dealing with security bugs is different in order to achieve responsible disclosure
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
8 SecurityCommon pitfalls
bull Forgetting session keys
bull Handled for you by formslib else you need to do it
bull Often missed when simple toggle functions
bull Incorrect use of PARAM_ types
bull Study the top of libmoodlelibphp
bull Careful with FORMAT_TEXT - itrsquos name is misleading due to multilang
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
9 Internationalisationbull Moodle 25 has over 100 language packs and is a strong multilingual
community
bull Use get_string() for strings donrsquot hardcode english
bull Consider carefully the time of translators in creation of your strings (tricky tradeoff)
bull Remember to use userdate() for times we provide a number of standard time formats as standard
bull Not all languages use lsquorsquo for floating point numbers Remember to use format_float() and unformat_float() to recieve and output floating point numbers in the users locale
bull Consider Right To Left (RTL) languages in CSSdesign [dir-rtl]
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
9 InternationalisationCommon pitfalls
bull Concatenating strings this breaks badly for rtl languages or when its impossible to translate correctly
bull Using the same string in different contexts
bull Use AMOS SCRIPT in git commits to do an AMOS CPY to make the translators life easier httpdocsmoodleorgdevLanguagesAMOSAMOS_script
bull Using PARAM_FLOAT for user input
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
10 Testingbull A big focus for Moodle over the last two years
bull Unit testing with phpunit
bull Tests written in php and executed in a sandboxed lsquoper unitrsquo environment
bull Much more powerful than the old simpletest environment
bull Test environment is reset between tests
bull Data generators allow test data to be easily constructed
bull Extensive range of assertions
bull Automated acceptance testing using behat
bull Tests written in English and executed automatically in a browser environment
bull Used for UI testing in multiple environments
bull Manual tests for situations which are not possible to automate
bull All automated tests are being run and verified on a weekly basis to check for regressions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
10 Behat DemoScenario Login to course and add forum Given the following users exists | username | firstname | lastname | email | | presenter1 | Presenter | Dan | danmoodlecom | And the following courses exists | fullname | shortname | | iMoot Course | imoot | And the following course enrolments exists | user | course | role | | presenter1 | imoot | editingteacher | And I log in as presenter1 And I follow iMoot Course And I turn editing mode on And I add a Forum to section 1 and I fill the form with | Forum name | iMoot Forum | | Forum type | Standard forum for general use | | Description | Test forum description | When I follow iMoot Course Then I should see iMoot Forum
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
10 TestingPitfalls
bull No tests at all
bull Consider using TDD for new code (its likely to be helpful for you too)
bull We will become stricter about this over time (no excuses)
bull Adding complex logic into tests and other lsquotest smellsrsquo
bull httpxunitpatternscomTest20Smellshtml is recommended reading
bull Learning curve setting up the tools
bull Please post on the forums and help us improve our tools
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
Grab bagbull Knowledge of git and how to create a git branch is essential As are
good commit messages (see httpdocsmoodleorgdevCommit_cheat_sheet )
bull Backwards compatibility must be maintained for for core code ensure that your changes donrsquot break backwards compatibility
bull When fixing bugs we generally need to support the last 3 versions currently in support as specified in httpdocsmoodleorgdevReleases
bull Donrsquot be put off from contributing your code if you canrsquot do all of what I suggest Moodle HQ can help prepare code for integration (and appreciate any effort you are able to give)
Questions
Questions
Related Documents
