https://docs.moodle.org/dev/api.php?action=feedcontributions&feedformat=atom&user=Ankitfrenz 2026-10-06T04:56:56Z User contributions MediaWiki 1.43.5 https://docs.moodle.org/dev/index.php?title=Task_API&diff=53212 2017-11-13T03:25:07Z

<p>Ankitfrenz: /* Adhoc tasks */</p> <hr /> <div>{{Infobox Project<br /> |name = Task<br /> |state = Integrated<br /> |tracker = MDL-25505<br /> |discussion = https://moodle.org/mod/forum/discuss.php?d=229139<br /> |assignee = Damyon<br /> }}<br /> {{Moodle 2.7}}<br /> == Tasks ==<br /> <br /> A task is a unit of work that needs to be done later. Good uses for tasks:<br /> <br /> * Run a slow operation in the background<br /> * Run a maintenance task on a regular schedule<br /> <br /> In general any operation that takes more than a few seconds should be a candidate for a task.<br /> <br /> == Benefits ==<br /> <br /> * Better user experience (give them feedback immediately, that their task has been queued)<br /> * Prevent browser timeouts<br /> * Better performance for clusters (tasks can be run on separate, non-webserving cluster node, tasks can run in parallel)<br /> * Failed tasks will be retried<br /> * A better user interface will prevent users queuing multiple tasks, because they thought it had &quot;got stuck&quot;.<br /> <br /> == Types of task ==<br /> <br /> === Scheduled tasks ===<br /> Scheduled tasks are tasks that will run on a regular schedule. A default schedule can be set, but admins have the ability to change the default schedule if required. Note: Tasks will only run as often as cron is run in Moodle. In 2.7 it is recommended to run cron once per minute to get the benefit from the new task scheduling (don't worry - it will do much less work each time it runs).<br /> <br /> === Adhoc tasks ===<br /> Adhoc tasks are for when you need to queue something to run in the background immediately, they would be executed as soon as possible. Adhoc tasks can contain custom data, specific to this specific instance of the task.<br /> <br /> == Usage ==<br /> <br /> === Scheduled task usage ===<br /> <br /> Scheduled tasks are created by subclassing \core\task\scheduled_task. They also require an entry in &quot;db/tasks.php&quot; for your plugin.<br /> <br /> 1. Create a subclass of \core\task\scheduled_task that contains your code to run in a schedule (within &quot;&lt;pluginroot&gt;/classes/task/cut_my_toe_nails.php&quot; for the autoloading mechanism to pick up).<br /> <br /> &lt;pre&gt;<br /> namespace mod_hygene\task;<br /> <br /> class cut_my_toe_nails extends \core\task\scheduled_task { <br /> public function get_name() {<br /> // Shown in admin screens<br /> return get_string('cutmytoenails', 'mod_hygene');<br /> }<br /> <br /> public function execute() { <br /> // apply fungus cream<br /> // apply chainsaw<br /> // apply olive oil<br /> } <br /> } <br /> &lt;/pre&gt;<br /> 2. Create entry in db/tasks.php for your plugin (then a version bump to your plugin will install the task):<br /> &lt;pre&gt;<br /> $tasks = array( <br /> array( <br /> 'classname' =&gt; 'mod_hygene\task\cut_my_toe_nails', <br /> 'blocking' =&gt; 0, <br /> 'minute' =&gt; '30', <br /> 'hour' =&gt; '17', <br /> 'day' =&gt; '*', <br /> 'dayofweek' =&gt; '0', <br /> 'month' =&gt; '1,7' <br /> )<br /> );<br /> &lt;/pre&gt;<br /> <br /> The fields required in the db/tasks.php file are:<br /> * classname - the fully namespaced classname of your task. This needs to comply with the autoloading rules. <br /> * blocking - if this is set to 1, no other scheduled task will run at the same time as this task. Do not set this to 1 unless you really need it as it will impact the performance of the task queue.<br /> * minute, hour, day, dayofweek, month - This is the default schedule for running the task. The syntax matches the syntax of unix cron. Starting with Moodle 2.8, the minute and hour values accept a special 'R' syntax which causes a random value to be set in the database at install time (useful to avoid overloading web services).<br /> <br /> 3. Increase the version number in version.php for your plugin and visit the Site &quot;Administration -&gt; Notifications&quot; page to install the new task. <br /> <br /> 4. (Optional - since 2.8) Run this task even when the plugin is disabled. In rare cases, you may want the scheduled tasks for a plugin to run, even when the plugin is disabled. Some of the enrolment plugins do this to clean up data. If this is the case, the scheduled task must override the &quot;get_run_if_component_disabled()&quot; method and return true instead of false. If they do not do this, the scheduled task will not be run while the plugin is disabled.<br /> <br /> When called from the command line for testing purposes errors can be hidden and a misleading error about locks can be displayed. To get at the details of an error Moodle 3.2 supports a shodebugging option that will show the actual errors. Read about it here<br /> https://docs.moodle.org/32/en/Administration_via_command_line#Scheduled_tasks<br /> <br /> <br /> <br /> ==== Cron syntax examples ====<br /> * day - Day of month field for task schedule. <br /> ** &quot;*&quot; - Every day<br /> ** &quot;*/2&quot; - Every 2nd day<br /> ** &quot;1&quot; - The first of every month<br /> ** &quot;1,15&quot; - The first and fifteenth of every month<br /> * dayofweek - Day of week field for task schedule.<br /> ** &quot;*&quot; - Every day<br /> ** &quot;0&quot; - Every Sunday<br /> ** &quot;6&quot; - Every Saturday<br /> ** &quot;1,5&quot; - Every Monday and Friday<br /> * hour - Hour field for task schedule.<br /> ** &quot;*&quot; - Every hour<br /> ** &quot;*/2&quot; - Every 2 hours<br /> ** &quot;2-10&quot; - Every hour from 2am until 10am (inclusive)<br /> ** &quot;2,6,9&quot; - 2am, 6am and 9am<br /> ** &quot;R&quot; - A random value between 0 and 23 is chosen at task install time (or when reset to default) [Supported since Moodle 2.8]<br /> * minute - Minute field for task schedule.<br /> ** &quot;*&quot; - Every minute<br /> ** &quot;*/5&quot; - Every 5 minutes<br /> ** &quot;2-10&quot; - Every minute between 2 and 10 minutes past the hour (inclusive)<br /> ** &quot;2,6,9&quot; - 2, 6 and 9 minutes past the hour<br /> ** &quot;R&quot; - A random value between 0 and 59 is chosen at task install time (or when reset to default) [Supported since Moodle 2.8]<br /> * month - Month field for task schedule.<br /> ** &quot;*&quot; - Every month<br /> ** &quot;*/2&quot; - Every second month<br /> ** &quot;1&quot; - Every January<br /> ** &quot;1,5&quot; - Every January and May<br /> <br /> === Adhoc task usage ===<br /> <br /> This is even easier than scheduled tasks. <br /> <br /> 1. Create a subclass of \core\task\adhoc_task that contains your code to run in the background.<br /> &lt;pre&gt;<br /> <br /> class take_over_the_world extends \core\task\adhoc_task { <br /> public function execute() { <br /> // gain 100,000,000 friends on facebook.<br /> // crash the stock market.<br /> // run for president.<br /> } <br /> } <br /> <br /> &lt;/pre&gt;<br /> <br /> 2. Create an instance of the task and queue it (adding custom data if required).<br /> <br /> &lt;pre&gt;<br /> // create the instance<br /> $domination = new take_over_the_world();<br /> // set blocking if required (it probably isn't)<br /> // $domination-&gt;set_blocking(true);<br /> // add custom data<br /> $domination-&gt;set_custom_data(array(<br /> 'plansfortomorrownight' =&gt; 'The same thing we do every night, Pinky!'<br /> ));<br /> <br /> // queue it<br /> \core\task\manager::queue_adhoc_task($domination);<br /> <br /> // profit<br /> &lt;/pre&gt;<br /> <br /> 3. There is no 3.<br /> <br /> === Failures ===<br /> A task, either scheduled or adhoc can sometimes fail. An example would be updating an RSS field when the network is temporarily down. This is handled by the task system automatically - all the failing task needs to do is throw an exception. The task will be retried after 1 minute. If the task keeps failing, the retry algorithm will add more time between each successive attempts up to a max of 24 hours.<br /> <br /> === Caches ===<br /> There is one special case that needs to be considered with this new system. If a particular scheduled or adhoc task runs for a long time and updates many DB records - particularly something related to enrolment - the next task in the queue may suffer because various API's in moodle use static caching to speed up requests, but assume that the data will not change much between the start and end of the request. In this case, you can force the cron to exit after running a task that has done many DB updates. The next cron will be run in the next minute, and will have all static caches cleared because it's a new process. To do this call \core\task\manager::clear_static_caches();<br /> <br /> === Security ===<br /> When scheduling a task to run in the background - or creating a scheduled task, the task will run in the context of the cron user (see &quot;cron_setup_user()&quot;). If you need to perform access checks in your background task, you should pass the userid/context in custom_data and then pass that userid to the access check functions (&quot;require_capability('moodle/course:update', $context, $userid)&quot;).<br /> <br /> === Legacy cron ===<br /> The older syntax of cron.php or modname_cron() is still supported - but is not as good as this new API. This is because:<br /> * the legacy cron functions run serially - a long running cron in one plugin will hold up the other plugins crons<br /> * the legacy cron functions are fragile - a failure in one cron in one plugin will prevent the cron in other functions from running at all<br /> * the scheduling cannot be changed by admins<br /> <br /> == For Admins ==<br /> Admins have a new screen where they can adjust the schedules for any scheduled task. They can also reset any scheduled task to its default schedule.<br /> [[File:task_admin_screenshot.png|Screenshot of admin page]]<br /> <br /> NOTE: You can also run [https://docs.moodle.org/32/en/Administration_via_command_line#Scheduled_tasks Scheduled tasks] via command line, individually.<br /> <br /> == Specification ==<br /> The specification for this feature is here: https://docs.moodle.org/dev/Scheduled_Tasks_Proposal</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Moodle_libraries_credits&diff=53046 2017-10-16T10:56:46Z

<p>Ankitfrenz: /* SimplePie */</p> <hr /> <div>Some of Moodle's libraries were written by other people, and are being redistributed as part of Moodle under their respective open source licenses that thankfully allow us to do so. Thanks to the authors of all these excellent products - without them Moodle would be missing important functionality. Copyright information for each package is included below:<br /> <br /> ==ADOdb==<br /> <br /> ''lib/adodb''<br /> <br /> Database abstraction library for MySQL, PostgreSQL, MSSQL, Oracle, Interbase, Foxpro, Access, ADO, Sybase, DB2 and ODBC.<br /> <br /> Version: 5.20.9<br /> <br /> @copyright (c) 2000-2013 John Lim (jlim#natsoft.com). All rights reserved.<br /> <br /> @copyright (c) 2014 Damien Regad, Mark Newnham and the ADOdb community<br /> <br /> License: Dual LGPL and BSD-style<br /> <br /> http://adodb.sourceforge.net<br /> <br /> ==Amazon S3==<br /> <br /> ''repository/s3/S3.php''<br /> <br /> A standalone Amazon S3 (REST) client for PHP 5.2.x using CURL that does not require PEAR. <br /> <br /> Version: 0.5.1<br /> <br /> Copyright (c) 2013, Donovan Schönknecht<br /> <br /> License: BSD 2-Clause<br /> <br /> https://github.com/tpyo/amazon-s3-php-class/releases<br /> <br /> ==CAS==<br /> <br /> ''auth/cas/CAS''<br /> <br /> phpCAS library to support CAS authentication plugin<br /> <br /> Copyright Jasig<br /> <br /> License: Apache License 2.0<br /> <br /> https://wiki.jasig.org/display/CASC/phpCAS<br /> <br /> ==Chart.js==<br /> <br /> ''lib/amd/src/chartjs-lazy.js''<br /> <br /> Simple yet flexible JavaScript charting for designers &amp; developers<br /> <br /> Version: 2.2.2<br /> <br /> Copyright 2016 Nick Downie<br /> <br /> License: MIT<br /> <br /> http://www.chartjs.org<br /> <br /> ==EvalMath==<br /> <br /> ''lib/evalmath''<br /> <br /> Class to safely evaluate math expressions<br /> <br /> Copyright Miles Kaufmann<br /> <br /> License: BSD<br /> <br /> http://www.twmagic.com/<br /> <br /> ==FLV player==<br /> <br /> ''filter/mediaplugin/flvplayer.swf''<br /> <br /> Flash movie to play FLV files<br /> <br /> Copyright Jeroen Wijering <br /> <br /> License: GNU GPL<br /> <br /> http://www.jeroenwijering.com<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==FPDF Class==<br /> <br /> ''lib/fpdf''<br /> <br /> Class to generate PDF files<br /> <br /> Version: 1.54<br /> <br /> Copyright Olivier PLATHEY<br /> <br /> License: Freeware<br /> <br /> http://www.setasign.com/products/fpdi/downloads<br /> <br /> == GeoIp2 ==<br /> <br /> ''lib/maxmind/GeoIp2''<br /> <br /> Library for precessing of GeoIP data files<br /> <br /> Version: 2.6.0<br /> <br /> Copyright MaxMind<br /> <br /> License: Apache 2.0<br /> <br /> https://github.com/maxmind/GeoIP2-php<br /> <br /> ==Google APIs==<br /> <br /> &quot;lib/google&quot;<br /> <br /> Library Google APIs Client Library for PHP<br /> <br /> Version: 1.1.7<br /> <br /> License: Apache License Version 2.0<br /> <br /> https://github.com/google/google-api-php-client<br /> <br /> ==Graph Class==<br /> <br /> ''lib/graphlib.php''<br /> <br /> Class to draw line, point, bar, and area graphs, including numeric x-axis and double y-axis.<br /> <br /> Version: 1.6.3 (with modifications)<br /> <br /> Copyright © 2000 Herman Veluwenkamp (''hermanV AT mindless DOT com'')<br /> <br /> License: LGPL<br /> <br /> ==Horde==<br /> <br /> ''lib/horde''<br /> <br /> Library used by the inbound e-mail handling system.<br /> <br /> Version: 5.2.7<br /> <br /> Copyright © Horde LLC<br /> <br /> License: LGPL<br /> <br /> http://www.horde.org/<br /> <br /> ==html2text==<br /> <br /> ''lib/html2text''<br /> <br /> PHP script to convert HTML into an approximate text equivalent<br /> <br /> Version: 4.1.0<br /> <br /> Copyright (c) 2005-2007 Jon Abernathy &lt;jon@chuggnutt.com&gt;<br /> <br /> License: GNU GPL<br /> <br /> https://github.com/mtibben/html2text.git<br /> <br /> ==htmlArea==<br /> <br /> ''lib/editor''<br /> <br /> Javascript/HTML script to put a GUI editor in textareas on Internet Explorer and Mozilla<br /> <br /> Version: 3.0 beta (with modifications)<br /> <br /> Copyright © 2002 interactivetools.com, inc.<br /> <br /> License: htmlArea License (based on BSD license)<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==HTML Purifier==<br /> <br /> &quot;lib/htmlpurifier&quot;<br /> <br /> Filters HTML.<br /> <br /> Version: 4.8.0<br /> <br /> License: LGPL<br /> <br /> ==IP-Atlas==<br /> <br /> ''lib/ipatlas''<br /> <br /> PHP scripts to show the location of an IP address on a map.<br /> <br /> Version: 1.0 (with modifications)<br /> <br /> Copyright © 2002 Ivan Kozik<br /> <br /> License: GNU GPL<br /> <br /> http://www.xpenguin.com/ip-atlas.php<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==jQuery==<br /> <br /> ''lib/jquery''<br /> <br /> jQuery is a fast, small, and feature-rich JavaScript library widely used on moodle.<br /> <br /> Version: 1.12.3<br /> <br /> Copyright: 2016 The jQuery Foundation<br /> <br /> License: MIT<br /> <br /> https://jquery.com<br /> <br /> ==jQuery migrate==<br /> <br /> ''lib/jquery/jquery-migrate-1.4.0.js''<br /> <br /> Library used migrate older jQuery code to jQuery 3.0.<br /> <br /> Version: 1.4.0<br /> <br /> Copyright: 2016 The jQuery Foundation and other contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/jquery/jquery-migrate<br /> <br /> ==jQuery UI==<br /> <br /> ''lib/jquery/ui-1.12.1/''<br /> <br /> jQuery UI is a set of user interface interactions, effects, widgets, and themes built on top of the jQuery library.<br /> <br /> Version: 1.12.1<br /> <br /> Copyright: 2016 The jQuery Foundation and other contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/jquery/jquery-migrate<br /> <br /> ==Services_JSON==<br /> <br /> ''lib/json''<br /> <br /> Allows PHP-&gt;JS communication via JSON<br /> <br /> Version: 1.3.1<br /> <br /> Copyright © 2005 Michal Migurski<br /> <br /> License: Modified BSD (GPL-compatible)<br /> <br /> http://pear.php.net/pepr/pepr-proposal-show.php?id=198<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==kses==<br /> <br /> ''lib/kses.php''<br /> <br /> HTML/XHTML filter that only allows some elements and attributes<br /> <br /> Version: 0.2.2<br /> <br /> Copyright © 2002, 2003, 2005 Ulf Harnhammar<br /> <br /> License: GNU GPL<br /> <br /> http://sourceforge.net/projects/kses<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==less.php==<br /> <br /> The less.php is a PHP port of the official LESS processor used by moodle themes.<br /> <br /> ''lib/lessphp''<br /> <br /> Version: 1.7.0.10<br /> <br /> License: Apache 2.0<br /> <br /> http://lessphp.typesettercms.com/<br /> <br /> Copyright: Matt Agar and Martin Jantošovič<br /> ==loglevel.js==<br /> <br /> Minimal lightweight simple logging for JavaScript.<br /> <br /> Version 1.4.1<br /> <br /> Copyright (c) 2013 Tim Perry<br /> <br /> License: MIT<br /> <br /> https://github.com/pimterry/loglevel/<br /> ==MathJax==<br /> <br /> &quot;Not actually included in Moodle. Moodle instead has a setting where the mathjax library is located. It is currently pointing to CDN by default.&quot;<br /> <br /> JavaScript filter library for displaying LaTeX, AsciiMath notation, and MathML.<br /> <br /> Version 2.7<br /> <br /> © Copyright 2015 The MathJax Consortium.<br /> <br /> License: Apache V2.0<br /> <br /> https://github.com/mathjax/MathJax<br /> <br /> ==MatthiasMullie\Minify==<br /> CSS &amp; JavaScript minifier, in PHP<br /> <br /> Version 1.3.37<br /> <br /> License: MIT<br /> <br /> https://github.com/matthiasmullie/minify<br /> <br /> ==mimeTeX==<br /> <br /> ''filter/tex''<br /> <br /> Compiled C program to convert TeX into GIFs<br /> <br /> Version: 1.4<br /> <br /> Copyright © 2002-2004 John Forkosh Associates, Inc<br /> <br /> License: GNU GPL<br /> <br /> http://www.forkosh.com/mimetex.html<br /> <br /> ==Mustache.js==<br /> <br /> &quot;lib/amd/src/mustache.js&quot;<br /> <br /> JS library for displaying mustache templates.<br /> <br /> Version: 2.2.1<br /> <br /> Copyright (c) 2009 Chris Wanstrath (Ruby)<br /> <br /> Copyright (c) 2010-2014 Jan Lehnardt (JavaScript)<br /> <br /> Copyright (c) 2010-2015 The mustache.js community<br /> <br /> License: MIT<br /> <br /> https://github.com/janl/mustache.js/releases<br /> <br /> ==Mustache==<br /> <br /> &quot;lib/mustache&quot;<br /> <br /> PHP library for displaying mustache templates.<br /> <br /> Version: 2.11.1<br /> <br /> Copyright (c) 2010-2016 Justin Hileman<br /> <br /> License: MIT<br /> <br /> https://github.com/bobthecow/mustache.php/releases<br /> <br /> ==mp3player==<br /> <br /> ''lib/mp3player''<br /> <br /> Flash movie to play streaming MP3s<br /> <br /> Copyright © 2005 Andrew Walker<br /> <br /> License: GNU GPL<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==overlibmws==<br /> <br /> ''lib/overlib.js''<br /> <br /> Javascript library to enable DHTML popups, floating windows, events etc<br /> <br /> Version: July 2004<br /> <br /> Copyright © 2002-2004 Foteos Macrides<br /> <br /> Copyright © 1998-2004 Erik Bosrup<br /> <br /> License: Artistic Open Source License<br /> <br /> http://www.macridesweb.com/oltest/<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PclZip==<br /> <br /> ''lib/pclzip''<br /> <br /> Class to create, manage and unpack zip files.<br /> <br /> Version: 2.4 RC1<br /> <br /> Copyright © 2004 Vincent Blavet (''vincent AT phpconcept DOT net'')<br /> <br /> License: GNU GPL<br /> <br /> http://www.phpconcept.net<br /> <br /> ==PEAR OLE Classes==<br /> <br /> ''lib/pear''<br /> <br /> Class to write Excel files<br /> <br /> Version: 0.5<br /> <br /> Copyright © 2004 Xavier Noguer<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/OLE<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PEAR Spreadsheet_Excel_Writer==<br /> <br /> ''lib/pear''<br /> <br /> Class to write Excel files<br /> <br /> Version: 0.9.1<br /> <br /> Copyright © 2004 Xavier Noguer and Mika Tuupola<br /> <br /> License: LGPL<br /> <br /> http://pear.php.net/package/Spreadsheet_Excel_Writer<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PEAR HTML_Quickform==<br /> <br /> ''lib/pear''<br /> <br /> Class to write forms<br /> <br /> Version: 3.2.6<br /> <br /> Copyright © 2004 Bertrand Mansion, Adam Daniel, Alexey Borzov<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Quickform<br /> <br /> ==PEAR HTML_Quickform_Renderer_Tableless==<br /> <br /> ''lib/pear''<br /> <br /> Class to render forms without tables<br /> <br /> Version: 0.3.4<br /> <br /> Copyright © 2005 Mark Wiesemann<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Quickform_Renderer_Tableless<br /> <br /> ==PEAR HTML_QuickForm_DHTMLRulesTableless==<br /> <br /> ''lib/pear''<br /> <br /> Class to render validation notices with dhtml<br /> <br /> Version: 0.1.2<br /> <br /> Copyright © 2005 Alexey Borzov, Adam Daniel, Bertrand Mansion, Justin Patrin, Mark Wiesemann<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_QuickForm_DHTMLRulesTableless<br /> <br /> ==PEAR HTML_Common==<br /> <br /> ''lib/pear''<br /> <br /> Class with many common HTML functions (used by HTML Quickform)<br /> <br /> Version: 0.3.4<br /> <br /> Copyright © 2004 Adam Daniel, Bertrand Mansion, Klaus Guenther, Alexey Borzov<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Common<br /> <br /> ==PEAR XML_Parser==<br /> <br /> ''lib/pear''<br /> <br /> Class implementing one handy (sax-expat) XML parser<br /> <br /> Version: 1.3.2<br /> <br /> Copyright © 2004-2008 The PHP Group &amp; Stephan Schmidt<br /> <br /> License: New BSD License<br /> <br /> http://pear.php.net/package/XML_Parser<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PHP-CSS-Parser==<br /> <br /> ''lib/php-css-parser''<br /> <br /> A Parser for CSS Files written in PHP.<br /> <br /> Version: 8.1.0<br /> <br /> Copyright (c) 2011 Raphael Schweikert, http://sabberworm.com/<br /> <br /> License: MIT<br /> <br /> https://github.com/sabberworm/PHP-CSS-Parser<br /> <br /> ==PHPExcel==<br /> <br /> ''lib/phpexcel/PHPExcel.php''<br /> <br /> Library to read, write and create spreadsheet documents in PHP.<br /> <br /> Version 1.8.1<br /> <br /> Copyright © 2006 - 2015 PHPExcel<br /> License: LGPL<br /> <br /> https://github.com/PHPOffice/PHPExcel<br /> <br /> ==PHP mailer==<br /> <br /> ''lib/class.phpmailer.php''<br /> <br /> Class for sending email using either sendmail, PHP mail(), or SMTP. Methods are based upon the standard AspEmail(tm) classes.<br /> <br /> Version 5.2.16<br /> <br /> Copyright © 2003 Brent R. Matzelle (''bmatzelle AT yahoo DOT com'')<br /> License: LGPL<br /> <br /> http://phpmailer.sourceforge.net<br /> https://github.com/PHPMailer/PHPMailer/releases<br /> <br /> ==PHP Markdown==<br /> <br /> ''lib/markdown.php''<br /> <br /> Functions to convert from the Markdown text format into clean XHTML.<br /> <br /> Version: 1.7.0 (with modifications)<br /> <br /> * @copyright 2004-2016 Michel Fortin &lt;https://michelf.com/projects/php-markdown/&gt;<br /> <br /> * @copyright (Original Markdown) 2004-2006 John Gruber &lt;https://daringfireball.net/projects/markdown/&gt;<br /> All rights reserved.<br /> <br /> License: BSD<br /> <br /> http://www.michelf.com/projects/php-markdown/<br /> <br /> ==RequireJS==<br /> <br /> ''/lib/requirejs/'' <br /> <br /> RequireJS is a JavaScript file and module loader.<br /> <br /> Version 2.3.2<br /> <br /> License: new BSD or MIT<br /> <br /> http://requirejs.org/<br /> <br /> ==scssphp==<br /> <br /> ''/lib/scssphp/'' <br /> <br /> scssphp is a compiler for SCSS written in PHP.<br /> <br /> Version: 0.6.5<br /> <br /> Copyright (c) 2015 Leaf Corcoran<br /> <br /> License: MIT<br /> <br /> http://leafo.github.io/scssphp<br /> <br /> ==SimplePie==<br /> <br /> &quot;/lib/simplepie&quot;<br /> <br /> Simple Pie helps with blogs.<br /> <br /> Version 1.5<br /> <br /> License: BSD<br /> <br /> https://github.com/simplepie/simplepie<br /> <br /> ==Snoopy==<br /> <br /> ''lib/snoopy''<br /> <br /> A PHP net client<br /> <br /> Version: 1.0<br /> <br /> Copyright © 1999-2000 Monte Ohrt (''monte AT ispi DOT net'')<br /> License: GNU LGPL<br /> <br /> http://snoopy.sourceforge.com<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==SMTP class==<br /> <br /> ''lib/class.smtp.php''<br /> <br /> Class that can be used to connect and communicate with any SMTP server. It implements all the SMTP functions defined in RFC821 except TURN.<br /> <br /> Version: 03/26/2001<br /> <br /> Copyright © 2001 Chris Ryan (''chris AT greatbridge DOT com'')<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==Spike PHPCoverage==<br /> <br /> ''lib/spikephpcoverage''<br /> <br /> PHP code coverage reporting tool<br /> <br /> Version: 0.8.2 (with modifications)<br /> <br /> Copyright © 2004 SpikeSource Inc<br /> <br /> License: LGPL<br /> <br /> http://developer.spikesource.com/projects/phpcoverage<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==Spout==<br /> <br /> &quot;lib/spout&quot;<br /> <br /> Library for importing and exporting csv / excel / ODS files.<br /> <br /> Version 2.7.3<br /> <br /> License: Apache<br /> <br /> https://github.com/box/spout/<br /> <br /> ==Typo3 Character Set Class==<br /> <br /> ''lib/typo3''<br /> <br /> Class for conversion between charsets and multibyte-savy operations with strings.<br /> <br /> Version: 4.7.19<br /> <br /> Copyright © 2003-2005 Kasper Skaarhoj<br /> <br /> Licence: GNU GPL<br /> <br /> http://typo3.org/<br /> <br /> ==Yahoo User Interface==<br /> <br /> ''lib/yui''<br /> <br /> The Yahoo! User Interface Library is a set of utilities and controls, in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, DHTML and AJAX. The YUI Library also includes several core CSS resources.Set of user-interface components using AJAX, DHTML etc. We use it for all our AJAX-related stuff.<br /> <br /> CVS version: 2.3.0<br /> <br /> Copyright (c) 2006, Yahoo! Inc.<br /> <br /> Licence: BSD<br /> <br /> http://developer.yahoo.com/yui/<br /> <br /> ==Mustache.js==<br /> <br /> &quot;lib/amd/src/mustache.js&quot;<br /> <br /> JS library for displaying mustache templates.<br /> <br /> Version: 2.2.1<br /> <br /> Copyright (c) 2009 Chris Wanstrath (Ruby)<br /> <br /> Copyright (c) 2010-2014 Jan Lehnardt (JavaScript)<br /> <br /> Copyright (c) 2010-2015 The mustache.js community<br /> <br /> License: MIT<br /> <br /> https://github.com/janl/mustache.js/releases<br /> <br /> ==LTI Tool Provider Library for PHP==<br /> <br /> &quot;lib/ltiprovider/&quot;<br /> <br /> PHP library for communicating with learning tools as per the LTI specification.<br /> <br /> Version: 3.0.2<br /> <br /> © 2016 IMS Global Learning Consortium Inc. All Rights Reserved. Trademark Policy - (www.imsglobal.org/trademarks)<br /> <br /> License: Apache 2<br /> <br /> https://github.com/IMSGlobal/LTI-Tool-Provider-Library-PHP<br /> <br /> <br /> ==Popper.js==<br /> <br /> &quot;admin/tool/usertours/amd/src/popper.js&quot;<br /> <br /> A kickass library used to created Poppers in web applications<br /> <br /> © 2016 Federico Zivolo and contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/FezVrasta/popper.js<br /> <br /> ==Flexitour==<br /> <br /> &quot;admin/tool/usertours/amd/src/tour.js&quot;<br /> <br /> A JS library for tours<br /> <br /> © 2016 Andrew Nicols and contributors<br /> <br /> License: GPLv3<br /> <br /> https://github.com/andrewnicols/flexitour<br /> <br /> [[Category:Credits]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Moodle_libraries_credits&diff=53045 2017-10-16T10:55:33Z

<p>Ankitfrenz: /* html2text */</p> <hr /> <div>Some of Moodle's libraries were written by other people, and are being redistributed as part of Moodle under their respective open source licenses that thankfully allow us to do so. Thanks to the authors of all these excellent products - without them Moodle would be missing important functionality. Copyright information for each package is included below:<br /> <br /> ==ADOdb==<br /> <br /> ''lib/adodb''<br /> <br /> Database abstraction library for MySQL, PostgreSQL, MSSQL, Oracle, Interbase, Foxpro, Access, ADO, Sybase, DB2 and ODBC.<br /> <br /> Version: 5.20.9<br /> <br /> @copyright (c) 2000-2013 John Lim (jlim#natsoft.com). All rights reserved.<br /> <br /> @copyright (c) 2014 Damien Regad, Mark Newnham and the ADOdb community<br /> <br /> License: Dual LGPL and BSD-style<br /> <br /> http://adodb.sourceforge.net<br /> <br /> ==Amazon S3==<br /> <br /> ''repository/s3/S3.php''<br /> <br /> A standalone Amazon S3 (REST) client for PHP 5.2.x using CURL that does not require PEAR. <br /> <br /> Version: 0.5.1<br /> <br /> Copyright (c) 2013, Donovan Schönknecht<br /> <br /> License: BSD 2-Clause<br /> <br /> https://github.com/tpyo/amazon-s3-php-class/releases<br /> <br /> ==CAS==<br /> <br /> ''auth/cas/CAS''<br /> <br /> phpCAS library to support CAS authentication plugin<br /> <br /> Copyright Jasig<br /> <br /> License: Apache License 2.0<br /> <br /> https://wiki.jasig.org/display/CASC/phpCAS<br /> <br /> ==Chart.js==<br /> <br /> ''lib/amd/src/chartjs-lazy.js''<br /> <br /> Simple yet flexible JavaScript charting for designers &amp; developers<br /> <br /> Version: 2.2.2<br /> <br /> Copyright 2016 Nick Downie<br /> <br /> License: MIT<br /> <br /> http://www.chartjs.org<br /> <br /> ==EvalMath==<br /> <br /> ''lib/evalmath''<br /> <br /> Class to safely evaluate math expressions<br /> <br /> Copyright Miles Kaufmann<br /> <br /> License: BSD<br /> <br /> http://www.twmagic.com/<br /> <br /> ==FLV player==<br /> <br /> ''filter/mediaplugin/flvplayer.swf''<br /> <br /> Flash movie to play FLV files<br /> <br /> Copyright Jeroen Wijering <br /> <br /> License: GNU GPL<br /> <br /> http://www.jeroenwijering.com<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==FPDF Class==<br /> <br /> ''lib/fpdf''<br /> <br /> Class to generate PDF files<br /> <br /> Version: 1.54<br /> <br /> Copyright Olivier PLATHEY<br /> <br /> License: Freeware<br /> <br /> http://www.setasign.com/products/fpdi/downloads<br /> <br /> == GeoIp2 ==<br /> <br /> ''lib/maxmind/GeoIp2''<br /> <br /> Library for precessing of GeoIP data files<br /> <br /> Version: 2.6.0<br /> <br /> Copyright MaxMind<br /> <br /> License: Apache 2.0<br /> <br /> https://github.com/maxmind/GeoIP2-php<br /> <br /> ==Google APIs==<br /> <br /> &quot;lib/google&quot;<br /> <br /> Library Google APIs Client Library for PHP<br /> <br /> Version: 1.1.7<br /> <br /> License: Apache License Version 2.0<br /> <br /> https://github.com/google/google-api-php-client<br /> <br /> ==Graph Class==<br /> <br /> ''lib/graphlib.php''<br /> <br /> Class to draw line, point, bar, and area graphs, including numeric x-axis and double y-axis.<br /> <br /> Version: 1.6.3 (with modifications)<br /> <br /> Copyright © 2000 Herman Veluwenkamp (''hermanV AT mindless DOT com'')<br /> <br /> License: LGPL<br /> <br /> ==Horde==<br /> <br /> ''lib/horde''<br /> <br /> Library used by the inbound e-mail handling system.<br /> <br /> Version: 5.2.7<br /> <br /> Copyright © Horde LLC<br /> <br /> License: LGPL<br /> <br /> http://www.horde.org/<br /> <br /> ==html2text==<br /> <br /> ''lib/html2text''<br /> <br /> PHP script to convert HTML into an approximate text equivalent<br /> <br /> Version: 4.1.0<br /> <br /> Copyright (c) 2005-2007 Jon Abernathy &lt;jon@chuggnutt.com&gt;<br /> <br /> License: GNU GPL<br /> <br /> https://github.com/mtibben/html2text.git<br /> <br /> ==htmlArea==<br /> <br /> ''lib/editor''<br /> <br /> Javascript/HTML script to put a GUI editor in textareas on Internet Explorer and Mozilla<br /> <br /> Version: 3.0 beta (with modifications)<br /> <br /> Copyright © 2002 interactivetools.com, inc.<br /> <br /> License: htmlArea License (based on BSD license)<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==HTML Purifier==<br /> <br /> &quot;lib/htmlpurifier&quot;<br /> <br /> Filters HTML.<br /> <br /> Version: 4.8.0<br /> <br /> License: LGPL<br /> <br /> ==IP-Atlas==<br /> <br /> ''lib/ipatlas''<br /> <br /> PHP scripts to show the location of an IP address on a map.<br /> <br /> Version: 1.0 (with modifications)<br /> <br /> Copyright © 2002 Ivan Kozik<br /> <br /> License: GNU GPL<br /> <br /> http://www.xpenguin.com/ip-atlas.php<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==jQuery==<br /> <br /> ''lib/jquery''<br /> <br /> jQuery is a fast, small, and feature-rich JavaScript library widely used on moodle.<br /> <br /> Version: 1.12.3<br /> <br /> Copyright: 2016 The jQuery Foundation<br /> <br /> License: MIT<br /> <br /> https://jquery.com<br /> <br /> ==jQuery migrate==<br /> <br /> ''lib/jquery/jquery-migrate-1.4.0.js''<br /> <br /> Library used migrate older jQuery code to jQuery 3.0.<br /> <br /> Version: 1.4.0<br /> <br /> Copyright: 2016 The jQuery Foundation and other contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/jquery/jquery-migrate<br /> <br /> ==jQuery UI==<br /> <br /> ''lib/jquery/ui-1.12.1/''<br /> <br /> jQuery UI is a set of user interface interactions, effects, widgets, and themes built on top of the jQuery library.<br /> <br /> Version: 1.12.1<br /> <br /> Copyright: 2016 The jQuery Foundation and other contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/jquery/jquery-migrate<br /> <br /> ==Services_JSON==<br /> <br /> ''lib/json''<br /> <br /> Allows PHP-&gt;JS communication via JSON<br /> <br /> Version: 1.3.1<br /> <br /> Copyright © 2005 Michal Migurski<br /> <br /> License: Modified BSD (GPL-compatible)<br /> <br /> http://pear.php.net/pepr/pepr-proposal-show.php?id=198<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==kses==<br /> <br /> ''lib/kses.php''<br /> <br /> HTML/XHTML filter that only allows some elements and attributes<br /> <br /> Version: 0.2.2<br /> <br /> Copyright © 2002, 2003, 2005 Ulf Harnhammar<br /> <br /> License: GNU GPL<br /> <br /> http://sourceforge.net/projects/kses<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==less.php==<br /> <br /> The less.php is a PHP port of the official LESS processor used by moodle themes.<br /> <br /> ''lib/lessphp''<br /> <br /> Version: 1.7.0.10<br /> <br /> License: Apache 2.0<br /> <br /> http://lessphp.typesettercms.com/<br /> <br /> Copyright: Matt Agar and Martin Jantošovič<br /> ==loglevel.js==<br /> <br /> Minimal lightweight simple logging for JavaScript.<br /> <br /> Version 1.4.1<br /> <br /> Copyright (c) 2013 Tim Perry<br /> <br /> License: MIT<br /> <br /> https://github.com/pimterry/loglevel/<br /> ==MathJax==<br /> <br /> &quot;Not actually included in Moodle. Moodle instead has a setting where the mathjax library is located. It is currently pointing to CDN by default.&quot;<br /> <br /> JavaScript filter library for displaying LaTeX, AsciiMath notation, and MathML.<br /> <br /> Version 2.7<br /> <br /> © Copyright 2015 The MathJax Consortium.<br /> <br /> License: Apache V2.0<br /> <br /> https://github.com/mathjax/MathJax<br /> <br /> ==MatthiasMullie\Minify==<br /> CSS &amp; JavaScript minifier, in PHP<br /> <br /> Version 1.3.37<br /> <br /> License: MIT<br /> <br /> https://github.com/matthiasmullie/minify<br /> <br /> ==mimeTeX==<br /> <br /> ''filter/tex''<br /> <br /> Compiled C program to convert TeX into GIFs<br /> <br /> Version: 1.4<br /> <br /> Copyright © 2002-2004 John Forkosh Associates, Inc<br /> <br /> License: GNU GPL<br /> <br /> http://www.forkosh.com/mimetex.html<br /> <br /> ==Mustache.js==<br /> <br /> &quot;lib/amd/src/mustache.js&quot;<br /> <br /> JS library for displaying mustache templates.<br /> <br /> Version: 2.2.1<br /> <br /> Copyright (c) 2009 Chris Wanstrath (Ruby)<br /> <br /> Copyright (c) 2010-2014 Jan Lehnardt (JavaScript)<br /> <br /> Copyright (c) 2010-2015 The mustache.js community<br /> <br /> License: MIT<br /> <br /> https://github.com/janl/mustache.js/releases<br /> <br /> ==Mustache==<br /> <br /> &quot;lib/mustache&quot;<br /> <br /> PHP library for displaying mustache templates.<br /> <br /> Version: 2.11.1<br /> <br /> Copyright (c) 2010-2016 Justin Hileman<br /> <br /> License: MIT<br /> <br /> https://github.com/bobthecow/mustache.php/releases<br /> <br /> ==mp3player==<br /> <br /> ''lib/mp3player''<br /> <br /> Flash movie to play streaming MP3s<br /> <br /> Copyright © 2005 Andrew Walker<br /> <br /> License: GNU GPL<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==overlibmws==<br /> <br /> ''lib/overlib.js''<br /> <br /> Javascript library to enable DHTML popups, floating windows, events etc<br /> <br /> Version: July 2004<br /> <br /> Copyright © 2002-2004 Foteos Macrides<br /> <br /> Copyright © 1998-2004 Erik Bosrup<br /> <br /> License: Artistic Open Source License<br /> <br /> http://www.macridesweb.com/oltest/<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PclZip==<br /> <br /> ''lib/pclzip''<br /> <br /> Class to create, manage and unpack zip files.<br /> <br /> Version: 2.4 RC1<br /> <br /> Copyright © 2004 Vincent Blavet (''vincent AT phpconcept DOT net'')<br /> <br /> License: GNU GPL<br /> <br /> http://www.phpconcept.net<br /> <br /> ==PEAR OLE Classes==<br /> <br /> ''lib/pear''<br /> <br /> Class to write Excel files<br /> <br /> Version: 0.5<br /> <br /> Copyright © 2004 Xavier Noguer<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/OLE<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PEAR Spreadsheet_Excel_Writer==<br /> <br /> ''lib/pear''<br /> <br /> Class to write Excel files<br /> <br /> Version: 0.9.1<br /> <br /> Copyright © 2004 Xavier Noguer and Mika Tuupola<br /> <br /> License: LGPL<br /> <br /> http://pear.php.net/package/Spreadsheet_Excel_Writer<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PEAR HTML_Quickform==<br /> <br /> ''lib/pear''<br /> <br /> Class to write forms<br /> <br /> Version: 3.2.6<br /> <br /> Copyright © 2004 Bertrand Mansion, Adam Daniel, Alexey Borzov<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Quickform<br /> <br /> ==PEAR HTML_Quickform_Renderer_Tableless==<br /> <br /> ''lib/pear''<br /> <br /> Class to render forms without tables<br /> <br /> Version: 0.3.4<br /> <br /> Copyright © 2005 Mark Wiesemann<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Quickform_Renderer_Tableless<br /> <br /> ==PEAR HTML_QuickForm_DHTMLRulesTableless==<br /> <br /> ''lib/pear''<br /> <br /> Class to render validation notices with dhtml<br /> <br /> Version: 0.1.2<br /> <br /> Copyright © 2005 Alexey Borzov, Adam Daniel, Bertrand Mansion, Justin Patrin, Mark Wiesemann<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_QuickForm_DHTMLRulesTableless<br /> <br /> ==PEAR HTML_Common==<br /> <br /> ''lib/pear''<br /> <br /> Class with many common HTML functions (used by HTML Quickform)<br /> <br /> Version: 0.3.4<br /> <br /> Copyright © 2004 Adam Daniel, Bertrand Mansion, Klaus Guenther, Alexey Borzov<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Common<br /> <br /> ==PEAR XML_Parser==<br /> <br /> ''lib/pear''<br /> <br /> Class implementing one handy (sax-expat) XML parser<br /> <br /> Version: 1.3.2<br /> <br /> Copyright © 2004-2008 The PHP Group &amp; Stephan Schmidt<br /> <br /> License: New BSD License<br /> <br /> http://pear.php.net/package/XML_Parser<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PHP-CSS-Parser==<br /> <br /> ''lib/php-css-parser''<br /> <br /> A Parser for CSS Files written in PHP.<br /> <br /> Version: 8.1.0<br /> <br /> Copyright (c) 2011 Raphael Schweikert, http://sabberworm.com/<br /> <br /> License: MIT<br /> <br /> https://github.com/sabberworm/PHP-CSS-Parser<br /> <br /> ==PHPExcel==<br /> <br /> ''lib/phpexcel/PHPExcel.php''<br /> <br /> Library to read, write and create spreadsheet documents in PHP.<br /> <br /> Version 1.8.1<br /> <br /> Copyright © 2006 - 2015 PHPExcel<br /> License: LGPL<br /> <br /> https://github.com/PHPOffice/PHPExcel<br /> <br /> ==PHP mailer==<br /> <br /> ''lib/class.phpmailer.php''<br /> <br /> Class for sending email using either sendmail, PHP mail(), or SMTP. Methods are based upon the standard AspEmail(tm) classes.<br /> <br /> Version 5.2.16<br /> <br /> Copyright © 2003 Brent R. Matzelle (''bmatzelle AT yahoo DOT com'')<br /> License: LGPL<br /> <br /> http://phpmailer.sourceforge.net<br /> https://github.com/PHPMailer/PHPMailer/releases<br /> <br /> ==PHP Markdown==<br /> <br /> ''lib/markdown.php''<br /> <br /> Functions to convert from the Markdown text format into clean XHTML.<br /> <br /> Version: 1.7.0 (with modifications)<br /> <br /> * @copyright 2004-2016 Michel Fortin &lt;https://michelf.com/projects/php-markdown/&gt;<br /> <br /> * @copyright (Original Markdown) 2004-2006 John Gruber &lt;https://daringfireball.net/projects/markdown/&gt;<br /> All rights reserved.<br /> <br /> License: BSD<br /> <br /> http://www.michelf.com/projects/php-markdown/<br /> <br /> ==RequireJS==<br /> <br /> ''/lib/requirejs/'' <br /> <br /> RequireJS is a JavaScript file and module loader.<br /> <br /> Version 2.3.2<br /> <br /> License: new BSD or MIT<br /> <br /> http://requirejs.org/<br /> <br /> ==scssphp==<br /> <br /> ''/lib/scssphp/'' <br /> <br /> scssphp is a compiler for SCSS written in PHP.<br /> <br /> Version: 0.6.5<br /> <br /> Copyright (c) 2015 Leaf Corcoran<br /> <br /> License: MIT<br /> <br /> http://leafo.github.io/scssphp<br /> <br /> ==SimplePie==<br /> <br /> &quot;/lib/simplepie&quot;<br /> <br /> Simple Pie helps with blogs.<br /> <br /> Version 1.4.2<br /> <br /> License: BSD<br /> <br /> https://github.com/simplepie/simplepie<br /> <br /> ==Snoopy==<br /> <br /> ''lib/snoopy''<br /> <br /> A PHP net client<br /> <br /> Version: 1.0<br /> <br /> Copyright © 1999-2000 Monte Ohrt (''monte AT ispi DOT net'')<br /> License: GNU LGPL<br /> <br /> http://snoopy.sourceforge.com<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==SMTP class==<br /> <br /> ''lib/class.smtp.php''<br /> <br /> Class that can be used to connect and communicate with any SMTP server. It implements all the SMTP functions defined in RFC821 except TURN.<br /> <br /> Version: 03/26/2001<br /> <br /> Copyright © 2001 Chris Ryan (''chris AT greatbridge DOT com'')<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==Spike PHPCoverage==<br /> <br /> ''lib/spikephpcoverage''<br /> <br /> PHP code coverage reporting tool<br /> <br /> Version: 0.8.2 (with modifications)<br /> <br /> Copyright © 2004 SpikeSource Inc<br /> <br /> License: LGPL<br /> <br /> http://developer.spikesource.com/projects/phpcoverage<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==Spout==<br /> <br /> &quot;lib/spout&quot;<br /> <br /> Library for importing and exporting csv / excel / ODS files.<br /> <br /> Version 2.7.3<br /> <br /> License: Apache<br /> <br /> https://github.com/box/spout/<br /> <br /> ==Typo3 Character Set Class==<br /> <br /> ''lib/typo3''<br /> <br /> Class for conversion between charsets and multibyte-savy operations with strings.<br /> <br /> Version: 4.7.19<br /> <br /> Copyright © 2003-2005 Kasper Skaarhoj<br /> <br /> Licence: GNU GPL<br /> <br /> http://typo3.org/<br /> <br /> ==Yahoo User Interface==<br /> <br /> ''lib/yui''<br /> <br /> The Yahoo! User Interface Library is a set of utilities and controls, in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, DHTML and AJAX. The YUI Library also includes several core CSS resources.Set of user-interface components using AJAX, DHTML etc. We use it for all our AJAX-related stuff.<br /> <br /> CVS version: 2.3.0<br /> <br /> Copyright (c) 2006, Yahoo! Inc.<br /> <br /> Licence: BSD<br /> <br /> http://developer.yahoo.com/yui/<br /> <br /> ==Mustache.js==<br /> <br /> &quot;lib/amd/src/mustache.js&quot;<br /> <br /> JS library for displaying mustache templates.<br /> <br /> Version: 2.2.1<br /> <br /> Copyright (c) 2009 Chris Wanstrath (Ruby)<br /> <br /> Copyright (c) 2010-2014 Jan Lehnardt (JavaScript)<br /> <br /> Copyright (c) 2010-2015 The mustache.js community<br /> <br /> License: MIT<br /> <br /> https://github.com/janl/mustache.js/releases<br /> <br /> ==LTI Tool Provider Library for PHP==<br /> <br /> &quot;lib/ltiprovider/&quot;<br /> <br /> PHP library for communicating with learning tools as per the LTI specification.<br /> <br /> Version: 3.0.2<br /> <br /> © 2016 IMS Global Learning Consortium Inc. All Rights Reserved. Trademark Policy - (www.imsglobal.org/trademarks)<br /> <br /> License: Apache 2<br /> <br /> https://github.com/IMSGlobal/LTI-Tool-Provider-Library-PHP<br /> <br /> <br /> ==Popper.js==<br /> <br /> &quot;admin/tool/usertours/amd/src/popper.js&quot;<br /> <br /> A kickass library used to created Poppers in web applications<br /> <br /> © 2016 Federico Zivolo and contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/FezVrasta/popper.js<br /> <br /> ==Flexitour==<br /> <br /> &quot;admin/tool/usertours/amd/src/tour.js&quot;<br /> <br /> A JS library for tours<br /> <br /> © 2016 Andrew Nicols and contributors<br /> <br /> License: GPLv3<br /> <br /> https://github.com/andrewnicols/flexitour<br /> <br /> [[Category:Credits]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Restore_2.0_for_developers&diff=53039 2017-10-16T05:52:11Z

<p>Ankitfrenz: /* restore_choice_stepslib.php */</p> <hr /> <div>{{Template:Backup 2.0}}{{Moodle_2.0}}{{Work in progress}}<br /> <br /> == Introduction ==<br /> <br /> This page tries to explain, from a development perspective, '''how to implement''' the restore feature for various Moodle 2.x plugins, mainly, modules and blocks. <br /> <br /> In order to work with Restore 2.0 you must read [[Backup 2.0 for developers]]. Everything will be crystal clear once you have read it. <br /> <br /> In this documentation you will learn about some points that you can not easily deduce from [[Backup 2.0 for developers]] concerning the Choice module.<br /> <br /> == Coding ==<br /> the restore is composed by two main php files: restore_choice_stepslib.php and restore_choice_activity_task.class.php<br /> === restore_choice_stepslib.php ===<br /> <br /> &lt;code php&gt;<br /> /**<br /> * Structure step to restore one choice activity<br /> */<br /> class restore_choice_activity_structure_step extends restore_activity_structure_step {<br /> <br /> protected function define_structure() {<br /> <br /> $paths = array();<br /> $userinfo = $this-&gt;get_setting_value('userinfo');<br /> <br /> $paths[] = new restore_path_element('choice', '/activity/choice');<br /> $paths[] = new restore_path_element('choice_option', '/activity/choice/options/option');<br /> if ($userinfo) {<br /> $paths[] = new restore_path_element('choice_answer', '/activity/choice/answers/answer');<br /> }<br /> <br /> // Return the paths wrapped into standard activity structure<br /> return $this-&gt;prepare_activity_structure($paths);<br /> }<br /> <br /> protected function process_choice($data) {<br /> global $DB;<br /> <br /> $data = (object)$data;<br /> $oldid = $data-&gt;id;<br /> $data-&gt;course = $this-&gt;get_courseid();<br /> <br /> $data-&gt;timeopen = $this-&gt;apply_date_offset($data-&gt;timeopen);<br /> $data-&gt;timeclose = $this-&gt;apply_date_offset($data-&gt;timeclose);<br /> <br /> // insert the choice record<br /> $newitemid = $DB-&gt;insert_record('choice', $data);<br /> // immediately after inserting &quot;activity&quot; record, call this<br /> $this-&gt;apply_activity_instance($newitemid);<br /> }<br /> <br /> protected function process_choice_option($data) {<br /> global $DB;<br /> <br /> $data = (object)$data;<br /> $oldid = $data-&gt;id;<br /> <br /> $data-&gt;choiceid = $this-&gt;get_new_parentid('choice');<br /> <br /> $newitemid = $DB-&gt;insert_record('choice_options', $data);<br /> $this-&gt;set_mapping('choice_option', $oldid, $newitemid);<br /> }<br /> <br /> protected function process_choice_answer($data) {<br /> global $DB;<br /> <br /> $data = (object)$data;<br /> <br /> $data-&gt;choiceid = $this-&gt;get_new_parentid('choice');<br /> $data-&gt;optionid = $this-&gt;get_mappingid('choice_option', $data-&gt;optionid);<br /> $data-&gt;userid = $this-&gt;get_mappingid('user', $data-&gt;userid);<br /> <br /> $newitemid = $DB-&gt;insert_record('choice_answers', $data);<br /> // No need to save this mapping as far as nothing depend on it<br /> // (child paths, file areas nor links decoder)<br /> }<br /> <br /> protected function after_execute() {<br /> // Add choice related files, no need to match by itemname (just internally handled context)<br /> $this-&gt;add_related_files('mod_choice', 'intro', null);<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> === restore_choice_activity_task.class.php ===<br /> &lt;code php&gt;<br /> /**<br /> * choice restore task that provides all the settings and steps to perform one<br /> * complete restore of the activity<br /> */<br /> <br /> require_once($CFG-&gt;dirroot . '/mod/choice/backup/moodle2/restore_choice_stepslib.php'); // Because it exists (must)<br /> <br /> class restore_choice_activity_task extends restore_activity_task {<br /> <br /> /**<br /> * Define (add) particular settings this activity can have<br /> */<br /> protected function define_my_settings() {<br /> // No particular settings for this activity<br /> }<br /> <br /> /**<br /> * Define (add) particular steps this activity can have<br /> */<br /> protected function define_my_steps() {<br /> // Choice only has one structure step<br /> $this-&gt;add_step(new restore_choice_activity_structure_step('choice_structure', 'choice.xml'));<br /> }<br /> <br /> /**<br /> * Define the contents in the activity that must be<br /> * processed by the link decoder<br /> */<br /> static public function define_decode_contents() {<br /> $contents = array();<br /> <br /> $contents[] = new restore_decode_content('choice', array('intro'), 'choice');<br /> <br /> return $contents;<br /> }<br /> <br /> /**<br /> * Define the decoding rules for links belonging<br /> * to the activity to be executed by the link decoder<br /> */<br /> static public function define_decode_rules() {<br /> $rules = array();<br /> <br /> $rules[] = new restore_decode_rule('CHOICEVIEWBYID', '/mod/choice/view.php?id=$1', 'course_module');<br /> $rules[] = new restore_decode_rule('CHOICEINDEX', '/mod/choice/index.php?id=$1', 'course');<br /> <br /> return $rules;<br /> <br /> }<br /> <br /> /**<br /> * Define the restore log rules that will be applied<br /> * by the {@link restore_logs_processor} when restoring<br /> * choice logs. It must return one array<br /> * of {@link restore_log_rule} objects<br /> */<br /> static public function define_restore_log_rules() {<br /> $rules = array();<br /> <br /> $rules[] = new restore_log_rule('choice', 'add', 'view.php?id={course_module}', '{choice}');<br /> $rules[] = new restore_log_rule('choice', 'update', 'view.php?id={course_module}', '{choice}');<br /> $rules[] = new restore_log_rule('choice', 'view', 'view.php?id={course_module}', '{choice}');<br /> $rules[] = new restore_log_rule('choice', 'choose', 'view.php?id={course_module}', '{choice}');<br /> $rules[] = new restore_log_rule('choice', 'choose again', 'view.php?id={course_module}', '{choice}');<br /> $rules[] = new restore_log_rule('choice', 'report', 'report.php?id={course_module}', '{choice}');<br /> <br /> return $rules;<br /> }<br /> <br /> /**<br /> * Define the restore log rules that will be applied<br /> * by the {@link restore_logs_processor} when restoring<br /> * course logs. It must return one array<br /> * of {@link restore_log_rule} objects<br /> *<br /> * Note this rules are applied when restoring course logs<br /> * by the restore final task, but are defined here at<br /> * activity level. All them are rules not linked to any module instance (cmid = 0)<br /> */<br /> static public function define_restore_log_rules_for_course() {<br /> $rules = array();<br /> <br /> // Fix old wrong uses (missing extension)<br /> $rules[] = new restore_log_rule('choice', 'view all', 'index?id={course}', null,<br /> null, null, 'index.php?id={course}');<br /> $rules[] = new restore_log_rule('choice', 'view all', 'index.php?id={course}', null);<br /> <br /> return $rules;<br /> }<br /> <br /> }<br /> &lt;/code&gt;<br /> <br /> '''define_restore_log_rules''': it covers all the &quot;mandatory&quot; log actions, performing {course_module} and {choice} mappings properly. Note that names between curly brackets instruct the log processor to look in the mapping tables for item = name between brackets. Of course, other modules like forum, has a lot of rules, with more complex mappings and so on. Choice is pretty basic.<br /> <br /> '''define_restore_log_rules_for_course''': choice module has the 1st rule because, while implementing restore, we discovered one bug causing URLs to be written in the logs table WITHOUT the .php in the URL, hence choice has that extra rule (that uses the 5-8 params, to REWRITE the URL to be inserted on restore). But that was one problem with choices only, afaik, so you probably would not need it in your own module.<br /> <br /> == Automatically triggering restore in code ==<br /> <br /> As with backup it is possible to automatically trigger a restore for a course (or activity or anything else you can back up). Here is how to restore a course backup into a new course:<br /> <br /> # Put the backup files in a specific folder: $CFG-&gt;dataroot/temp/backup/$folder, where $folder is a random or unused unique id.<br /> # Decide on the course shortname, fullname, and category id for restore (course must not already exist).<br /> # Run the following code:<br /> <br /> &lt;code php&gt;<br /> &lt;?php<br /> <br /> define('CLI_SCRIPT', true);<br /> <br /> require_once('config.php');<br /> require_once($CFG-&gt;dirroot . '/backup/util/includes/restore_includes.php');<br /> <br /> // Transaction.<br /> $transaction = $DB-&gt;start_delegated_transaction();<br /> <br /> // Create new course.<br /> $folder = XX; // as found in: $CFG-&gt;dataroot . '/temp/backup/' <br /> $categoryid = YY; // e.g. 1 == Miscellaneous<br /> $userdoingrestore = ZZ; // e.g. 2 == admin<br /> $courseid = restore_dbops::create_new_course('', '', $categoryid);<br /> <br /> // Restore backup into course.<br /> $controller = new restore_controller($folder, $courseid, <br /> backup::INTERACTIVE_NO, backup::MODE_SAMESITE, $userdoingrestore,<br /> backup::TARGET_NEW_COURSE);<br /> $controller-&gt;execute_precheck();<br /> $controller-&gt;execute_plan();<br /> <br /> // Commit.<br /> $transaction-&gt;allow_commit();<br /> &lt;/code&gt;<br /> <br /> Note:<br /> <br /> * The transaction is used so that if backup fails, the course isn't created.<br /> * The MODE_SAMESITE option is used if restoring a backup which comes from the same site, otherwise MODE_GENERAL might be used.<br /> <br /> == Code that runs after restore ==<br /> <br /> If you are writing a restore task for an activity module, your code is all executed while the system is restoring that module. The &lt;tt&gt;after_execute&lt;/tt&gt; method in your &lt;tt&gt;restore_mymodule_activity_structure_step&lt;/tt&gt; class is called immediately after all the other restore functions in that step are finished for that instance of the module.<br /> <br /> === The problem ===<br /> <br /> Usually this is correct, but in some situations you may need to have an activity module restore that depends in some way on another activity module or on a course section other than the one the module belongs to. Depending on the order within the course, in some cases the other module or section has not yet been restored, so this is a problem.<br /> <br /> The code that may not work as a result is code that tries to convert from an 'old' course-module ID or section ID into a 'new' one:<br /> <br /> $newcmid = $this-&gt;get_mappingid('course_module', $oldcmid);<br /> $newsectionid = $this-&gt;get_mappingid('course_section', $oldsectionid);<br /> <br /> These functions will return false if the relevant course-module or section has not yet been restored.<br /> <br /> === The solution ===<br /> <br /> You can have a method called &lt;tt&gt;after_restore&lt;/tt&gt; inside your TASK (not step) class, &lt;tt&gt;restore_mymodule_activity_task&lt;/tt&gt;.<br /> <br /> public function after_restore() {<br /> // Do something at end of restore<br /> }<br /> <br /> In this method you can carry out necessary finishing tasks such as updating course-module and section IDs (using code like the above).<br /> <br /> The function will be called once per activity that was restored (for example, if you put this code into forum restore, and there are four forums on the website being restored, then it will be called four times). You can use the &lt;tt&gt;get_activityid&lt;/tt&gt; method to return the current activity ID (other functions such as &lt;tt&gt;get_courseid&lt;/tt&gt; are also available).<br /> <br /> === Warning ===<br /> <br /> You should do as little as possible in this method, and be aware that using it may mean your activity module does not function correctly in some cases.<br /> <br /> * It is possible to backup and restore a single module, or a section, rather than a whole course. <br /> * This function (backing up a single module) may also be used to support other upcoming features such as the 'copy activity' feature.<br /> <br /> If somebody backs up your activity as a single activity, then obviously any such dependencies will not be included. There is currently no way to indicate that your module has any dependencies. So the backup and restore will go ahead but, once again, the &lt;tt&gt;get_mappingid&lt;/tt&gt; function will return false.<br /> <br /> At present the best way to handle this is to add a message to the restore log (which will not currently be displayed anywhere, but this might change):<br /> <br /> $this-&gt;get_logger()-&gt;process(&quot;Failed to restore dependency in mymodule '$name'. &quot; .<br /> &quot;Backup and restore will not work correctly unless you include the dependent module.&quot;,<br /> backup::LOG_ERROR);</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=ctags&diff=53038 2017-10-16T05:42:06Z

<p>Ankitfrenz: </p> <hr /> <div>== Moodle 3.4 and newer ==<br /> As of Moodle 3.4 tags.txt file is completely removed from core, use features of your respective editors.<br /> <br /> == Moodle 1.9.6 and newer ==<br /> As of Moodle 1.9.6 the tags file is no longer included in the Moodle distribution. Instead a file tags.txt is included providing instructions on creating the tag file yourself. The text of this file is as follows:<br /> <br /> &lt;pre&gt;<br /> Generating a tags file<br /> ======================<br /> <br /> If you need a tags file so that you can jump around Moodle code<br /> easily in your editor (eg vim or emacs), you can generate one:<br /> <br /> Exuberant ctags (default on Linux, can be compiled on other platforms):<br /> ----------------------------------------------------------------------<br /> <br /> ctags -R --languages=php --php-kinds=f \<br /> --regex-PHP='/abstract +class +([^ ]*)/\1/c/' \<br /> --regex-PHP='/interface +([^ ]*)/\1/c/' \<br /> --regex-PHP='/(public |static |abstract |protected |private )+ *function +([^ (]*)/\2/f/'<br /> <br /> BSD ctags (Default on Mac OS X):<br /> -------------------------------<br /> <br /> (TODO)<br /> &lt;/pre&gt;<br /> <br /> == Using tags with Vim ==<br /> <br /> In order to use the tags file with the Vim editor (on a Unix style system), you should first add the following line to the file '''.vimrc''' in your home directory:<br /> <br /> set tags=tags;/<br /> <br /> If .vimrc does not exist you should create it. This directive will force Vim to search for the tags file in the directory tree in which you are working (it searches up from where you are) so it will work for multiple versions of the code automatically.<br /> <br /> === How to jump to a tag with Vim ===<br /> <br /> There are a number of things you can do:<br /> <br /> * Place the cursor over the tag (e.g., function name) and press '''CTRL+]'''.<br /> * Type the command ''':tag &lt;tagname&gt;'''<br /> * To open in a new editor window type the command ''':stag &lt;tagname&gt;'''<br /> * To return to your previous location type '''CTRL+t'''<br /> <br /> == Using tags with Emacs ==<br /> To create the TAGS file add a -e to the command of tags.txt, like this:<br /> &lt;pre&gt;<br /> ctags -e -R --languages=php --exclude=&quot;CVS&quot; --php-kinds=f \<br /> --regex-PHP='/abstract class ([^ ]*)/\1/c/' \<br /> --regex-PHP='/interface ([^ ]*)/\1/c/' \<br /> --regex-PHP='/(public |static |abstract |protected |private )+function ([^ (]*)/\2/f/'<br /> &lt;/pre&gt;<br /> <br /> For instructions about how to use it look to the emacs wiki page [http://www.emacswiki.org/emacs/EmacsTags EmacsTags]<br /> <br /> ==See also==<br /> <br /> * [http://www.vim.org/tips/tip.php?tip_id=94 Vim tags usage tip]<br /> * [http://vimdoc.sourceforge.net/htmldoc/usr_29.html#29.1 Vim documentation: Using tags]<br /> * [http://vimdoc.sourceforge.net/htmldoc/tagsrch.html Vim documentation: Tags and special searches]<br /> <br /> [[Category:Developer tools]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Moodle_libraries_credits&diff=53037 2017-10-16T05:36:55Z

<p>Ankitfrenz: /* PHP Markdown */</p> <hr /> <div>Some of Moodle's libraries were written by other people, and are being redistributed as part of Moodle under their respective open source licenses that thankfully allow us to do so. Thanks to the authors of all these excellent products - without them Moodle would be missing important functionality. Copyright information for each package is included below:<br /> <br /> ==ADOdb==<br /> <br /> ''lib/adodb''<br /> <br /> Database abstraction library for MySQL, PostgreSQL, MSSQL, Oracle, Interbase, Foxpro, Access, ADO, Sybase, DB2 and ODBC.<br /> <br /> Version: 5.20.9<br /> <br /> @copyright (c) 2000-2013 John Lim (jlim#natsoft.com). All rights reserved.<br /> <br /> @copyright (c) 2014 Damien Regad, Mark Newnham and the ADOdb community<br /> <br /> License: Dual LGPL and BSD-style<br /> <br /> http://adodb.sourceforge.net<br /> <br /> ==Amazon S3==<br /> <br /> ''repository/s3/S3.php''<br /> <br /> A standalone Amazon S3 (REST) client for PHP 5.2.x using CURL that does not require PEAR. <br /> <br /> Version: 0.5.1<br /> <br /> Copyright (c) 2013, Donovan Schönknecht<br /> <br /> License: BSD 2-Clause<br /> <br /> https://github.com/tpyo/amazon-s3-php-class/releases<br /> <br /> ==CAS==<br /> <br /> ''auth/cas/CAS''<br /> <br /> phpCAS library to support CAS authentication plugin<br /> <br /> Copyright Jasig<br /> <br /> License: Apache License 2.0<br /> <br /> https://wiki.jasig.org/display/CASC/phpCAS<br /> <br /> ==Chart.js==<br /> <br /> ''lib/amd/src/chartjs-lazy.js''<br /> <br /> Simple yet flexible JavaScript charting for designers &amp; developers<br /> <br /> Version: 2.2.2<br /> <br /> Copyright 2016 Nick Downie<br /> <br /> License: MIT<br /> <br /> http://www.chartjs.org<br /> <br /> ==EvalMath==<br /> <br /> ''lib/evalmath''<br /> <br /> Class to safely evaluate math expressions<br /> <br /> Copyright Miles Kaufmann<br /> <br /> License: BSD<br /> <br /> http://www.twmagic.com/<br /> <br /> ==FLV player==<br /> <br /> ''filter/mediaplugin/flvplayer.swf''<br /> <br /> Flash movie to play FLV files<br /> <br /> Copyright Jeroen Wijering <br /> <br /> License: GNU GPL<br /> <br /> http://www.jeroenwijering.com<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==FPDF Class==<br /> <br /> ''lib/fpdf''<br /> <br /> Class to generate PDF files<br /> <br /> Version: 1.54<br /> <br /> Copyright Olivier PLATHEY<br /> <br /> License: Freeware<br /> <br /> http://www.setasign.com/products/fpdi/downloads<br /> <br /> == GeoIp2 ==<br /> <br /> ''lib/maxmind/GeoIp2''<br /> <br /> Library for precessing of GeoIP data files<br /> <br /> Version: 2.6.0<br /> <br /> Copyright MaxMind<br /> <br /> License: Apache 2.0<br /> <br /> https://github.com/maxmind/GeoIP2-php<br /> <br /> ==Google APIs==<br /> <br /> &quot;lib/google&quot;<br /> <br /> Library Google APIs Client Library for PHP<br /> <br /> Version: 1.1.7<br /> <br /> License: Apache License Version 2.0<br /> <br /> https://github.com/google/google-api-php-client<br /> <br /> ==Graph Class==<br /> <br /> ''lib/graphlib.php''<br /> <br /> Class to draw line, point, bar, and area graphs, including numeric x-axis and double y-axis.<br /> <br /> Version: 1.6.3 (with modifications)<br /> <br /> Copyright © 2000 Herman Veluwenkamp (''hermanV AT mindless DOT com'')<br /> <br /> License: LGPL<br /> <br /> ==Horde==<br /> <br /> ''lib/horde''<br /> <br /> Library used by the inbound e-mail handling system.<br /> <br /> Version: 5.2.7<br /> <br /> Copyright © Horde LLC<br /> <br /> License: LGPL<br /> <br /> http://www.horde.org/<br /> <br /> ==html2text==<br /> <br /> ''lib/html2text''<br /> <br /> PHP script to convert HTML into an approximate text equivalent<br /> <br /> Version: 4.0.1<br /> <br /> Copyright © 2005-7 Jon Abernathy<br /> <br /> License: GNU GPL<br /> <br /> https://github.com/mtibben/html2text.git<br /> <br /> ==htmlArea==<br /> <br /> ''lib/editor''<br /> <br /> Javascript/HTML script to put a GUI editor in textareas on Internet Explorer and Mozilla<br /> <br /> Version: 3.0 beta (with modifications)<br /> <br /> Copyright © 2002 interactivetools.com, inc.<br /> <br /> License: htmlArea License (based on BSD license)<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==HTML Purifier==<br /> <br /> &quot;lib/htmlpurifier&quot;<br /> <br /> Filters HTML.<br /> <br /> Version: 4.8.0<br /> <br /> License: LGPL<br /> <br /> ==IP-Atlas==<br /> <br /> ''lib/ipatlas''<br /> <br /> PHP scripts to show the location of an IP address on a map.<br /> <br /> Version: 1.0 (with modifications)<br /> <br /> Copyright © 2002 Ivan Kozik<br /> <br /> License: GNU GPL<br /> <br /> http://www.xpenguin.com/ip-atlas.php<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==jQuery==<br /> <br /> ''lib/jquery''<br /> <br /> jQuery is a fast, small, and feature-rich JavaScript library widely used on moodle.<br /> <br /> Version: 1.12.3<br /> <br /> Copyright: 2016 The jQuery Foundation<br /> <br /> License: MIT<br /> <br /> https://jquery.com<br /> <br /> ==jQuery migrate==<br /> <br /> ''lib/jquery/jquery-migrate-1.4.0.js''<br /> <br /> Library used migrate older jQuery code to jQuery 3.0.<br /> <br /> Version: 1.4.0<br /> <br /> Copyright: 2016 The jQuery Foundation and other contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/jquery/jquery-migrate<br /> <br /> ==jQuery UI==<br /> <br /> ''lib/jquery/ui-1.12.1/''<br /> <br /> jQuery UI is a set of user interface interactions, effects, widgets, and themes built on top of the jQuery library.<br /> <br /> Version: 1.12.1<br /> <br /> Copyright: 2016 The jQuery Foundation and other contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/jquery/jquery-migrate<br /> <br /> ==Services_JSON==<br /> <br /> ''lib/json''<br /> <br /> Allows PHP-&gt;JS communication via JSON<br /> <br /> Version: 1.3.1<br /> <br /> Copyright © 2005 Michal Migurski<br /> <br /> License: Modified BSD (GPL-compatible)<br /> <br /> http://pear.php.net/pepr/pepr-proposal-show.php?id=198<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==kses==<br /> <br /> ''lib/kses.php''<br /> <br /> HTML/XHTML filter that only allows some elements and attributes<br /> <br /> Version: 0.2.2<br /> <br /> Copyright © 2002, 2003, 2005 Ulf Harnhammar<br /> <br /> License: GNU GPL<br /> <br /> http://sourceforge.net/projects/kses<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==less.php==<br /> <br /> The less.php is a PHP port of the official LESS processor used by moodle themes.<br /> <br /> ''lib/lessphp''<br /> <br /> Version: 1.7.0.10<br /> <br /> License: Apache 2.0<br /> <br /> http://lessphp.typesettercms.com/<br /> <br /> Copyright: Matt Agar and Martin Jantošovič<br /> ==loglevel.js==<br /> <br /> Minimal lightweight simple logging for JavaScript.<br /> <br /> Version 1.4.1<br /> <br /> Copyright (c) 2013 Tim Perry<br /> <br /> License: MIT<br /> <br /> https://github.com/pimterry/loglevel/<br /> ==MathJax==<br /> <br /> &quot;Not actually included in Moodle. Moodle instead has a setting where the mathjax library is located. It is currently pointing to CDN by default.&quot;<br /> <br /> JavaScript filter library for displaying LaTeX, AsciiMath notation, and MathML.<br /> <br /> Version 2.7<br /> <br /> © Copyright 2015 The MathJax Consortium.<br /> <br /> License: Apache V2.0<br /> <br /> https://github.com/mathjax/MathJax<br /> <br /> ==MatthiasMullie\Minify==<br /> CSS &amp; JavaScript minifier, in PHP<br /> <br /> Version 1.3.37<br /> <br /> License: MIT<br /> <br /> https://github.com/matthiasmullie/minify<br /> <br /> ==mimeTeX==<br /> <br /> ''filter/tex''<br /> <br /> Compiled C program to convert TeX into GIFs<br /> <br /> Version: 1.4<br /> <br /> Copyright © 2002-2004 John Forkosh Associates, Inc<br /> <br /> License: GNU GPL<br /> <br /> http://www.forkosh.com/mimetex.html<br /> <br /> ==Mustache.js==<br /> <br /> &quot;lib/amd/src/mustache.js&quot;<br /> <br /> JS library for displaying mustache templates.<br /> <br /> Version: 2.2.1<br /> <br /> Copyright (c) 2009 Chris Wanstrath (Ruby)<br /> <br /> Copyright (c) 2010-2014 Jan Lehnardt (JavaScript)<br /> <br /> Copyright (c) 2010-2015 The mustache.js community<br /> <br /> License: MIT<br /> <br /> https://github.com/janl/mustache.js/releases<br /> <br /> ==Mustache==<br /> <br /> &quot;lib/mustache&quot;<br /> <br /> PHP library for displaying mustache templates.<br /> <br /> Version: 2.11.1<br /> <br /> Copyright (c) 2010-2016 Justin Hileman<br /> <br /> License: MIT<br /> <br /> https://github.com/bobthecow/mustache.php/releases<br /> <br /> ==mp3player==<br /> <br /> ''lib/mp3player''<br /> <br /> Flash movie to play streaming MP3s<br /> <br /> Copyright © 2005 Andrew Walker<br /> <br /> License: GNU GPL<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==overlibmws==<br /> <br /> ''lib/overlib.js''<br /> <br /> Javascript library to enable DHTML popups, floating windows, events etc<br /> <br /> Version: July 2004<br /> <br /> Copyright © 2002-2004 Foteos Macrides<br /> <br /> Copyright © 1998-2004 Erik Bosrup<br /> <br /> License: Artistic Open Source License<br /> <br /> http://www.macridesweb.com/oltest/<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PclZip==<br /> <br /> ''lib/pclzip''<br /> <br /> Class to create, manage and unpack zip files.<br /> <br /> Version: 2.4 RC1<br /> <br /> Copyright © 2004 Vincent Blavet (''vincent AT phpconcept DOT net'')<br /> <br /> License: GNU GPL<br /> <br /> http://www.phpconcept.net<br /> <br /> ==PEAR OLE Classes==<br /> <br /> ''lib/pear''<br /> <br /> Class to write Excel files<br /> <br /> Version: 0.5<br /> <br /> Copyright © 2004 Xavier Noguer<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/OLE<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PEAR Spreadsheet_Excel_Writer==<br /> <br /> ''lib/pear''<br /> <br /> Class to write Excel files<br /> <br /> Version: 0.9.1<br /> <br /> Copyright © 2004 Xavier Noguer and Mika Tuupola<br /> <br /> License: LGPL<br /> <br /> http://pear.php.net/package/Spreadsheet_Excel_Writer<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PEAR HTML_Quickform==<br /> <br /> ''lib/pear''<br /> <br /> Class to write forms<br /> <br /> Version: 3.2.6<br /> <br /> Copyright © 2004 Bertrand Mansion, Adam Daniel, Alexey Borzov<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Quickform<br /> <br /> ==PEAR HTML_Quickform_Renderer_Tableless==<br /> <br /> ''lib/pear''<br /> <br /> Class to render forms without tables<br /> <br /> Version: 0.3.4<br /> <br /> Copyright © 2005 Mark Wiesemann<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Quickform_Renderer_Tableless<br /> <br /> ==PEAR HTML_QuickForm_DHTMLRulesTableless==<br /> <br /> ''lib/pear''<br /> <br /> Class to render validation notices with dhtml<br /> <br /> Version: 0.1.2<br /> <br /> Copyright © 2005 Alexey Borzov, Adam Daniel, Bertrand Mansion, Justin Patrin, Mark Wiesemann<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_QuickForm_DHTMLRulesTableless<br /> <br /> ==PEAR HTML_Common==<br /> <br /> ''lib/pear''<br /> <br /> Class with many common HTML functions (used by HTML Quickform)<br /> <br /> Version: 0.3.4<br /> <br /> Copyright © 2004 Adam Daniel, Bertrand Mansion, Klaus Guenther, Alexey Borzov<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Common<br /> <br /> ==PEAR XML_Parser==<br /> <br /> ''lib/pear''<br /> <br /> Class implementing one handy (sax-expat) XML parser<br /> <br /> Version: 1.3.2<br /> <br /> Copyright © 2004-2008 The PHP Group &amp; Stephan Schmidt<br /> <br /> License: New BSD License<br /> <br /> http://pear.php.net/package/XML_Parser<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PHP-CSS-Parser==<br /> <br /> ''lib/php-css-parser''<br /> <br /> A Parser for CSS Files written in PHP.<br /> <br /> Version: 8.1.0<br /> <br /> Copyright (c) 2011 Raphael Schweikert, http://sabberworm.com/<br /> <br /> License: MIT<br /> <br /> https://github.com/sabberworm/PHP-CSS-Parser<br /> <br /> ==PHPExcel==<br /> <br /> ''lib/phpexcel/PHPExcel.php''<br /> <br /> Library to read, write and create spreadsheet documents in PHP.<br /> <br /> Version 1.8.1<br /> <br /> Copyright © 2006 - 2015 PHPExcel<br /> License: LGPL<br /> <br /> https://github.com/PHPOffice/PHPExcel<br /> <br /> ==PHP mailer==<br /> <br /> ''lib/class.phpmailer.php''<br /> <br /> Class for sending email using either sendmail, PHP mail(), or SMTP. Methods are based upon the standard AspEmail(tm) classes.<br /> <br /> Version 5.2.16<br /> <br /> Copyright © 2003 Brent R. Matzelle (''bmatzelle AT yahoo DOT com'')<br /> License: LGPL<br /> <br /> http://phpmailer.sourceforge.net<br /> https://github.com/PHPMailer/PHPMailer/releases<br /> <br /> ==PHP Markdown==<br /> <br /> ''lib/markdown.php''<br /> <br /> Functions to convert from the Markdown text format into clean XHTML.<br /> <br /> Version: 1.7.0 (with modifications)<br /> <br /> * @copyright 2004-2016 Michel Fortin &lt;https://michelf.com/projects/php-markdown/&gt;<br /> <br /> * @copyright (Original Markdown) 2004-2006 John Gruber &lt;https://daringfireball.net/projects/markdown/&gt;<br /> All rights reserved.<br /> <br /> License: BSD<br /> <br /> http://www.michelf.com/projects/php-markdown/<br /> <br /> ==RequireJS==<br /> <br /> ''/lib/requirejs/'' <br /> <br /> RequireJS is a JavaScript file and module loader.<br /> <br /> Version 2.3.2<br /> <br /> License: new BSD or MIT<br /> <br /> http://requirejs.org/<br /> <br /> ==scssphp==<br /> <br /> ''/lib/scssphp/'' <br /> <br /> scssphp is a compiler for SCSS written in PHP.<br /> <br /> Version: 0.6.5<br /> <br /> Copyright (c) 2015 Leaf Corcoran<br /> <br /> License: MIT<br /> <br /> http://leafo.github.io/scssphp<br /> <br /> ==SimplePie==<br /> <br /> &quot;/lib/simplepie&quot;<br /> <br /> Simple Pie helps with blogs.<br /> <br /> Version 1.4.2<br /> <br /> License: BSD<br /> <br /> https://github.com/simplepie/simplepie<br /> <br /> ==Snoopy==<br /> <br /> ''lib/snoopy''<br /> <br /> A PHP net client<br /> <br /> Version: 1.0<br /> <br /> Copyright © 1999-2000 Monte Ohrt (''monte AT ispi DOT net'')<br /> License: GNU LGPL<br /> <br /> http://snoopy.sourceforge.com<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==SMTP class==<br /> <br /> ''lib/class.smtp.php''<br /> <br /> Class that can be used to connect and communicate with any SMTP server. It implements all the SMTP functions defined in RFC821 except TURN.<br /> <br /> Version: 03/26/2001<br /> <br /> Copyright © 2001 Chris Ryan (''chris AT greatbridge DOT com'')<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==Spike PHPCoverage==<br /> <br /> ''lib/spikephpcoverage''<br /> <br /> PHP code coverage reporting tool<br /> <br /> Version: 0.8.2 (with modifications)<br /> <br /> Copyright © 2004 SpikeSource Inc<br /> <br /> License: LGPL<br /> <br /> http://developer.spikesource.com/projects/phpcoverage<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==Spout==<br /> <br /> &quot;lib/spout&quot;<br /> <br /> Library for importing and exporting csv / excel / ODS files.<br /> <br /> Version 2.7.3<br /> <br /> License: Apache<br /> <br /> https://github.com/box/spout/<br /> <br /> ==Typo3 Character Set Class==<br /> <br /> ''lib/typo3''<br /> <br /> Class for conversion between charsets and multibyte-savy operations with strings.<br /> <br /> Version: 4.7.19<br /> <br /> Copyright © 2003-2005 Kasper Skaarhoj<br /> <br /> Licence: GNU GPL<br /> <br /> http://typo3.org/<br /> <br /> ==Yahoo User Interface==<br /> <br /> ''lib/yui''<br /> <br /> The Yahoo! User Interface Library is a set of utilities and controls, in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, DHTML and AJAX. The YUI Library also includes several core CSS resources.Set of user-interface components using AJAX, DHTML etc. We use it for all our AJAX-related stuff.<br /> <br /> CVS version: 2.3.0<br /> <br /> Copyright (c) 2006, Yahoo! Inc.<br /> <br /> Licence: BSD<br /> <br /> http://developer.yahoo.com/yui/<br /> <br /> ==Mustache.js==<br /> <br /> &quot;lib/amd/src/mustache.js&quot;<br /> <br /> JS library for displaying mustache templates.<br /> <br /> Version: 2.2.1<br /> <br /> Copyright (c) 2009 Chris Wanstrath (Ruby)<br /> <br /> Copyright (c) 2010-2014 Jan Lehnardt (JavaScript)<br /> <br /> Copyright (c) 2010-2015 The mustache.js community<br /> <br /> License: MIT<br /> <br /> https://github.com/janl/mustache.js/releases<br /> <br /> ==LTI Tool Provider Library for PHP==<br /> <br /> &quot;lib/ltiprovider/&quot;<br /> <br /> PHP library for communicating with learning tools as per the LTI specification.<br /> <br /> Version: 3.0.2<br /> <br /> © 2016 IMS Global Learning Consortium Inc. All Rights Reserved. Trademark Policy - (www.imsglobal.org/trademarks)<br /> <br /> License: Apache 2<br /> <br /> https://github.com/IMSGlobal/LTI-Tool-Provider-Library-PHP<br /> <br /> <br /> ==Popper.js==<br /> <br /> &quot;admin/tool/usertours/amd/src/popper.js&quot;<br /> <br /> A kickass library used to created Poppers in web applications<br /> <br /> © 2016 Federico Zivolo and contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/FezVrasta/popper.js<br /> <br /> ==Flexitour==<br /> <br /> &quot;admin/tool/usertours/amd/src/tour.js&quot;<br /> <br /> A JS library for tours<br /> <br /> © 2016 Andrew Nicols and contributors<br /> <br /> License: GPLv3<br /> <br /> https://github.com/andrewnicols/flexitour<br /> <br /> [[Category:Credits]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Moodle_libraries_credits&diff=53036 2017-10-16T05:32:58Z

<p>Ankitfrenz: /* Spout */</p> <hr /> <div>Some of Moodle's libraries were written by other people, and are being redistributed as part of Moodle under their respective open source licenses that thankfully allow us to do so. Thanks to the authors of all these excellent products - without them Moodle would be missing important functionality. Copyright information for each package is included below:<br /> <br /> ==ADOdb==<br /> <br /> ''lib/adodb''<br /> <br /> Database abstraction library for MySQL, PostgreSQL, MSSQL, Oracle, Interbase, Foxpro, Access, ADO, Sybase, DB2 and ODBC.<br /> <br /> Version: 5.20.9<br /> <br /> @copyright (c) 2000-2013 John Lim (jlim#natsoft.com). All rights reserved.<br /> <br /> @copyright (c) 2014 Damien Regad, Mark Newnham and the ADOdb community<br /> <br /> License: Dual LGPL and BSD-style<br /> <br /> http://adodb.sourceforge.net<br /> <br /> ==Amazon S3==<br /> <br /> ''repository/s3/S3.php''<br /> <br /> A standalone Amazon S3 (REST) client for PHP 5.2.x using CURL that does not require PEAR. <br /> <br /> Version: 0.5.1<br /> <br /> Copyright (c) 2013, Donovan Schönknecht<br /> <br /> License: BSD 2-Clause<br /> <br /> https://github.com/tpyo/amazon-s3-php-class/releases<br /> <br /> ==CAS==<br /> <br /> ''auth/cas/CAS''<br /> <br /> phpCAS library to support CAS authentication plugin<br /> <br /> Copyright Jasig<br /> <br /> License: Apache License 2.0<br /> <br /> https://wiki.jasig.org/display/CASC/phpCAS<br /> <br /> ==Chart.js==<br /> <br /> ''lib/amd/src/chartjs-lazy.js''<br /> <br /> Simple yet flexible JavaScript charting for designers &amp; developers<br /> <br /> Version: 2.2.2<br /> <br /> Copyright 2016 Nick Downie<br /> <br /> License: MIT<br /> <br /> http://www.chartjs.org<br /> <br /> ==EvalMath==<br /> <br /> ''lib/evalmath''<br /> <br /> Class to safely evaluate math expressions<br /> <br /> Copyright Miles Kaufmann<br /> <br /> License: BSD<br /> <br /> http://www.twmagic.com/<br /> <br /> ==FLV player==<br /> <br /> ''filter/mediaplugin/flvplayer.swf''<br /> <br /> Flash movie to play FLV files<br /> <br /> Copyright Jeroen Wijering <br /> <br /> License: GNU GPL<br /> <br /> http://www.jeroenwijering.com<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==FPDF Class==<br /> <br /> ''lib/fpdf''<br /> <br /> Class to generate PDF files<br /> <br /> Version: 1.54<br /> <br /> Copyright Olivier PLATHEY<br /> <br /> License: Freeware<br /> <br /> http://www.setasign.com/products/fpdi/downloads<br /> <br /> == GeoIp2 ==<br /> <br /> ''lib/maxmind/GeoIp2''<br /> <br /> Library for precessing of GeoIP data files<br /> <br /> Version: 2.6.0<br /> <br /> Copyright MaxMind<br /> <br /> License: Apache 2.0<br /> <br /> https://github.com/maxmind/GeoIP2-php<br /> <br /> ==Google APIs==<br /> <br /> &quot;lib/google&quot;<br /> <br /> Library Google APIs Client Library for PHP<br /> <br /> Version: 1.1.7<br /> <br /> License: Apache License Version 2.0<br /> <br /> https://github.com/google/google-api-php-client<br /> <br /> ==Graph Class==<br /> <br /> ''lib/graphlib.php''<br /> <br /> Class to draw line, point, bar, and area graphs, including numeric x-axis and double y-axis.<br /> <br /> Version: 1.6.3 (with modifications)<br /> <br /> Copyright © 2000 Herman Veluwenkamp (''hermanV AT mindless DOT com'')<br /> <br /> License: LGPL<br /> <br /> ==Horde==<br /> <br /> ''lib/horde''<br /> <br /> Library used by the inbound e-mail handling system.<br /> <br /> Version: 5.2.7<br /> <br /> Copyright © Horde LLC<br /> <br /> License: LGPL<br /> <br /> http://www.horde.org/<br /> <br /> ==html2text==<br /> <br /> ''lib/html2text''<br /> <br /> PHP script to convert HTML into an approximate text equivalent<br /> <br /> Version: 4.0.1<br /> <br /> Copyright © 2005-7 Jon Abernathy<br /> <br /> License: GNU GPL<br /> <br /> https://github.com/mtibben/html2text.git<br /> <br /> ==htmlArea==<br /> <br /> ''lib/editor''<br /> <br /> Javascript/HTML script to put a GUI editor in textareas on Internet Explorer and Mozilla<br /> <br /> Version: 3.0 beta (with modifications)<br /> <br /> Copyright © 2002 interactivetools.com, inc.<br /> <br /> License: htmlArea License (based on BSD license)<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==HTML Purifier==<br /> <br /> &quot;lib/htmlpurifier&quot;<br /> <br /> Filters HTML.<br /> <br /> Version: 4.8.0<br /> <br /> License: LGPL<br /> <br /> ==IP-Atlas==<br /> <br /> ''lib/ipatlas''<br /> <br /> PHP scripts to show the location of an IP address on a map.<br /> <br /> Version: 1.0 (with modifications)<br /> <br /> Copyright © 2002 Ivan Kozik<br /> <br /> License: GNU GPL<br /> <br /> http://www.xpenguin.com/ip-atlas.php<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==jQuery==<br /> <br /> ''lib/jquery''<br /> <br /> jQuery is a fast, small, and feature-rich JavaScript library widely used on moodle.<br /> <br /> Version: 1.12.3<br /> <br /> Copyright: 2016 The jQuery Foundation<br /> <br /> License: MIT<br /> <br /> https://jquery.com<br /> <br /> ==jQuery migrate==<br /> <br /> ''lib/jquery/jquery-migrate-1.4.0.js''<br /> <br /> Library used migrate older jQuery code to jQuery 3.0.<br /> <br /> Version: 1.4.0<br /> <br /> Copyright: 2016 The jQuery Foundation and other contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/jquery/jquery-migrate<br /> <br /> ==jQuery UI==<br /> <br /> ''lib/jquery/ui-1.12.1/''<br /> <br /> jQuery UI is a set of user interface interactions, effects, widgets, and themes built on top of the jQuery library.<br /> <br /> Version: 1.12.1<br /> <br /> Copyright: 2016 The jQuery Foundation and other contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/jquery/jquery-migrate<br /> <br /> ==Services_JSON==<br /> <br /> ''lib/json''<br /> <br /> Allows PHP-&gt;JS communication via JSON<br /> <br /> Version: 1.3.1<br /> <br /> Copyright © 2005 Michal Migurski<br /> <br /> License: Modified BSD (GPL-compatible)<br /> <br /> http://pear.php.net/pepr/pepr-proposal-show.php?id=198<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==kses==<br /> <br /> ''lib/kses.php''<br /> <br /> HTML/XHTML filter that only allows some elements and attributes<br /> <br /> Version: 0.2.2<br /> <br /> Copyright © 2002, 2003, 2005 Ulf Harnhammar<br /> <br /> License: GNU GPL<br /> <br /> http://sourceforge.net/projects/kses<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==less.php==<br /> <br /> The less.php is a PHP port of the official LESS processor used by moodle themes.<br /> <br /> ''lib/lessphp''<br /> <br /> Version: 1.7.0.10<br /> <br /> License: Apache 2.0<br /> <br /> http://lessphp.typesettercms.com/<br /> <br /> Copyright: Matt Agar and Martin Jantošovič<br /> ==loglevel.js==<br /> <br /> Minimal lightweight simple logging for JavaScript.<br /> <br /> Version 1.4.1<br /> <br /> Copyright (c) 2013 Tim Perry<br /> <br /> License: MIT<br /> <br /> https://github.com/pimterry/loglevel/<br /> ==MathJax==<br /> <br /> &quot;Not actually included in Moodle. Moodle instead has a setting where the mathjax library is located. It is currently pointing to CDN by default.&quot;<br /> <br /> JavaScript filter library for displaying LaTeX, AsciiMath notation, and MathML.<br /> <br /> Version 2.7<br /> <br /> © Copyright 2015 The MathJax Consortium.<br /> <br /> License: Apache V2.0<br /> <br /> https://github.com/mathjax/MathJax<br /> <br /> ==MatthiasMullie\Minify==<br /> CSS &amp; JavaScript minifier, in PHP<br /> <br /> Version 1.3.37<br /> <br /> License: MIT<br /> <br /> https://github.com/matthiasmullie/minify<br /> <br /> ==mimeTeX==<br /> <br /> ''filter/tex''<br /> <br /> Compiled C program to convert TeX into GIFs<br /> <br /> Version: 1.4<br /> <br /> Copyright © 2002-2004 John Forkosh Associates, Inc<br /> <br /> License: GNU GPL<br /> <br /> http://www.forkosh.com/mimetex.html<br /> <br /> ==Mustache.js==<br /> <br /> &quot;lib/amd/src/mustache.js&quot;<br /> <br /> JS library for displaying mustache templates.<br /> <br /> Version: 2.2.1<br /> <br /> Copyright (c) 2009 Chris Wanstrath (Ruby)<br /> <br /> Copyright (c) 2010-2014 Jan Lehnardt (JavaScript)<br /> <br /> Copyright (c) 2010-2015 The mustache.js community<br /> <br /> License: MIT<br /> <br /> https://github.com/janl/mustache.js/releases<br /> <br /> ==Mustache==<br /> <br /> &quot;lib/mustache&quot;<br /> <br /> PHP library for displaying mustache templates.<br /> <br /> Version: 2.11.1<br /> <br /> Copyright (c) 2010-2016 Justin Hileman<br /> <br /> License: MIT<br /> <br /> https://github.com/bobthecow/mustache.php/releases<br /> <br /> ==mp3player==<br /> <br /> ''lib/mp3player''<br /> <br /> Flash movie to play streaming MP3s<br /> <br /> Copyright © 2005 Andrew Walker<br /> <br /> License: GNU GPL<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==overlibmws==<br /> <br /> ''lib/overlib.js''<br /> <br /> Javascript library to enable DHTML popups, floating windows, events etc<br /> <br /> Version: July 2004<br /> <br /> Copyright © 2002-2004 Foteos Macrides<br /> <br /> Copyright © 1998-2004 Erik Bosrup<br /> <br /> License: Artistic Open Source License<br /> <br /> http://www.macridesweb.com/oltest/<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PclZip==<br /> <br /> ''lib/pclzip''<br /> <br /> Class to create, manage and unpack zip files.<br /> <br /> Version: 2.4 RC1<br /> <br /> Copyright © 2004 Vincent Blavet (''vincent AT phpconcept DOT net'')<br /> <br /> License: GNU GPL<br /> <br /> http://www.phpconcept.net<br /> <br /> ==PEAR OLE Classes==<br /> <br /> ''lib/pear''<br /> <br /> Class to write Excel files<br /> <br /> Version: 0.5<br /> <br /> Copyright © 2004 Xavier Noguer<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/OLE<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PEAR Spreadsheet_Excel_Writer==<br /> <br /> ''lib/pear''<br /> <br /> Class to write Excel files<br /> <br /> Version: 0.9.1<br /> <br /> Copyright © 2004 Xavier Noguer and Mika Tuupola<br /> <br /> License: LGPL<br /> <br /> http://pear.php.net/package/Spreadsheet_Excel_Writer<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PEAR HTML_Quickform==<br /> <br /> ''lib/pear''<br /> <br /> Class to write forms<br /> <br /> Version: 3.2.6<br /> <br /> Copyright © 2004 Bertrand Mansion, Adam Daniel, Alexey Borzov<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Quickform<br /> <br /> ==PEAR HTML_Quickform_Renderer_Tableless==<br /> <br /> ''lib/pear''<br /> <br /> Class to render forms without tables<br /> <br /> Version: 0.3.4<br /> <br /> Copyright © 2005 Mark Wiesemann<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Quickform_Renderer_Tableless<br /> <br /> ==PEAR HTML_QuickForm_DHTMLRulesTableless==<br /> <br /> ''lib/pear''<br /> <br /> Class to render validation notices with dhtml<br /> <br /> Version: 0.1.2<br /> <br /> Copyright © 2005 Alexey Borzov, Adam Daniel, Bertrand Mansion, Justin Patrin, Mark Wiesemann<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_QuickForm_DHTMLRulesTableless<br /> <br /> ==PEAR HTML_Common==<br /> <br /> ''lib/pear''<br /> <br /> Class with many common HTML functions (used by HTML Quickform)<br /> <br /> Version: 0.3.4<br /> <br /> Copyright © 2004 Adam Daniel, Bertrand Mansion, Klaus Guenther, Alexey Borzov<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Common<br /> <br /> ==PEAR XML_Parser==<br /> <br /> ''lib/pear''<br /> <br /> Class implementing one handy (sax-expat) XML parser<br /> <br /> Version: 1.3.2<br /> <br /> Copyright © 2004-2008 The PHP Group &amp; Stephan Schmidt<br /> <br /> License: New BSD License<br /> <br /> http://pear.php.net/package/XML_Parser<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PHP-CSS-Parser==<br /> <br /> ''lib/php-css-parser''<br /> <br /> A Parser for CSS Files written in PHP.<br /> <br /> Version: 8.1.0<br /> <br /> Copyright (c) 2011 Raphael Schweikert, http://sabberworm.com/<br /> <br /> License: MIT<br /> <br /> https://github.com/sabberworm/PHP-CSS-Parser<br /> <br /> ==PHPExcel==<br /> <br /> ''lib/phpexcel/PHPExcel.php''<br /> <br /> Library to read, write and create spreadsheet documents in PHP.<br /> <br /> Version 1.8.1<br /> <br /> Copyright © 2006 - 2015 PHPExcel<br /> License: LGPL<br /> <br /> https://github.com/PHPOffice/PHPExcel<br /> <br /> ==PHP mailer==<br /> <br /> ''lib/class.phpmailer.php''<br /> <br /> Class for sending email using either sendmail, PHP mail(), or SMTP. Methods are based upon the standard AspEmail(tm) classes.<br /> <br /> Version 5.2.16<br /> <br /> Copyright © 2003 Brent R. Matzelle (''bmatzelle AT yahoo DOT com'')<br /> License: LGPL<br /> <br /> http://phpmailer.sourceforge.net<br /> https://github.com/PHPMailer/PHPMailer/releases<br /> <br /> ==PHP Markdown==<br /> <br /> ''lib/markdown.php''<br /> <br /> Functions to convert from the Markdown text format into clean XHTML.<br /> <br /> Version: 1.6.0 (with modifications)<br /> <br /> PHP Markdown Lib Copyright © 2004-2015 Michel Fortin https://michelf.ca/<br /> All rights reserved.<br /> <br /> Based on Markdown<br /> Copyright © 2003-2005 John Gruber https://daringfireball.net/<br /> All rights reserved.<br /> <br /> License: BSD<br /> <br /> http://www.michelf.com/projects/php-markdown/<br /> <br /> ==RequireJS==<br /> <br /> ''/lib/requirejs/'' <br /> <br /> RequireJS is a JavaScript file and module loader.<br /> <br /> Version 2.3.2<br /> <br /> License: new BSD or MIT<br /> <br /> http://requirejs.org/<br /> <br /> ==scssphp==<br /> <br /> ''/lib/scssphp/'' <br /> <br /> scssphp is a compiler for SCSS written in PHP.<br /> <br /> Version: 0.6.5<br /> <br /> Copyright (c) 2015 Leaf Corcoran<br /> <br /> License: MIT<br /> <br /> http://leafo.github.io/scssphp<br /> <br /> ==SimplePie==<br /> <br /> &quot;/lib/simplepie&quot;<br /> <br /> Simple Pie helps with blogs.<br /> <br /> Version 1.4.2<br /> <br /> License: BSD<br /> <br /> https://github.com/simplepie/simplepie<br /> <br /> ==Snoopy==<br /> <br /> ''lib/snoopy''<br /> <br /> A PHP net client<br /> <br /> Version: 1.0<br /> <br /> Copyright © 1999-2000 Monte Ohrt (''monte AT ispi DOT net'')<br /> License: GNU LGPL<br /> <br /> http://snoopy.sourceforge.com<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==SMTP class==<br /> <br /> ''lib/class.smtp.php''<br /> <br /> Class that can be used to connect and communicate with any SMTP server. It implements all the SMTP functions defined in RFC821 except TURN.<br /> <br /> Version: 03/26/2001<br /> <br /> Copyright © 2001 Chris Ryan (''chris AT greatbridge DOT com'')<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==Spike PHPCoverage==<br /> <br /> ''lib/spikephpcoverage''<br /> <br /> PHP code coverage reporting tool<br /> <br /> Version: 0.8.2 (with modifications)<br /> <br /> Copyright © 2004 SpikeSource Inc<br /> <br /> License: LGPL<br /> <br /> http://developer.spikesource.com/projects/phpcoverage<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==Spout==<br /> <br /> &quot;lib/spout&quot;<br /> <br /> Library for importing and exporting csv / excel / ODS files.<br /> <br /> Version 2.7.3<br /> <br /> License: Apache<br /> <br /> https://github.com/box/spout/<br /> <br /> ==Typo3 Character Set Class==<br /> <br /> ''lib/typo3''<br /> <br /> Class for conversion between charsets and multibyte-savy operations with strings.<br /> <br /> Version: 4.7.19<br /> <br /> Copyright © 2003-2005 Kasper Skaarhoj<br /> <br /> Licence: GNU GPL<br /> <br /> http://typo3.org/<br /> <br /> ==Yahoo User Interface==<br /> <br /> ''lib/yui''<br /> <br /> The Yahoo! User Interface Library is a set of utilities and controls, in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, DHTML and AJAX. The YUI Library also includes several core CSS resources.Set of user-interface components using AJAX, DHTML etc. We use it for all our AJAX-related stuff.<br /> <br /> CVS version: 2.3.0<br /> <br /> Copyright (c) 2006, Yahoo! Inc.<br /> <br /> Licence: BSD<br /> <br /> http://developer.yahoo.com/yui/<br /> <br /> ==Mustache.js==<br /> <br /> &quot;lib/amd/src/mustache.js&quot;<br /> <br /> JS library for displaying mustache templates.<br /> <br /> Version: 2.2.1<br /> <br /> Copyright (c) 2009 Chris Wanstrath (Ruby)<br /> <br /> Copyright (c) 2010-2014 Jan Lehnardt (JavaScript)<br /> <br /> Copyright (c) 2010-2015 The mustache.js community<br /> <br /> License: MIT<br /> <br /> https://github.com/janl/mustache.js/releases<br /> <br /> ==LTI Tool Provider Library for PHP==<br /> <br /> &quot;lib/ltiprovider/&quot;<br /> <br /> PHP library for communicating with learning tools as per the LTI specification.<br /> <br /> Version: 3.0.2<br /> <br /> © 2016 IMS Global Learning Consortium Inc. All Rights Reserved. Trademark Policy - (www.imsglobal.org/trademarks)<br /> <br /> License: Apache 2<br /> <br /> https://github.com/IMSGlobal/LTI-Tool-Provider-Library-PHP<br /> <br /> <br /> ==Popper.js==<br /> <br /> &quot;admin/tool/usertours/amd/src/popper.js&quot;<br /> <br /> A kickass library used to created Poppers in web applications<br /> <br /> © 2016 Federico Zivolo and contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/FezVrasta/popper.js<br /> <br /> ==Flexitour==<br /> <br /> &quot;admin/tool/usertours/amd/src/tour.js&quot;<br /> <br /> A JS library for tours<br /> <br /> © 2016 Andrew Nicols and contributors<br /> <br /> License: GPLv3<br /> <br /> https://github.com/andrewnicols/flexitour<br /> <br /> [[Category:Credits]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Moodle_libraries_credits&diff=53035 2017-10-16T05:31:30Z

<p>Ankitfrenz: /* GeoIp2 */</p> <hr /> <div>Some of Moodle's libraries were written by other people, and are being redistributed as part of Moodle under their respective open source licenses that thankfully allow us to do so. Thanks to the authors of all these excellent products - without them Moodle would be missing important functionality. Copyright information for each package is included below:<br /> <br /> ==ADOdb==<br /> <br /> ''lib/adodb''<br /> <br /> Database abstraction library for MySQL, PostgreSQL, MSSQL, Oracle, Interbase, Foxpro, Access, ADO, Sybase, DB2 and ODBC.<br /> <br /> Version: 5.20.9<br /> <br /> @copyright (c) 2000-2013 John Lim (jlim#natsoft.com). All rights reserved.<br /> <br /> @copyright (c) 2014 Damien Regad, Mark Newnham and the ADOdb community<br /> <br /> License: Dual LGPL and BSD-style<br /> <br /> http://adodb.sourceforge.net<br /> <br /> ==Amazon S3==<br /> <br /> ''repository/s3/S3.php''<br /> <br /> A standalone Amazon S3 (REST) client for PHP 5.2.x using CURL that does not require PEAR. <br /> <br /> Version: 0.5.1<br /> <br /> Copyright (c) 2013, Donovan Schönknecht<br /> <br /> License: BSD 2-Clause<br /> <br /> https://github.com/tpyo/amazon-s3-php-class/releases<br /> <br /> ==CAS==<br /> <br /> ''auth/cas/CAS''<br /> <br /> phpCAS library to support CAS authentication plugin<br /> <br /> Copyright Jasig<br /> <br /> License: Apache License 2.0<br /> <br /> https://wiki.jasig.org/display/CASC/phpCAS<br /> <br /> ==Chart.js==<br /> <br /> ''lib/amd/src/chartjs-lazy.js''<br /> <br /> Simple yet flexible JavaScript charting for designers &amp; developers<br /> <br /> Version: 2.2.2<br /> <br /> Copyright 2016 Nick Downie<br /> <br /> License: MIT<br /> <br /> http://www.chartjs.org<br /> <br /> ==EvalMath==<br /> <br /> ''lib/evalmath''<br /> <br /> Class to safely evaluate math expressions<br /> <br /> Copyright Miles Kaufmann<br /> <br /> License: BSD<br /> <br /> http://www.twmagic.com/<br /> <br /> ==FLV player==<br /> <br /> ''filter/mediaplugin/flvplayer.swf''<br /> <br /> Flash movie to play FLV files<br /> <br /> Copyright Jeroen Wijering <br /> <br /> License: GNU GPL<br /> <br /> http://www.jeroenwijering.com<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==FPDF Class==<br /> <br /> ''lib/fpdf''<br /> <br /> Class to generate PDF files<br /> <br /> Version: 1.54<br /> <br /> Copyright Olivier PLATHEY<br /> <br /> License: Freeware<br /> <br /> http://www.setasign.com/products/fpdi/downloads<br /> <br /> == GeoIp2 ==<br /> <br /> ''lib/maxmind/GeoIp2''<br /> <br /> Library for precessing of GeoIP data files<br /> <br /> Version: 2.6.0<br /> <br /> Copyright MaxMind<br /> <br /> License: Apache 2.0<br /> <br /> https://github.com/maxmind/GeoIP2-php<br /> <br /> ==Google APIs==<br /> <br /> &quot;lib/google&quot;<br /> <br /> Library Google APIs Client Library for PHP<br /> <br /> Version: 1.1.7<br /> <br /> License: Apache License Version 2.0<br /> <br /> https://github.com/google/google-api-php-client<br /> <br /> ==Graph Class==<br /> <br /> ''lib/graphlib.php''<br /> <br /> Class to draw line, point, bar, and area graphs, including numeric x-axis and double y-axis.<br /> <br /> Version: 1.6.3 (with modifications)<br /> <br /> Copyright © 2000 Herman Veluwenkamp (''hermanV AT mindless DOT com'')<br /> <br /> License: LGPL<br /> <br /> ==Horde==<br /> <br /> ''lib/horde''<br /> <br /> Library used by the inbound e-mail handling system.<br /> <br /> Version: 5.2.7<br /> <br /> Copyright © Horde LLC<br /> <br /> License: LGPL<br /> <br /> http://www.horde.org/<br /> <br /> ==html2text==<br /> <br /> ''lib/html2text''<br /> <br /> PHP script to convert HTML into an approximate text equivalent<br /> <br /> Version: 4.0.1<br /> <br /> Copyright © 2005-7 Jon Abernathy<br /> <br /> License: GNU GPL<br /> <br /> https://github.com/mtibben/html2text.git<br /> <br /> ==htmlArea==<br /> <br /> ''lib/editor''<br /> <br /> Javascript/HTML script to put a GUI editor in textareas on Internet Explorer and Mozilla<br /> <br /> Version: 3.0 beta (with modifications)<br /> <br /> Copyright © 2002 interactivetools.com, inc.<br /> <br /> License: htmlArea License (based on BSD license)<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==HTML Purifier==<br /> <br /> &quot;lib/htmlpurifier&quot;<br /> <br /> Filters HTML.<br /> <br /> Version: 4.8.0<br /> <br /> License: LGPL<br /> <br /> ==IP-Atlas==<br /> <br /> ''lib/ipatlas''<br /> <br /> PHP scripts to show the location of an IP address on a map.<br /> <br /> Version: 1.0 (with modifications)<br /> <br /> Copyright © 2002 Ivan Kozik<br /> <br /> License: GNU GPL<br /> <br /> http://www.xpenguin.com/ip-atlas.php<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==jQuery==<br /> <br /> ''lib/jquery''<br /> <br /> jQuery is a fast, small, and feature-rich JavaScript library widely used on moodle.<br /> <br /> Version: 1.12.3<br /> <br /> Copyright: 2016 The jQuery Foundation<br /> <br /> License: MIT<br /> <br /> https://jquery.com<br /> <br /> ==jQuery migrate==<br /> <br /> ''lib/jquery/jquery-migrate-1.4.0.js''<br /> <br /> Library used migrate older jQuery code to jQuery 3.0.<br /> <br /> Version: 1.4.0<br /> <br /> Copyright: 2016 The jQuery Foundation and other contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/jquery/jquery-migrate<br /> <br /> ==jQuery UI==<br /> <br /> ''lib/jquery/ui-1.12.1/''<br /> <br /> jQuery UI is a set of user interface interactions, effects, widgets, and themes built on top of the jQuery library.<br /> <br /> Version: 1.12.1<br /> <br /> Copyright: 2016 The jQuery Foundation and other contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/jquery/jquery-migrate<br /> <br /> ==Services_JSON==<br /> <br /> ''lib/json''<br /> <br /> Allows PHP-&gt;JS communication via JSON<br /> <br /> Version: 1.3.1<br /> <br /> Copyright © 2005 Michal Migurski<br /> <br /> License: Modified BSD (GPL-compatible)<br /> <br /> http://pear.php.net/pepr/pepr-proposal-show.php?id=198<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==kses==<br /> <br /> ''lib/kses.php''<br /> <br /> HTML/XHTML filter that only allows some elements and attributes<br /> <br /> Version: 0.2.2<br /> <br /> Copyright © 2002, 2003, 2005 Ulf Harnhammar<br /> <br /> License: GNU GPL<br /> <br /> http://sourceforge.net/projects/kses<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==less.php==<br /> <br /> The less.php is a PHP port of the official LESS processor used by moodle themes.<br /> <br /> ''lib/lessphp''<br /> <br /> Version: 1.7.0.10<br /> <br /> License: Apache 2.0<br /> <br /> http://lessphp.typesettercms.com/<br /> <br /> Copyright: Matt Agar and Martin Jantošovič<br /> ==loglevel.js==<br /> <br /> Minimal lightweight simple logging for JavaScript.<br /> <br /> Version 1.4.1<br /> <br /> Copyright (c) 2013 Tim Perry<br /> <br /> License: MIT<br /> <br /> https://github.com/pimterry/loglevel/<br /> ==MathJax==<br /> <br /> &quot;Not actually included in Moodle. Moodle instead has a setting where the mathjax library is located. It is currently pointing to CDN by default.&quot;<br /> <br /> JavaScript filter library for displaying LaTeX, AsciiMath notation, and MathML.<br /> <br /> Version 2.7<br /> <br /> © Copyright 2015 The MathJax Consortium.<br /> <br /> License: Apache V2.0<br /> <br /> https://github.com/mathjax/MathJax<br /> <br /> ==MatthiasMullie\Minify==<br /> CSS &amp; JavaScript minifier, in PHP<br /> <br /> Version 1.3.37<br /> <br /> License: MIT<br /> <br /> https://github.com/matthiasmullie/minify<br /> <br /> ==mimeTeX==<br /> <br /> ''filter/tex''<br /> <br /> Compiled C program to convert TeX into GIFs<br /> <br /> Version: 1.4<br /> <br /> Copyright © 2002-2004 John Forkosh Associates, Inc<br /> <br /> License: GNU GPL<br /> <br /> http://www.forkosh.com/mimetex.html<br /> <br /> ==Mustache.js==<br /> <br /> &quot;lib/amd/src/mustache.js&quot;<br /> <br /> JS library for displaying mustache templates.<br /> <br /> Version: 2.2.1<br /> <br /> Copyright (c) 2009 Chris Wanstrath (Ruby)<br /> <br /> Copyright (c) 2010-2014 Jan Lehnardt (JavaScript)<br /> <br /> Copyright (c) 2010-2015 The mustache.js community<br /> <br /> License: MIT<br /> <br /> https://github.com/janl/mustache.js/releases<br /> <br /> ==Mustache==<br /> <br /> &quot;lib/mustache&quot;<br /> <br /> PHP library for displaying mustache templates.<br /> <br /> Version: 2.11.1<br /> <br /> Copyright (c) 2010-2016 Justin Hileman<br /> <br /> License: MIT<br /> <br /> https://github.com/bobthecow/mustache.php/releases<br /> <br /> ==mp3player==<br /> <br /> ''lib/mp3player''<br /> <br /> Flash movie to play streaming MP3s<br /> <br /> Copyright © 2005 Andrew Walker<br /> <br /> License: GNU GPL<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==overlibmws==<br /> <br /> ''lib/overlib.js''<br /> <br /> Javascript library to enable DHTML popups, floating windows, events etc<br /> <br /> Version: July 2004<br /> <br /> Copyright © 2002-2004 Foteos Macrides<br /> <br /> Copyright © 1998-2004 Erik Bosrup<br /> <br /> License: Artistic Open Source License<br /> <br /> http://www.macridesweb.com/oltest/<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PclZip==<br /> <br /> ''lib/pclzip''<br /> <br /> Class to create, manage and unpack zip files.<br /> <br /> Version: 2.4 RC1<br /> <br /> Copyright © 2004 Vincent Blavet (''vincent AT phpconcept DOT net'')<br /> <br /> License: GNU GPL<br /> <br /> http://www.phpconcept.net<br /> <br /> ==PEAR OLE Classes==<br /> <br /> ''lib/pear''<br /> <br /> Class to write Excel files<br /> <br /> Version: 0.5<br /> <br /> Copyright © 2004 Xavier Noguer<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/OLE<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PEAR Spreadsheet_Excel_Writer==<br /> <br /> ''lib/pear''<br /> <br /> Class to write Excel files<br /> <br /> Version: 0.9.1<br /> <br /> Copyright © 2004 Xavier Noguer and Mika Tuupola<br /> <br /> License: LGPL<br /> <br /> http://pear.php.net/package/Spreadsheet_Excel_Writer<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PEAR HTML_Quickform==<br /> <br /> ''lib/pear''<br /> <br /> Class to write forms<br /> <br /> Version: 3.2.6<br /> <br /> Copyright © 2004 Bertrand Mansion, Adam Daniel, Alexey Borzov<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Quickform<br /> <br /> ==PEAR HTML_Quickform_Renderer_Tableless==<br /> <br /> ''lib/pear''<br /> <br /> Class to render forms without tables<br /> <br /> Version: 0.3.4<br /> <br /> Copyright © 2005 Mark Wiesemann<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Quickform_Renderer_Tableless<br /> <br /> ==PEAR HTML_QuickForm_DHTMLRulesTableless==<br /> <br /> ''lib/pear''<br /> <br /> Class to render validation notices with dhtml<br /> <br /> Version: 0.1.2<br /> <br /> Copyright © 2005 Alexey Borzov, Adam Daniel, Bertrand Mansion, Justin Patrin, Mark Wiesemann<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_QuickForm_DHTMLRulesTableless<br /> <br /> ==PEAR HTML_Common==<br /> <br /> ''lib/pear''<br /> <br /> Class with many common HTML functions (used by HTML Quickform)<br /> <br /> Version: 0.3.4<br /> <br /> Copyright © 2004 Adam Daniel, Bertrand Mansion, Klaus Guenther, Alexey Borzov<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Common<br /> <br /> ==PEAR XML_Parser==<br /> <br /> ''lib/pear''<br /> <br /> Class implementing one handy (sax-expat) XML parser<br /> <br /> Version: 1.3.2<br /> <br /> Copyright © 2004-2008 The PHP Group &amp; Stephan Schmidt<br /> <br /> License: New BSD License<br /> <br /> http://pear.php.net/package/XML_Parser<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PHP-CSS-Parser==<br /> <br /> ''lib/php-css-parser''<br /> <br /> A Parser for CSS Files written in PHP.<br /> <br /> Version: 8.1.0<br /> <br /> Copyright (c) 2011 Raphael Schweikert, http://sabberworm.com/<br /> <br /> License: MIT<br /> <br /> https://github.com/sabberworm/PHP-CSS-Parser<br /> <br /> ==PHPExcel==<br /> <br /> ''lib/phpexcel/PHPExcel.php''<br /> <br /> Library to read, write and create spreadsheet documents in PHP.<br /> <br /> Version 1.8.1<br /> <br /> Copyright © 2006 - 2015 PHPExcel<br /> License: LGPL<br /> <br /> https://github.com/PHPOffice/PHPExcel<br /> <br /> ==PHP mailer==<br /> <br /> ''lib/class.phpmailer.php''<br /> <br /> Class for sending email using either sendmail, PHP mail(), or SMTP. Methods are based upon the standard AspEmail(tm) classes.<br /> <br /> Version 5.2.16<br /> <br /> Copyright © 2003 Brent R. Matzelle (''bmatzelle AT yahoo DOT com'')<br /> License: LGPL<br /> <br /> http://phpmailer.sourceforge.net<br /> https://github.com/PHPMailer/PHPMailer/releases<br /> <br /> ==PHP Markdown==<br /> <br /> ''lib/markdown.php''<br /> <br /> Functions to convert from the Markdown text format into clean XHTML.<br /> <br /> Version: 1.6.0 (with modifications)<br /> <br /> PHP Markdown Lib Copyright © 2004-2015 Michel Fortin https://michelf.ca/<br /> All rights reserved.<br /> <br /> Based on Markdown<br /> Copyright © 2003-2005 John Gruber https://daringfireball.net/<br /> All rights reserved.<br /> <br /> License: BSD<br /> <br /> http://www.michelf.com/projects/php-markdown/<br /> <br /> ==RequireJS==<br /> <br /> ''/lib/requirejs/'' <br /> <br /> RequireJS is a JavaScript file and module loader.<br /> <br /> Version 2.3.2<br /> <br /> License: new BSD or MIT<br /> <br /> http://requirejs.org/<br /> <br /> ==scssphp==<br /> <br /> ''/lib/scssphp/'' <br /> <br /> scssphp is a compiler for SCSS written in PHP.<br /> <br /> Version: 0.6.5<br /> <br /> Copyright (c) 2015 Leaf Corcoran<br /> <br /> License: MIT<br /> <br /> http://leafo.github.io/scssphp<br /> <br /> ==SimplePie==<br /> <br /> &quot;/lib/simplepie&quot;<br /> <br /> Simple Pie helps with blogs.<br /> <br /> Version 1.4.2<br /> <br /> License: BSD<br /> <br /> https://github.com/simplepie/simplepie<br /> <br /> ==Snoopy==<br /> <br /> ''lib/snoopy''<br /> <br /> A PHP net client<br /> <br /> Version: 1.0<br /> <br /> Copyright © 1999-2000 Monte Ohrt (''monte AT ispi DOT net'')<br /> License: GNU LGPL<br /> <br /> http://snoopy.sourceforge.com<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==SMTP class==<br /> <br /> ''lib/class.smtp.php''<br /> <br /> Class that can be used to connect and communicate with any SMTP server. It implements all the SMTP functions defined in RFC821 except TURN.<br /> <br /> Version: 03/26/2001<br /> <br /> Copyright © 2001 Chris Ryan (''chris AT greatbridge DOT com'')<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==Spike PHPCoverage==<br /> <br /> ''lib/spikephpcoverage''<br /> <br /> PHP code coverage reporting tool<br /> <br /> Version: 0.8.2 (with modifications)<br /> <br /> Copyright © 2004 SpikeSource Inc<br /> <br /> License: LGPL<br /> <br /> http://developer.spikesource.com/projects/phpcoverage<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==Spout==<br /> <br /> &quot;lib/spout&quot;<br /> <br /> Library for importing and exporting csv / excel / ODS files.<br /> <br /> Version 2.6.0<br /> <br /> License: Apache<br /> <br /> https://github.com/box/spout/<br /> <br /> ==Typo3 Character Set Class==<br /> <br /> ''lib/typo3''<br /> <br /> Class for conversion between charsets and multibyte-savy operations with strings.<br /> <br /> Version: 4.7.19<br /> <br /> Copyright © 2003-2005 Kasper Skaarhoj<br /> <br /> Licence: GNU GPL<br /> <br /> http://typo3.org/<br /> <br /> ==Yahoo User Interface==<br /> <br /> ''lib/yui''<br /> <br /> The Yahoo! User Interface Library is a set of utilities and controls, in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, DHTML and AJAX. The YUI Library also includes several core CSS resources.Set of user-interface components using AJAX, DHTML etc. We use it for all our AJAX-related stuff.<br /> <br /> CVS version: 2.3.0<br /> <br /> Copyright (c) 2006, Yahoo! Inc.<br /> <br /> Licence: BSD<br /> <br /> http://developer.yahoo.com/yui/<br /> <br /> ==Mustache.js==<br /> <br /> &quot;lib/amd/src/mustache.js&quot;<br /> <br /> JS library for displaying mustache templates.<br /> <br /> Version: 2.2.1<br /> <br /> Copyright (c) 2009 Chris Wanstrath (Ruby)<br /> <br /> Copyright (c) 2010-2014 Jan Lehnardt (JavaScript)<br /> <br /> Copyright (c) 2010-2015 The mustache.js community<br /> <br /> License: MIT<br /> <br /> https://github.com/janl/mustache.js/releases<br /> <br /> ==LTI Tool Provider Library for PHP==<br /> <br /> &quot;lib/ltiprovider/&quot;<br /> <br /> PHP library for communicating with learning tools as per the LTI specification.<br /> <br /> Version: 3.0.2<br /> <br /> © 2016 IMS Global Learning Consortium Inc. All Rights Reserved. Trademark Policy - (www.imsglobal.org/trademarks)<br /> <br /> License: Apache 2<br /> <br /> https://github.com/IMSGlobal/LTI-Tool-Provider-Library-PHP<br /> <br /> <br /> ==Popper.js==<br /> <br /> &quot;admin/tool/usertours/amd/src/popper.js&quot;<br /> <br /> A kickass library used to created Poppers in web applications<br /> <br /> © 2016 Federico Zivolo and contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/FezVrasta/popper.js<br /> <br /> ==Flexitour==<br /> <br /> &quot;admin/tool/usertours/amd/src/tour.js&quot;<br /> <br /> A JS library for tours<br /> <br /> © 2016 Andrew Nicols and contributors<br /> <br /> License: GPLv3<br /> <br /> https://github.com/andrewnicols/flexitour<br /> <br /> [[Category:Credits]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Moodle_libraries_credits&diff=53034 2017-10-16T05:28:42Z

<p>Ankitfrenz: /* ADOdb */</p> <hr /> <div>Some of Moodle's libraries were written by other people, and are being redistributed as part of Moodle under their respective open source licenses that thankfully allow us to do so. Thanks to the authors of all these excellent products - without them Moodle would be missing important functionality. Copyright information for each package is included below:<br /> <br /> ==ADOdb==<br /> <br /> ''lib/adodb''<br /> <br /> Database abstraction library for MySQL, PostgreSQL, MSSQL, Oracle, Interbase, Foxpro, Access, ADO, Sybase, DB2 and ODBC.<br /> <br /> Version: 5.20.9<br /> <br /> @copyright (c) 2000-2013 John Lim (jlim#natsoft.com). All rights reserved.<br /> <br /> @copyright (c) 2014 Damien Regad, Mark Newnham and the ADOdb community<br /> <br /> License: Dual LGPL and BSD-style<br /> <br /> http://adodb.sourceforge.net<br /> <br /> ==Amazon S3==<br /> <br /> ''repository/s3/S3.php''<br /> <br /> A standalone Amazon S3 (REST) client for PHP 5.2.x using CURL that does not require PEAR. <br /> <br /> Version: 0.5.1<br /> <br /> Copyright (c) 2013, Donovan Schönknecht<br /> <br /> License: BSD 2-Clause<br /> <br /> https://github.com/tpyo/amazon-s3-php-class/releases<br /> <br /> ==CAS==<br /> <br /> ''auth/cas/CAS''<br /> <br /> phpCAS library to support CAS authentication plugin<br /> <br /> Copyright Jasig<br /> <br /> License: Apache License 2.0<br /> <br /> https://wiki.jasig.org/display/CASC/phpCAS<br /> <br /> ==Chart.js==<br /> <br /> ''lib/amd/src/chartjs-lazy.js''<br /> <br /> Simple yet flexible JavaScript charting for designers &amp; developers<br /> <br /> Version: 2.2.2<br /> <br /> Copyright 2016 Nick Downie<br /> <br /> License: MIT<br /> <br /> http://www.chartjs.org<br /> <br /> ==EvalMath==<br /> <br /> ''lib/evalmath''<br /> <br /> Class to safely evaluate math expressions<br /> <br /> Copyright Miles Kaufmann<br /> <br /> License: BSD<br /> <br /> http://www.twmagic.com/<br /> <br /> ==FLV player==<br /> <br /> ''filter/mediaplugin/flvplayer.swf''<br /> <br /> Flash movie to play FLV files<br /> <br /> Copyright Jeroen Wijering <br /> <br /> License: GNU GPL<br /> <br /> http://www.jeroenwijering.com<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==FPDF Class==<br /> <br /> ''lib/fpdf''<br /> <br /> Class to generate PDF files<br /> <br /> Version: 1.54<br /> <br /> Copyright Olivier PLATHEY<br /> <br /> License: Freeware<br /> <br /> http://www.setasign.com/products/fpdi/downloads<br /> <br /> == GeoIp2 ==<br /> <br /> ''lib/maxmind/GeoIp2''<br /> <br /> Library for precessing of GeoIP data files<br /> <br /> Version: 2.4.2<br /> <br /> Copyright MaxMind<br /> <br /> License: Apache 2.0<br /> <br /> https://github.com/maxmind/GeoIP2-php<br /> <br /> ==Google APIs==<br /> <br /> &quot;lib/google&quot;<br /> <br /> Library Google APIs Client Library for PHP<br /> <br /> Version: 1.1.7<br /> <br /> License: Apache License Version 2.0<br /> <br /> https://github.com/google/google-api-php-client<br /> <br /> ==Graph Class==<br /> <br /> ''lib/graphlib.php''<br /> <br /> Class to draw line, point, bar, and area graphs, including numeric x-axis and double y-axis.<br /> <br /> Version: 1.6.3 (with modifications)<br /> <br /> Copyright © 2000 Herman Veluwenkamp (''hermanV AT mindless DOT com'')<br /> <br /> License: LGPL<br /> <br /> ==Horde==<br /> <br /> ''lib/horde''<br /> <br /> Library used by the inbound e-mail handling system.<br /> <br /> Version: 5.2.7<br /> <br /> Copyright © Horde LLC<br /> <br /> License: LGPL<br /> <br /> http://www.horde.org/<br /> <br /> ==html2text==<br /> <br /> ''lib/html2text''<br /> <br /> PHP script to convert HTML into an approximate text equivalent<br /> <br /> Version: 4.0.1<br /> <br /> Copyright © 2005-7 Jon Abernathy<br /> <br /> License: GNU GPL<br /> <br /> https://github.com/mtibben/html2text.git<br /> <br /> ==htmlArea==<br /> <br /> ''lib/editor''<br /> <br /> Javascript/HTML script to put a GUI editor in textareas on Internet Explorer and Mozilla<br /> <br /> Version: 3.0 beta (with modifications)<br /> <br /> Copyright © 2002 interactivetools.com, inc.<br /> <br /> License: htmlArea License (based on BSD license)<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==HTML Purifier==<br /> <br /> &quot;lib/htmlpurifier&quot;<br /> <br /> Filters HTML.<br /> <br /> Version: 4.8.0<br /> <br /> License: LGPL<br /> <br /> ==IP-Atlas==<br /> <br /> ''lib/ipatlas''<br /> <br /> PHP scripts to show the location of an IP address on a map.<br /> <br /> Version: 1.0 (with modifications)<br /> <br /> Copyright © 2002 Ivan Kozik<br /> <br /> License: GNU GPL<br /> <br /> http://www.xpenguin.com/ip-atlas.php<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==jQuery==<br /> <br /> ''lib/jquery''<br /> <br /> jQuery is a fast, small, and feature-rich JavaScript library widely used on moodle.<br /> <br /> Version: 1.12.3<br /> <br /> Copyright: 2016 The jQuery Foundation<br /> <br /> License: MIT<br /> <br /> https://jquery.com<br /> <br /> ==jQuery migrate==<br /> <br /> ''lib/jquery/jquery-migrate-1.4.0.js''<br /> <br /> Library used migrate older jQuery code to jQuery 3.0.<br /> <br /> Version: 1.4.0<br /> <br /> Copyright: 2016 The jQuery Foundation and other contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/jquery/jquery-migrate<br /> <br /> ==jQuery UI==<br /> <br /> ''lib/jquery/ui-1.12.1/''<br /> <br /> jQuery UI is a set of user interface interactions, effects, widgets, and themes built on top of the jQuery library.<br /> <br /> Version: 1.12.1<br /> <br /> Copyright: 2016 The jQuery Foundation and other contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/jquery/jquery-migrate<br /> <br /> ==Services_JSON==<br /> <br /> ''lib/json''<br /> <br /> Allows PHP-&gt;JS communication via JSON<br /> <br /> Version: 1.3.1<br /> <br /> Copyright © 2005 Michal Migurski<br /> <br /> License: Modified BSD (GPL-compatible)<br /> <br /> http://pear.php.net/pepr/pepr-proposal-show.php?id=198<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==kses==<br /> <br /> ''lib/kses.php''<br /> <br /> HTML/XHTML filter that only allows some elements and attributes<br /> <br /> Version: 0.2.2<br /> <br /> Copyright © 2002, 2003, 2005 Ulf Harnhammar<br /> <br /> License: GNU GPL<br /> <br /> http://sourceforge.net/projects/kses<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==less.php==<br /> <br /> The less.php is a PHP port of the official LESS processor used by moodle themes.<br /> <br /> ''lib/lessphp''<br /> <br /> Version: 1.7.0.10<br /> <br /> License: Apache 2.0<br /> <br /> http://lessphp.typesettercms.com/<br /> <br /> Copyright: Matt Agar and Martin Jantošovič<br /> ==loglevel.js==<br /> <br /> Minimal lightweight simple logging for JavaScript.<br /> <br /> Version 1.4.1<br /> <br /> Copyright (c) 2013 Tim Perry<br /> <br /> License: MIT<br /> <br /> https://github.com/pimterry/loglevel/<br /> ==MathJax==<br /> <br /> &quot;Not actually included in Moodle. Moodle instead has a setting where the mathjax library is located. It is currently pointing to CDN by default.&quot;<br /> <br /> JavaScript filter library for displaying LaTeX, AsciiMath notation, and MathML.<br /> <br /> Version 2.7<br /> <br /> © Copyright 2015 The MathJax Consortium.<br /> <br /> License: Apache V2.0<br /> <br /> https://github.com/mathjax/MathJax<br /> <br /> ==MatthiasMullie\Minify==<br /> CSS &amp; JavaScript minifier, in PHP<br /> <br /> Version 1.3.37<br /> <br /> License: MIT<br /> <br /> https://github.com/matthiasmullie/minify<br /> <br /> ==mimeTeX==<br /> <br /> ''filter/tex''<br /> <br /> Compiled C program to convert TeX into GIFs<br /> <br /> Version: 1.4<br /> <br /> Copyright © 2002-2004 John Forkosh Associates, Inc<br /> <br /> License: GNU GPL<br /> <br /> http://www.forkosh.com/mimetex.html<br /> <br /> ==Mustache.js==<br /> <br /> &quot;lib/amd/src/mustache.js&quot;<br /> <br /> JS library for displaying mustache templates.<br /> <br /> Version: 2.2.1<br /> <br /> Copyright (c) 2009 Chris Wanstrath (Ruby)<br /> <br /> Copyright (c) 2010-2014 Jan Lehnardt (JavaScript)<br /> <br /> Copyright (c) 2010-2015 The mustache.js community<br /> <br /> License: MIT<br /> <br /> https://github.com/janl/mustache.js/releases<br /> <br /> ==Mustache==<br /> <br /> &quot;lib/mustache&quot;<br /> <br /> PHP library for displaying mustache templates.<br /> <br /> Version: 2.11.1<br /> <br /> Copyright (c) 2010-2016 Justin Hileman<br /> <br /> License: MIT<br /> <br /> https://github.com/bobthecow/mustache.php/releases<br /> <br /> ==mp3player==<br /> <br /> ''lib/mp3player''<br /> <br /> Flash movie to play streaming MP3s<br /> <br /> Copyright © 2005 Andrew Walker<br /> <br /> License: GNU GPL<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==overlibmws==<br /> <br /> ''lib/overlib.js''<br /> <br /> Javascript library to enable DHTML popups, floating windows, events etc<br /> <br /> Version: July 2004<br /> <br /> Copyright © 2002-2004 Foteos Macrides<br /> <br /> Copyright © 1998-2004 Erik Bosrup<br /> <br /> License: Artistic Open Source License<br /> <br /> http://www.macridesweb.com/oltest/<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PclZip==<br /> <br /> ''lib/pclzip''<br /> <br /> Class to create, manage and unpack zip files.<br /> <br /> Version: 2.4 RC1<br /> <br /> Copyright © 2004 Vincent Blavet (''vincent AT phpconcept DOT net'')<br /> <br /> License: GNU GPL<br /> <br /> http://www.phpconcept.net<br /> <br /> ==PEAR OLE Classes==<br /> <br /> ''lib/pear''<br /> <br /> Class to write Excel files<br /> <br /> Version: 0.5<br /> <br /> Copyright © 2004 Xavier Noguer<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/OLE<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PEAR Spreadsheet_Excel_Writer==<br /> <br /> ''lib/pear''<br /> <br /> Class to write Excel files<br /> <br /> Version: 0.9.1<br /> <br /> Copyright © 2004 Xavier Noguer and Mika Tuupola<br /> <br /> License: LGPL<br /> <br /> http://pear.php.net/package/Spreadsheet_Excel_Writer<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PEAR HTML_Quickform==<br /> <br /> ''lib/pear''<br /> <br /> Class to write forms<br /> <br /> Version: 3.2.6<br /> <br /> Copyright © 2004 Bertrand Mansion, Adam Daniel, Alexey Borzov<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Quickform<br /> <br /> ==PEAR HTML_Quickform_Renderer_Tableless==<br /> <br /> ''lib/pear''<br /> <br /> Class to render forms without tables<br /> <br /> Version: 0.3.4<br /> <br /> Copyright © 2005 Mark Wiesemann<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Quickform_Renderer_Tableless<br /> <br /> ==PEAR HTML_QuickForm_DHTMLRulesTableless==<br /> <br /> ''lib/pear''<br /> <br /> Class to render validation notices with dhtml<br /> <br /> Version: 0.1.2<br /> <br /> Copyright © 2005 Alexey Borzov, Adam Daniel, Bertrand Mansion, Justin Patrin, Mark Wiesemann<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_QuickForm_DHTMLRulesTableless<br /> <br /> ==PEAR HTML_Common==<br /> <br /> ''lib/pear''<br /> <br /> Class with many common HTML functions (used by HTML Quickform)<br /> <br /> Version: 0.3.4<br /> <br /> Copyright © 2004 Adam Daniel, Bertrand Mansion, Klaus Guenther, Alexey Borzov<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Common<br /> <br /> ==PEAR XML_Parser==<br /> <br /> ''lib/pear''<br /> <br /> Class implementing one handy (sax-expat) XML parser<br /> <br /> Version: 1.3.2<br /> <br /> Copyright © 2004-2008 The PHP Group &amp; Stephan Schmidt<br /> <br /> License: New BSD License<br /> <br /> http://pear.php.net/package/XML_Parser<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PHP-CSS-Parser==<br /> <br /> ''lib/php-css-parser''<br /> <br /> A Parser for CSS Files written in PHP.<br /> <br /> Version: 8.1.0<br /> <br /> Copyright (c) 2011 Raphael Schweikert, http://sabberworm.com/<br /> <br /> License: MIT<br /> <br /> https://github.com/sabberworm/PHP-CSS-Parser<br /> <br /> ==PHPExcel==<br /> <br /> ''lib/phpexcel/PHPExcel.php''<br /> <br /> Library to read, write and create spreadsheet documents in PHP.<br /> <br /> Version 1.8.1<br /> <br /> Copyright © 2006 - 2015 PHPExcel<br /> License: LGPL<br /> <br /> https://github.com/PHPOffice/PHPExcel<br /> <br /> ==PHP mailer==<br /> <br /> ''lib/class.phpmailer.php''<br /> <br /> Class for sending email using either sendmail, PHP mail(), or SMTP. Methods are based upon the standard AspEmail(tm) classes.<br /> <br /> Version 5.2.16<br /> <br /> Copyright © 2003 Brent R. Matzelle (''bmatzelle AT yahoo DOT com'')<br /> License: LGPL<br /> <br /> http://phpmailer.sourceforge.net<br /> https://github.com/PHPMailer/PHPMailer/releases<br /> <br /> ==PHP Markdown==<br /> <br /> ''lib/markdown.php''<br /> <br /> Functions to convert from the Markdown text format into clean XHTML.<br /> <br /> Version: 1.6.0 (with modifications)<br /> <br /> PHP Markdown Lib Copyright © 2004-2015 Michel Fortin https://michelf.ca/<br /> All rights reserved.<br /> <br /> Based on Markdown<br /> Copyright © 2003-2005 John Gruber https://daringfireball.net/<br /> All rights reserved.<br /> <br /> License: BSD<br /> <br /> http://www.michelf.com/projects/php-markdown/<br /> <br /> ==RequireJS==<br /> <br /> ''/lib/requirejs/'' <br /> <br /> RequireJS is a JavaScript file and module loader.<br /> <br /> Version 2.3.2<br /> <br /> License: new BSD or MIT<br /> <br /> http://requirejs.org/<br /> <br /> ==scssphp==<br /> <br /> ''/lib/scssphp/'' <br /> <br /> scssphp is a compiler for SCSS written in PHP.<br /> <br /> Version: 0.6.5<br /> <br /> Copyright (c) 2015 Leaf Corcoran<br /> <br /> License: MIT<br /> <br /> http://leafo.github.io/scssphp<br /> <br /> ==SimplePie==<br /> <br /> &quot;/lib/simplepie&quot;<br /> <br /> Simple Pie helps with blogs.<br /> <br /> Version 1.4.2<br /> <br /> License: BSD<br /> <br /> https://github.com/simplepie/simplepie<br /> <br /> ==Snoopy==<br /> <br /> ''lib/snoopy''<br /> <br /> A PHP net client<br /> <br /> Version: 1.0<br /> <br /> Copyright © 1999-2000 Monte Ohrt (''monte AT ispi DOT net'')<br /> License: GNU LGPL<br /> <br /> http://snoopy.sourceforge.com<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==SMTP class==<br /> <br /> ''lib/class.smtp.php''<br /> <br /> Class that can be used to connect and communicate with any SMTP server. It implements all the SMTP functions defined in RFC821 except TURN.<br /> <br /> Version: 03/26/2001<br /> <br /> Copyright © 2001 Chris Ryan (''chris AT greatbridge DOT com'')<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==Spike PHPCoverage==<br /> <br /> ''lib/spikephpcoverage''<br /> <br /> PHP code coverage reporting tool<br /> <br /> Version: 0.8.2 (with modifications)<br /> <br /> Copyright © 2004 SpikeSource Inc<br /> <br /> License: LGPL<br /> <br /> http://developer.spikesource.com/projects/phpcoverage<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==Spout==<br /> <br /> &quot;lib/spout&quot;<br /> <br /> Library for importing and exporting csv / excel / ODS files.<br /> <br /> Version 2.6.0<br /> <br /> License: Apache<br /> <br /> https://github.com/box/spout/<br /> <br /> ==Typo3 Character Set Class==<br /> <br /> ''lib/typo3''<br /> <br /> Class for conversion between charsets and multibyte-savy operations with strings.<br /> <br /> Version: 4.7.19<br /> <br /> Copyright © 2003-2005 Kasper Skaarhoj<br /> <br /> Licence: GNU GPL<br /> <br /> http://typo3.org/<br /> <br /> ==Yahoo User Interface==<br /> <br /> ''lib/yui''<br /> <br /> The Yahoo! User Interface Library is a set of utilities and controls, in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, DHTML and AJAX. The YUI Library also includes several core CSS resources.Set of user-interface components using AJAX, DHTML etc. We use it for all our AJAX-related stuff.<br /> <br /> CVS version: 2.3.0<br /> <br /> Copyright (c) 2006, Yahoo! Inc.<br /> <br /> Licence: BSD<br /> <br /> http://developer.yahoo.com/yui/<br /> <br /> ==Mustache.js==<br /> <br /> &quot;lib/amd/src/mustache.js&quot;<br /> <br /> JS library for displaying mustache templates.<br /> <br /> Version: 2.2.1<br /> <br /> Copyright (c) 2009 Chris Wanstrath (Ruby)<br /> <br /> Copyright (c) 2010-2014 Jan Lehnardt (JavaScript)<br /> <br /> Copyright (c) 2010-2015 The mustache.js community<br /> <br /> License: MIT<br /> <br /> https://github.com/janl/mustache.js/releases<br /> <br /> ==LTI Tool Provider Library for PHP==<br /> <br /> &quot;lib/ltiprovider/&quot;<br /> <br /> PHP library for communicating with learning tools as per the LTI specification.<br /> <br /> Version: 3.0.2<br /> <br /> © 2016 IMS Global Learning Consortium Inc. All Rights Reserved. Trademark Policy - (www.imsglobal.org/trademarks)<br /> <br /> License: Apache 2<br /> <br /> https://github.com/IMSGlobal/LTI-Tool-Provider-Library-PHP<br /> <br /> <br /> ==Popper.js==<br /> <br /> &quot;admin/tool/usertours/amd/src/popper.js&quot;<br /> <br /> A kickass library used to created Poppers in web applications<br /> <br /> © 2016 Federico Zivolo and contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/FezVrasta/popper.js<br /> <br /> ==Flexitour==<br /> <br /> &quot;admin/tool/usertours/amd/src/tour.js&quot;<br /> <br /> A JS library for tours<br /> <br /> © 2016 Andrew Nicols and contributors<br /> <br /> License: GPLv3<br /> <br /> https://github.com/andrewnicols/flexitour<br /> <br /> [[Category:Credits]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Moodle_libraries_credits&diff=53033 2017-10-16T05:28:21Z

<p>Ankitfrenz: /* ADOdb */</p> <hr /> <div>Some of Moodle's libraries were written by other people, and are being redistributed as part of Moodle under their respective open source licenses that thankfully allow us to do so. Thanks to the authors of all these excellent products - without them Moodle would be missing important functionality. Copyright information for each package is included below:<br /> <br /> ==ADOdb==<br /> <br /> ''lib/adodb''<br /> <br /> Database abstraction library for MySQL, PostgreSQL, MSSQL, Oracle, Interbase, Foxpro, Access, ADO, Sybase, DB2 and ODBC.<br /> <br /> Version: 5.20.9<br /> <br /> @copyright (c) 2000-2013 John Lim (jlim#natsoft.com). All rights reserved.<br /> @copyright (c) 2014 Damien Regad, Mark Newnham and the ADOdb community<br /> <br /> License: Dual LGPL and BSD-style<br /> <br /> http://adodb.sourceforge.net<br /> <br /> ==Amazon S3==<br /> <br /> ''repository/s3/S3.php''<br /> <br /> A standalone Amazon S3 (REST) client for PHP 5.2.x using CURL that does not require PEAR. <br /> <br /> Version: 0.5.1<br /> <br /> Copyright (c) 2013, Donovan Schönknecht<br /> <br /> License: BSD 2-Clause<br /> <br /> https://github.com/tpyo/amazon-s3-php-class/releases<br /> <br /> ==CAS==<br /> <br /> ''auth/cas/CAS''<br /> <br /> phpCAS library to support CAS authentication plugin<br /> <br /> Copyright Jasig<br /> <br /> License: Apache License 2.0<br /> <br /> https://wiki.jasig.org/display/CASC/phpCAS<br /> <br /> ==Chart.js==<br /> <br /> ''lib/amd/src/chartjs-lazy.js''<br /> <br /> Simple yet flexible JavaScript charting for designers &amp; developers<br /> <br /> Version: 2.2.2<br /> <br /> Copyright 2016 Nick Downie<br /> <br /> License: MIT<br /> <br /> http://www.chartjs.org<br /> <br /> ==EvalMath==<br /> <br /> ''lib/evalmath''<br /> <br /> Class to safely evaluate math expressions<br /> <br /> Copyright Miles Kaufmann<br /> <br /> License: BSD<br /> <br /> http://www.twmagic.com/<br /> <br /> ==FLV player==<br /> <br /> ''filter/mediaplugin/flvplayer.swf''<br /> <br /> Flash movie to play FLV files<br /> <br /> Copyright Jeroen Wijering <br /> <br /> License: GNU GPL<br /> <br /> http://www.jeroenwijering.com<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==FPDF Class==<br /> <br /> ''lib/fpdf''<br /> <br /> Class to generate PDF files<br /> <br /> Version: 1.54<br /> <br /> Copyright Olivier PLATHEY<br /> <br /> License: Freeware<br /> <br /> http://www.setasign.com/products/fpdi/downloads<br /> <br /> == GeoIp2 ==<br /> <br /> ''lib/maxmind/GeoIp2''<br /> <br /> Library for precessing of GeoIP data files<br /> <br /> Version: 2.4.2<br /> <br /> Copyright MaxMind<br /> <br /> License: Apache 2.0<br /> <br /> https://github.com/maxmind/GeoIP2-php<br /> <br /> ==Google APIs==<br /> <br /> &quot;lib/google&quot;<br /> <br /> Library Google APIs Client Library for PHP<br /> <br /> Version: 1.1.7<br /> <br /> License: Apache License Version 2.0<br /> <br /> https://github.com/google/google-api-php-client<br /> <br /> ==Graph Class==<br /> <br /> ''lib/graphlib.php''<br /> <br /> Class to draw line, point, bar, and area graphs, including numeric x-axis and double y-axis.<br /> <br /> Version: 1.6.3 (with modifications)<br /> <br /> Copyright © 2000 Herman Veluwenkamp (''hermanV AT mindless DOT com'')<br /> <br /> License: LGPL<br /> <br /> ==Horde==<br /> <br /> ''lib/horde''<br /> <br /> Library used by the inbound e-mail handling system.<br /> <br /> Version: 5.2.7<br /> <br /> Copyright © Horde LLC<br /> <br /> License: LGPL<br /> <br /> http://www.horde.org/<br /> <br /> ==html2text==<br /> <br /> ''lib/html2text''<br /> <br /> PHP script to convert HTML into an approximate text equivalent<br /> <br /> Version: 4.0.1<br /> <br /> Copyright © 2005-7 Jon Abernathy<br /> <br /> License: GNU GPL<br /> <br /> https://github.com/mtibben/html2text.git<br /> <br /> ==htmlArea==<br /> <br /> ''lib/editor''<br /> <br /> Javascript/HTML script to put a GUI editor in textareas on Internet Explorer and Mozilla<br /> <br /> Version: 3.0 beta (with modifications)<br /> <br /> Copyright © 2002 interactivetools.com, inc.<br /> <br /> License: htmlArea License (based on BSD license)<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==HTML Purifier==<br /> <br /> &quot;lib/htmlpurifier&quot;<br /> <br /> Filters HTML.<br /> <br /> Version: 4.8.0<br /> <br /> License: LGPL<br /> <br /> ==IP-Atlas==<br /> <br /> ''lib/ipatlas''<br /> <br /> PHP scripts to show the location of an IP address on a map.<br /> <br /> Version: 1.0 (with modifications)<br /> <br /> Copyright © 2002 Ivan Kozik<br /> <br /> License: GNU GPL<br /> <br /> http://www.xpenguin.com/ip-atlas.php<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==jQuery==<br /> <br /> ''lib/jquery''<br /> <br /> jQuery is a fast, small, and feature-rich JavaScript library widely used on moodle.<br /> <br /> Version: 1.12.3<br /> <br /> Copyright: 2016 The jQuery Foundation<br /> <br /> License: MIT<br /> <br /> https://jquery.com<br /> <br /> ==jQuery migrate==<br /> <br /> ''lib/jquery/jquery-migrate-1.4.0.js''<br /> <br /> Library used migrate older jQuery code to jQuery 3.0.<br /> <br /> Version: 1.4.0<br /> <br /> Copyright: 2016 The jQuery Foundation and other contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/jquery/jquery-migrate<br /> <br /> ==jQuery UI==<br /> <br /> ''lib/jquery/ui-1.12.1/''<br /> <br /> jQuery UI is a set of user interface interactions, effects, widgets, and themes built on top of the jQuery library.<br /> <br /> Version: 1.12.1<br /> <br /> Copyright: 2016 The jQuery Foundation and other contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/jquery/jquery-migrate<br /> <br /> ==Services_JSON==<br /> <br /> ''lib/json''<br /> <br /> Allows PHP-&gt;JS communication via JSON<br /> <br /> Version: 1.3.1<br /> <br /> Copyright © 2005 Michal Migurski<br /> <br /> License: Modified BSD (GPL-compatible)<br /> <br /> http://pear.php.net/pepr/pepr-proposal-show.php?id=198<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==kses==<br /> <br /> ''lib/kses.php''<br /> <br /> HTML/XHTML filter that only allows some elements and attributes<br /> <br /> Version: 0.2.2<br /> <br /> Copyright © 2002, 2003, 2005 Ulf Harnhammar<br /> <br /> License: GNU GPL<br /> <br /> http://sourceforge.net/projects/kses<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==less.php==<br /> <br /> The less.php is a PHP port of the official LESS processor used by moodle themes.<br /> <br /> ''lib/lessphp''<br /> <br /> Version: 1.7.0.10<br /> <br /> License: Apache 2.0<br /> <br /> http://lessphp.typesettercms.com/<br /> <br /> Copyright: Matt Agar and Martin Jantošovič<br /> ==loglevel.js==<br /> <br /> Minimal lightweight simple logging for JavaScript.<br /> <br /> Version 1.4.1<br /> <br /> Copyright (c) 2013 Tim Perry<br /> <br /> License: MIT<br /> <br /> https://github.com/pimterry/loglevel/<br /> ==MathJax==<br /> <br /> &quot;Not actually included in Moodle. Moodle instead has a setting where the mathjax library is located. It is currently pointing to CDN by default.&quot;<br /> <br /> JavaScript filter library for displaying LaTeX, AsciiMath notation, and MathML.<br /> <br /> Version 2.7<br /> <br /> © Copyright 2015 The MathJax Consortium.<br /> <br /> License: Apache V2.0<br /> <br /> https://github.com/mathjax/MathJax<br /> <br /> ==MatthiasMullie\Minify==<br /> CSS &amp; JavaScript minifier, in PHP<br /> <br /> Version 1.3.37<br /> <br /> License: MIT<br /> <br /> https://github.com/matthiasmullie/minify<br /> <br /> ==mimeTeX==<br /> <br /> ''filter/tex''<br /> <br /> Compiled C program to convert TeX into GIFs<br /> <br /> Version: 1.4<br /> <br /> Copyright © 2002-2004 John Forkosh Associates, Inc<br /> <br /> License: GNU GPL<br /> <br /> http://www.forkosh.com/mimetex.html<br /> <br /> ==Mustache.js==<br /> <br /> &quot;lib/amd/src/mustache.js&quot;<br /> <br /> JS library for displaying mustache templates.<br /> <br /> Version: 2.2.1<br /> <br /> Copyright (c) 2009 Chris Wanstrath (Ruby)<br /> <br /> Copyright (c) 2010-2014 Jan Lehnardt (JavaScript)<br /> <br /> Copyright (c) 2010-2015 The mustache.js community<br /> <br /> License: MIT<br /> <br /> https://github.com/janl/mustache.js/releases<br /> <br /> ==Mustache==<br /> <br /> &quot;lib/mustache&quot;<br /> <br /> PHP library for displaying mustache templates.<br /> <br /> Version: 2.11.1<br /> <br /> Copyright (c) 2010-2016 Justin Hileman<br /> <br /> License: MIT<br /> <br /> https://github.com/bobthecow/mustache.php/releases<br /> <br /> ==mp3player==<br /> <br /> ''lib/mp3player''<br /> <br /> Flash movie to play streaming MP3s<br /> <br /> Copyright © 2005 Andrew Walker<br /> <br /> License: GNU GPL<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==overlibmws==<br /> <br /> ''lib/overlib.js''<br /> <br /> Javascript library to enable DHTML popups, floating windows, events etc<br /> <br /> Version: July 2004<br /> <br /> Copyright © 2002-2004 Foteos Macrides<br /> <br /> Copyright © 1998-2004 Erik Bosrup<br /> <br /> License: Artistic Open Source License<br /> <br /> http://www.macridesweb.com/oltest/<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PclZip==<br /> <br /> ''lib/pclzip''<br /> <br /> Class to create, manage and unpack zip files.<br /> <br /> Version: 2.4 RC1<br /> <br /> Copyright © 2004 Vincent Blavet (''vincent AT phpconcept DOT net'')<br /> <br /> License: GNU GPL<br /> <br /> http://www.phpconcept.net<br /> <br /> ==PEAR OLE Classes==<br /> <br /> ''lib/pear''<br /> <br /> Class to write Excel files<br /> <br /> Version: 0.5<br /> <br /> Copyright © 2004 Xavier Noguer<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/OLE<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PEAR Spreadsheet_Excel_Writer==<br /> <br /> ''lib/pear''<br /> <br /> Class to write Excel files<br /> <br /> Version: 0.9.1<br /> <br /> Copyright © 2004 Xavier Noguer and Mika Tuupola<br /> <br /> License: LGPL<br /> <br /> http://pear.php.net/package/Spreadsheet_Excel_Writer<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PEAR HTML_Quickform==<br /> <br /> ''lib/pear''<br /> <br /> Class to write forms<br /> <br /> Version: 3.2.6<br /> <br /> Copyright © 2004 Bertrand Mansion, Adam Daniel, Alexey Borzov<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Quickform<br /> <br /> ==PEAR HTML_Quickform_Renderer_Tableless==<br /> <br /> ''lib/pear''<br /> <br /> Class to render forms without tables<br /> <br /> Version: 0.3.4<br /> <br /> Copyright © 2005 Mark Wiesemann<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Quickform_Renderer_Tableless<br /> <br /> ==PEAR HTML_QuickForm_DHTMLRulesTableless==<br /> <br /> ''lib/pear''<br /> <br /> Class to render validation notices with dhtml<br /> <br /> Version: 0.1.2<br /> <br /> Copyright © 2005 Alexey Borzov, Adam Daniel, Bertrand Mansion, Justin Patrin, Mark Wiesemann<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_QuickForm_DHTMLRulesTableless<br /> <br /> ==PEAR HTML_Common==<br /> <br /> ''lib/pear''<br /> <br /> Class with many common HTML functions (used by HTML Quickform)<br /> <br /> Version: 0.3.4<br /> <br /> Copyright © 2004 Adam Daniel, Bertrand Mansion, Klaus Guenther, Alexey Borzov<br /> <br /> License: PHP (plus special exemption for Moodle to make it compatible)<br /> <br /> http://pear.php.net/package/HTML_Common<br /> <br /> ==PEAR XML_Parser==<br /> <br /> ''lib/pear''<br /> <br /> Class implementing one handy (sax-expat) XML parser<br /> <br /> Version: 1.3.2<br /> <br /> Copyright © 2004-2008 The PHP Group &amp; Stephan Schmidt<br /> <br /> License: New BSD License<br /> <br /> http://pear.php.net/package/XML_Parser<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==PHP-CSS-Parser==<br /> <br /> ''lib/php-css-parser''<br /> <br /> A Parser for CSS Files written in PHP.<br /> <br /> Version: 8.1.0<br /> <br /> Copyright (c) 2011 Raphael Schweikert, http://sabberworm.com/<br /> <br /> License: MIT<br /> <br /> https://github.com/sabberworm/PHP-CSS-Parser<br /> <br /> ==PHPExcel==<br /> <br /> ''lib/phpexcel/PHPExcel.php''<br /> <br /> Library to read, write and create spreadsheet documents in PHP.<br /> <br /> Version 1.8.1<br /> <br /> Copyright © 2006 - 2015 PHPExcel<br /> License: LGPL<br /> <br /> https://github.com/PHPOffice/PHPExcel<br /> <br /> ==PHP mailer==<br /> <br /> ''lib/class.phpmailer.php''<br /> <br /> Class for sending email using either sendmail, PHP mail(), or SMTP. Methods are based upon the standard AspEmail(tm) classes.<br /> <br /> Version 5.2.16<br /> <br /> Copyright © 2003 Brent R. Matzelle (''bmatzelle AT yahoo DOT com'')<br /> License: LGPL<br /> <br /> http://phpmailer.sourceforge.net<br /> https://github.com/PHPMailer/PHPMailer/releases<br /> <br /> ==PHP Markdown==<br /> <br /> ''lib/markdown.php''<br /> <br /> Functions to convert from the Markdown text format into clean XHTML.<br /> <br /> Version: 1.6.0 (with modifications)<br /> <br /> PHP Markdown Lib Copyright © 2004-2015 Michel Fortin https://michelf.ca/<br /> All rights reserved.<br /> <br /> Based on Markdown<br /> Copyright © 2003-2005 John Gruber https://daringfireball.net/<br /> All rights reserved.<br /> <br /> License: BSD<br /> <br /> http://www.michelf.com/projects/php-markdown/<br /> <br /> ==RequireJS==<br /> <br /> ''/lib/requirejs/'' <br /> <br /> RequireJS is a JavaScript file and module loader.<br /> <br /> Version 2.3.2<br /> <br /> License: new BSD or MIT<br /> <br /> http://requirejs.org/<br /> <br /> ==scssphp==<br /> <br /> ''/lib/scssphp/'' <br /> <br /> scssphp is a compiler for SCSS written in PHP.<br /> <br /> Version: 0.6.5<br /> <br /> Copyright (c) 2015 Leaf Corcoran<br /> <br /> License: MIT<br /> <br /> http://leafo.github.io/scssphp<br /> <br /> ==SimplePie==<br /> <br /> &quot;/lib/simplepie&quot;<br /> <br /> Simple Pie helps with blogs.<br /> <br /> Version 1.4.2<br /> <br /> License: BSD<br /> <br /> https://github.com/simplepie/simplepie<br /> <br /> ==Snoopy==<br /> <br /> ''lib/snoopy''<br /> <br /> A PHP net client<br /> <br /> Version: 1.0<br /> <br /> Copyright © 1999-2000 Monte Ohrt (''monte AT ispi DOT net'')<br /> License: GNU LGPL<br /> <br /> http://snoopy.sourceforge.com<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==SMTP class==<br /> <br /> ''lib/class.smtp.php''<br /> <br /> Class that can be used to connect and communicate with any SMTP server. It implements all the SMTP functions defined in RFC821 except TURN.<br /> <br /> Version: 03/26/2001<br /> <br /> Copyright © 2001 Chris Ryan (''chris AT greatbridge DOT com'')<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==Spike PHPCoverage==<br /> <br /> ''lib/spikephpcoverage''<br /> <br /> PHP code coverage reporting tool<br /> <br /> Version: 0.8.2 (with modifications)<br /> <br /> Copyright © 2004 SpikeSource Inc<br /> <br /> License: LGPL<br /> <br /> http://developer.spikesource.com/projects/phpcoverage<br /> <br /> (This library is not currently used in Moodle)<br /> <br /> ==Spout==<br /> <br /> &quot;lib/spout&quot;<br /> <br /> Library for importing and exporting csv / excel / ODS files.<br /> <br /> Version 2.6.0<br /> <br /> License: Apache<br /> <br /> https://github.com/box/spout/<br /> <br /> ==Typo3 Character Set Class==<br /> <br /> ''lib/typo3''<br /> <br /> Class for conversion between charsets and multibyte-savy operations with strings.<br /> <br /> Version: 4.7.19<br /> <br /> Copyright © 2003-2005 Kasper Skaarhoj<br /> <br /> Licence: GNU GPL<br /> <br /> http://typo3.org/<br /> <br /> ==Yahoo User Interface==<br /> <br /> ''lib/yui''<br /> <br /> The Yahoo! User Interface Library is a set of utilities and controls, in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, DHTML and AJAX. The YUI Library also includes several core CSS resources.Set of user-interface components using AJAX, DHTML etc. We use it for all our AJAX-related stuff.<br /> <br /> CVS version: 2.3.0<br /> <br /> Copyright (c) 2006, Yahoo! Inc.<br /> <br /> Licence: BSD<br /> <br /> http://developer.yahoo.com/yui/<br /> <br /> ==Mustache.js==<br /> <br /> &quot;lib/amd/src/mustache.js&quot;<br /> <br /> JS library for displaying mustache templates.<br /> <br /> Version: 2.2.1<br /> <br /> Copyright (c) 2009 Chris Wanstrath (Ruby)<br /> <br /> Copyright (c) 2010-2014 Jan Lehnardt (JavaScript)<br /> <br /> Copyright (c) 2010-2015 The mustache.js community<br /> <br /> License: MIT<br /> <br /> https://github.com/janl/mustache.js/releases<br /> <br /> ==LTI Tool Provider Library for PHP==<br /> <br /> &quot;lib/ltiprovider/&quot;<br /> <br /> PHP library for communicating with learning tools as per the LTI specification.<br /> <br /> Version: 3.0.2<br /> <br /> © 2016 IMS Global Learning Consortium Inc. All Rights Reserved. Trademark Policy - (www.imsglobal.org/trademarks)<br /> <br /> License: Apache 2<br /> <br /> https://github.com/IMSGlobal/LTI-Tool-Provider-Library-PHP<br /> <br /> <br /> ==Popper.js==<br /> <br /> &quot;admin/tool/usertours/amd/src/popper.js&quot;<br /> <br /> A kickass library used to created Poppers in web applications<br /> <br /> © 2016 Federico Zivolo and contributors<br /> <br /> License: MIT<br /> <br /> https://github.com/FezVrasta/popper.js<br /> <br /> ==Flexitour==<br /> <br /> &quot;admin/tool/usertours/amd/src/tour.js&quot;<br /> <br /> A JS library for tours<br /> <br /> © 2016 Andrew Nicols and contributors<br /> <br /> License: GPLv3<br /> <br /> https://github.com/andrewnicols/flexitour<br /> <br /> [[Category:Credits]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Tutorial&diff=52844 2017-08-23T06:34:31Z

<p>Ankitfrenz: /* Plugin types */</p> <hr /> <div>Welcome to Moodle development!<br /> <br /> This is a tutorial to help you learn how to write plugins for Moodle from start to finish, while showing you how to navigate the most important developer documentation along the way.<br /> <br /> PRE-REQUISITES: We assume you are fairly comfortable with [[PHP FAQ|PHP]] in general and that you are able to [[:en:Installing AMP|install a database and web server]] on your local machine. <br /> <br /> If you need to learn PHP, you can see one PHP tutorial at http://www.w3schools.com/php/default.asp, another at http://php.net/manual/en/tutorial.php and several videos in YouTube at https://www.youtube.com/results?search_query=learn+php. There is a very old unmaintained Introduction to Moodle 1.8 Programming course at http://dev.moodle.org/course/view.php?id=2.<br /> <br /> Code examples can be found on GitHub at https://github.com/abgreeve/devcourse where a working plugin is located.<br /> <br /> ==Background==<br /> ===What's in the box===<br /> If you [http://download.moodle.org/ download] Moodle source code or clone it from [https://github.com/moodle/moodle git], you will see a bunch of files and folders. This code consists of [[Core_APIs|Moodle core]] (that consists of the Very core and Core components), [[Moodle_libraries_credits|third party libraries]] and [[Plugin_types|plugins]]. Their mixed locations can be quite confusing at first but as you start working with it it will become more clear. Moodle developers should avoid modifications of the third party libraries (unless required) and core can never call methods defined in plugins. See also [[Communication Between Components]]<br /> <br /> ===Setting up your development environment===<br /> * Moodle uses Git for developement. View the link below for basic information about Git and Moodle.<br /> <br /> links<br /> <br /> * [[Git for developers]]<br /> <br /> ===The Moodle development framework===<br /> ===What type of plugin are you developing?===<br /> * Moodle has lots of different types of plugins.<br /> * There are 24 different categories of plugin listed on the moodle plugin database. Before starting check here to see if someone else has not already created what you are looking for. Perhaps you could contribute to their plugin instead of creating a new one.<br /> <br /> links<br /> <br /> * https://moodle.org/plugins/<br /> * [[Plugin types]]<br /> <br /> ==Let's make a plugin==<br /> ===The skeleton of your plugin===<br /> <br /> You plugin code will be organised into multiple files within a single root directory (and the subdirectories).<br /> <br /> The page [[Plugin files]] provides a list of common plugins files and their purpose.<br /> <br /> See also:<br /> <br /> * [[Moodle architecture]] - general overview of Moodle code architecture<br /> * [[Plugin types]] - list of all supported plugin types<br /> * [https://moodle.org/plugins/ Moodle plugins directory] - repository of contributed plugins for Moodle<br /> * [https://moodle.org/plugins/tool_pluginskel Moodle plugin skeleton generator] - allows to quickly generate code skeleton for a new plugin<br /> <br /> ===Basic page structure===<br /> <br /> The link below explains how to create and display a simple page in Moodle.<br /> <br /> links<br /> <br /> * [[Page API]]<br /> <br /> ===How to support over 100 languages===<br /> * Language files are stored in the &quot;lang&quot; directory. English strings would be found in &quot;lang/en&quot;. Each language contains a file named after the plugin which contains all of the strings. For example the language strings for the assignment activity are found in &quot;mod/assign/lang/en/assign.php&quot;.<br /> * [[:en:Language FAQ#Which_is_the_official_language_for_Moodle.3F| Moodle's default is Australian English]]. <br /> ** American English is a separate language pack (en_us). Please use only Australian (UK) English grammar and spelling when writing Moodle plugins.<br /> ** There is no need to include languages other than the default English, as almost all approved [https://lang.moodle.org/mod/forum/discuss.php?d=2485 plugin strings will be automatically imported into AMOS] for translation by the language packs translators. <br /> * get_string() is used in most cases for displaying text.<br /> * lang_string() is used in situations where the text may not necessarily be displayed.<br /> <br /> &lt;code php&gt;<br /> // Declaration in language file (lang/en/{pluginname}.php)<br /> $string['nameofstring'] = 'Actual string';<br /> &lt;/code&gt;<br /> <br /> The get_string() function takes four parameters, but in this example we are only filling in the first two. The last two parameters are optional. The first parameter is the identifier for the string. The second is the component.<br /> The component will be the name of the language file.<br /> The following example shows a string in the badges block.<br /> &lt;code php&gt;<br /> // Use of string in code.<br /> echo html_writer::tag('p', get_string('numbadgestodisplay', 'block_badges'));<br /> &lt;/code&gt;<br /> <br /> <br /> links<br /> <br /> * [[String API]]<br /> * [[Places to search for lang strings]]<br /> * [[:en:Language customisation]]<br /> * [[Plugin contribution checklist#Strings]]<br /> <br /> ===Moodle file structure===<br /> ==== Automatic Class Loading ====<br /> Automatic class loading helps us to automatically include class files as and when they are required instead of manually including them everytime. Moodle supports automatic class loading. See the link below for the explanation of rules associated with it - <br /> <br /> links<br /> <br /> [[ Automatic class loading]]<br /> <br /> ==== Callbacks ====<br /> You can add a lot of features to your plugin by providing certain callbacks that Moodle expects to be present in your plugin's lib.php file. A detailed list can be found at - <br /> <br /> links<br /> <br /> [[ Callbacks ]]<br /> <br /> ==== Plugin types ====<br /> Moodle supports a wide range of plugin types. The complete list and location to place these plugins can be found at - <br /> <br /> links<br /> <br /> [[ Plugin types ]]<br /> <br /> ==== Core APIs ====<br /> Moodle provides apis for a plugin to interact with core and other external systems. For example you don't have to manually do any SQL queries, Moodle provides it's own DDL and DML layers. The link below lists all major core apis in Moodle - <br /> <br /> links<br /> <br /> [[ Core APIs ]]<br /> <br /> ==== Browser accessible pages ====<br /> Any php file in your plugin will either be browser accessible or be an internal file. <br /> <br /> For browser accessible pages you must include config.php with code something similar to this - <br /> &lt;code php&gt;<br /> require_once('../../config.php');<br /> &lt;/code&gt;<br /> <br /> For internal files the code should use the following - <br /> &lt;code php&gt;<br /> defined('MOODLE_INTERNAL') || die();<br /> &lt;/code&gt;<br /> <br /> ===Add content to your page===<br /> * Content for a page is added through renderers.<br /> * Renderers are typically stored in the &quot;classes/output&quot; directory.<br /> * Putting content in renderers allows themers to override the visual display of the content.<br /> * Very basic information is presented using the html_writer class.<br /> * In most cases templates should be used.<br /> * templates are stored in the &quot;templates&quot; directory. The templates use mustache files.<br /> * Mustache files allow for more generic html with placeholders inserted, that inserts the data (context) at run time.<br /> <br /> The example used below is an admin tool and would be located under admin/tool.<br /> <br /> Step One: Create a class for rendering. This class collects information to display and has a method for formatting that information into a format that the template will understand.<br /> <br /> '''devcourse/classes/output/developer_course_main_page.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use renderable;<br /> use renderer_base;<br /> use templatable;<br /> use stdClass;<br /> <br /> <br /> class developer_course_main_page implements renderable, templatable {<br /> <br /> protected $comment;<br /> <br /> /**<br /> * Construct this renderable.<br /> * @param int $courseid The course record for this page.<br /> */<br /> public function __construct($comment) {<br /> $this-&gt;comment = $comment;<br /> }<br /> <br /> /**<br /> * Export this data so it can be used as the context for a mustache template.<br /> *<br /> * @param renderer_base $output Renderer base.<br /> * @return stdClass<br /> */<br /> public function export_for_template(renderer_base $output) {<br /> $data = new stdClass();<br /> $data-&gt;comment = $this-&gt;comment;<br /> return $data;<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step Two: To render this information a custom renderer is created for the plugin. This renderer class must extend plugin_renderer_base.<br /> <br /> '''devcourse/classes/output/renderer.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> <br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use plugin_renderer_base;<br /> use renderable;<br /> <br /> class renderer extends plugin_renderer_base {<br /> <br /> /**<br /> * Defer to template.<br /> *<br /> * @param developer_course_main_page $page<br /> *<br /> * @return string html for the page<br /> */<br /> public function render_developer_course_main_page(developer_course_main_page $page) {<br /> $data = $page-&gt;export_for_template($this);<br /> return parent::render_from_template('tool_devcourse/developer_course_main_page', $data);<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step three: A mustache template is to then be created. The information is sent to the template and at this point the information is known as the context (not to be confused with the normal definition of context throughout Moodle).<br /> <br /> '''devcourse/templates/developer_course_main_page.mustache'''<br /> &lt;code html&gt;<br /> {{!<br /> @template tool_devcourse/developer_course_main_page<br /> <br /> Example context (json):<br /> {<br /> &quot;comment&quot;: &quot;Example comment for the context&quot;<br /> }<br /> }}<br /> &lt;h2&gt;{{#str}}maintitle, tool_devdoc{{/str}}&lt;/h2&gt;<br /> &lt;div&gt;{{comment}}&lt;/div&gt;<br /> &lt;/code&gt;<br /> This shows an extremely simple mustache template with one item in the context (comment). It also shows how strings are defined in the template.<br /> <br /> Step four: To actually have this template be displayed we get the custom renderer. This chunk of code would be located in a place such as devcourse/index.php after the appropriate setup outlined in the [[Tutorial#Basic_page_structure|basic page structure]].<br /> &lt;code php&gt;<br /> $output = $PAGE-&gt;get_renderer('tool_devcourse');<br /> //Then we get the class for rendering and provide it with information (if needed).<br /> $randomcomment = 'This comment is random';<br /> $page = new \tool_devdoc\output\developer_course_main_page($randomcomment);<br /> //Finally we echo out the template<br /> echo $output-&gt;render($page);<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Output API]]<br /> * [[Output functions]]<br /> * [[Templates]]<br /> * [[Output renderers]]<br /> * [[Renderer]]<br /> * [[Overriding a renderer]]<br /> <br /> ===Adding your plugin into Moodle's navigation===<br /> * The moodle navigation system has hooks which allows plugins to add links to the navigation menu.<br /> * Hooks are located in lib.php. Try to keep lib.php as small as possible as this file is included on every page. Put classes and functions elsewhere.<br /> * Course navigation extension example:<br /> &lt;code php&gt;<br /> function tool_devcourse_extend_navigation_course($navigation, $course, $coursecontext) {<br /> $url = new moodle_url('/admin/tool/devcourse/index.php');<br /> $devcoursenode = navigation_node::create('Development course', $url, navigation_node::TYPE_CUSTOM, 'Dev course', 'devcourse');<br /> $navigation-&gt;add_node($devcoursenode);<br /> }<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Navigation API]]<br /> * [[:en:Navigation]]<br /> <br /> ===Database queries===<br /> * Moodle has a generic database query library. Behind this library are additional libraries which allow Moodle to work with MySQL, PostgreSQL, Oracle, SQL Server, and Maria DB.<br /> * Where possible it is advisable to use the predefined functions rather than write out SQL. Writing SQL has a greater chance of not working with one of the supported databases.<br /> * The return of the select functions tends to be an object or an array of objects.<br /> <br /> Example call to retrieve data from the course table.<br /> &lt;code php&gt;<br /> global $DB;<br /> $courses = $DB-&gt;get_records('course', null, '', 'id, category, fullname, shortname');<br /> &lt;/code&gt;<br /> Example of data returned from the above code.<br /> &lt;code&gt;<br /> Array<br /> (<br /> [43] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 43<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX -Test 5<br /> [shortname] =&gt; xxt5<br /> )<br /> <br /> [5] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 5<br /> [category] =&gt; 1<br /> [fullname] =&gt; With the glossary<br /> [shortname] =&gt; wtg<br /> )<br /> <br /> [39] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 39<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX - Test 1<br /> [shortname] =&gt; xxt1<br /> )<br /> )<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Database]]<br /> * [[Data manipulation API]]<br /> <br /> ===Creating your own database tables===<br /> * We create our database tables in Moodle using the XMLDB editor. This is located in the administration block &quot;Site administration | Development | XMLDB editor&quot;.<br /> * The {plugin}\db directory needs to have write access for the XMLDB editor to be most effective.<br /> * XMLDB editor creates an install.xml file in the db directory. This file will be loaded during the install to create your tables.<br /> * XMLDB editor will produce php update code for adding and updating moodle database tables.<br /> <br /> The XMLDB main page.<br /> <br /> [[{{ns:file}}:xmldb-main.png]]<br /> <br /> Upgrade code generated by the XMLDB<br /> <br /> [[{{ns:file}}:xmldb-upgrade-code.png]]<br /> <br /> links<br /> * [[XMLDB editor]]<br /> * [[Using XMLDB]]<br /> * [[XMLDB Documentation]]<br /> * [[Upgrade API]]<br /> * [[XMLDB introduction]]<br /> <br /> ===Supporting access permissions: roles, capabilities and contexts===<br /> * Capabilities are controlled in &quot;access.php&quot; under the &quot;db&quot; directory.<br /> * This file has an array of capabilities with the following:<br /> ** name<br /> ** possible security risks behind giving this capability.<br /> ** The context that this capability works in.<br /> ** The default roles (teacher, manager, student, etc) that have this capability.<br /> ** Various other information.<br /> * These capabilities are checked in code to allow access to pages, sections, and abilities (saving, deleting, etc).<br /> <br /> links<br /> * [[Access API]]<br /> * [[Roles#Context]]<br /> * [[:en:Category:Capabilities]]<br /> * [[:en:Roles and permissions]]<br /> <br /> ===Adding web forms===<br /> * Moodle has it's own forms library.<br /> * The forms lib includes a lot of accessibility code, and error checking, by default.<br /> * Moodle forms can be displayed in JavaScript using 'fragments'.<br /> <br /> links<br /> <br /> * [[Form API]]<br /> * [[lib/formslib.php Form Definition]]<br /> * [[Fragment]]<br /> <br /> ===Maintaining good security===<br /> * Use the sesskey when directing to pages to do actions.<br /> * Use the appropriate filters when retrieving parameters<br /> <br /> links<br /> <br /> * [[lib/formslib.php Form Definition#Most Commonly Used PARAM .2A Types]]<br /> * [[Output functions#p.28.29 and s.28.29]]<br /> <br /> ===Handling files===<br /> * Files are conceptually stored in file areas.<br /> * Plugins can only access files from it's own component.<br /> <br /> links<br /> <br /> * [[File API]]<br /> * [[File API internals]]<br /> * [[Using the File API in Moodle forms]]<br /> <br /> ===Adding Javascript===<br /> * Moodle is currently using jquery and AMD (Asynchronous Module Definition).<br /> * JavaScript files are located in the &quot;amd/src&quot; directory.<br /> * Use grunt to build your JavaScript.<br /> * Include your JavaScript in php files as follows:<br /> &lt;code php&gt;<br /> $this-&gt;page-&gt;requires-&gt;js_call_amd('{JScriptfilename}');<br /> &lt;/code&gt;<br /> * Can also be included in mustache templates.<br /> <br /> links<br /> <br /> * [[Javascript Modules]]<br /> * [[jQuery]]<br /> * [[Javascript FAQ]]<br /> * [[JavaScript guidelines]]<br /> * [[Grunt]]<br /> <br /> ===Adding events and logging===<br /> * All logging in moodle is done through the events system.<br /> * New events should be located in the &quot;classes/event&quot; directory.<br /> * It is possible to create observers and subscribe to events.<br /> <br /> links<br /> <br /> * [[Event 2]]<br /> * [[Logging 2]]<br /> <br /> ===Accessibility===<br /> <br /> Accessibility is an important consideration while developing a plugin to make sure your plugin is accessible to all users and doesn't discriminate against users with disablities. This often is a mandated requirement in many countries. The links below explain common practices that we follow at Moodle to make the interface more accessible.<br /> <br /> links<br /> * [[Accessibility]]<br /> * [[Usability]]<br /> ===Web Services and AJAX===<br /> * Moodle web services uses the external functions API.<br /> * The recommended way to make AJAX requests is to use the ajax AMD file which uses the external functions API.<br /> * External functions should be located in the &quot;classes/external.php&quot; file.<br /> * A list of services should be included in &quot;db/services.php&quot;. This file is required to register the web services with Moodle.<br /> * The services list is an array which contains:<br /> ** '''classname''' Name of the external class.<br /> ** '''methodname''' The name of the external function.<br /> ** '''classpath''' system path to the external function file.<br /> ** '''description''' Description of the function<br /> ** '''type''' Create, read, update, delete<br /> ** '''ajax''' Can this function be used with ajax?<br /> ** '''capabilities''' Capabilities required to use this function.<br /> <br /> links<br /> <br /> * [[External functions API]]<br /> * [[Adding a web service to a plugin]]<br /> * [[Web services API]]<br /> <br /> ===Using caching to improve performance===<br /> * The main cache used by moodle is the Moodle Universal Cache (MUC).<br /> * The MUC has several cache definitions - <br /> ** Request cache<br /> ** Session cache<br /> ** Application<br /> <br /> links<br /> <br /> * [[The Moodle Universal Cache (MUC)]]<br /> * [[:en:MUC FAQ]]<br /> * [[:en:Caching]]<br /> <br /> ===Supporting backup and restore===<br /> * Supporting backup and restore requires creating several files in the 'backup/moodle2' directory.<br /> * Back requires a class to extend the backup_task of some sort. There may be a specific plugin task to extend.<br /> * Restore requires a class to extend the restore_task of some sort. There may be a specific plugin task to extend.<br /> * The restore steps lib defines the structure of the plugin to be restored.<br /> * The backup steps lib defines steps, settings, attributes, etc.<br /> <br /> links<br /> <br /> * [[Backup 2.0 for developers]] - provides an example of step-by-step implementation of backup support to your plugin<br /> * [[:en:Backup and restore FAQ]]<br /> <br /> ===Supporting automated testing===<br /> * Moodle has two types of automated testing: php unit tests, and behat tests.<br /> * Unit tests are for testing functions.<br /> * Behat tests runs through scenarios.<br /> ** Behat tests follows a script and navigates through moodle pages.<br /> * unit tests should be located in the &quot;tests&quot; directory.<br /> * behat tests should be located in the &quot;tests/behat&quot; directory.<br /> * Tests located in these directories will be run through when a full test run is initiated.<br /> * behat tests are actually feature files and end with the extension &quot;.feature&quot;.<br /> <br /> links<br /> <br /> * [[Writing PHPUnit tests]]<br /> * [[PHPUnit]]<br /> * [[Acceptance testing]]<br /> * [[Behat integration]]<br /> <br /> ==Publishing your plugin==<br /> ===Adding your plugin to moodle.org===<br /> * publish your plugins at https://moodle.org/plugins/<br /> * Publishing plugins on the moodle site leads you through a bunch of steps that need to be completed in order for the plugin to be approved and published.<br /> * Plugins will be run through a pre-checker to give suggestions about possible issues with the code.<br /> <br /> ===Supporting your plugin===<br /> <br /> <br /> =TODO=<br /> <br /> Finishing this tutorial:<br /> # About one or two screens for each section with a very generic overview for beginners, containing links to relevant docs WITH COMMENTS ABOUT QUALITY, USEFULNESS, CAVEATS etc.<br /> # Go through all the linked pages and make sure they are current and accurate.<br /> # Add a worked example to this page, so that each section has suggestions about things to add to the admin tool being built as an exercise. If the code is long, it could be placed on separate pages. A good reference for style is [[Moodle_Mobile_Developing_a_plugin_tutorial]] and [[Blocks]].<br /> <br /> ==See also==<br /> * See [https://moodle.org/mod/forum/discuss.php?d=352360 this forum thread] about Getting Started with Moodle Development.<br /> <br /> =See also these older tutorials =<br /> * [[Blocks|A Step-by-step Guide To Creating Blocks]] <br /> * [[NEWMODULE Tutorial]]<br /> * [http://dev.moodle.org Introduction to Moodle programming (based on Moodle 1.8)]<br /> * [[Moodle_Mobile_Developing_a_plugin_tutorial|Moodle Mobile plugin tutorial]]<br /> * [[Category:Tutorial|Other tutorials in these docs]]<br /> <br /> [[Category:Tutorial]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Tutorial&diff=52843 2017-08-23T06:21:30Z

<p>Ankitfrenz: /* Core APIs */</p> <hr /> <div>Welcome to Moodle development!<br /> <br /> This is a tutorial to help you learn how to write plugins for Moodle from start to finish, while showing you how to navigate the most important developer documentation along the way.<br /> <br /> PRE-REQUISITES: We assume you are fairly comfortable with [[PHP FAQ|PHP]] in general and that you are able to [[:en:Installing AMP|install a database and web server]] on your local machine. <br /> <br /> If you need to learn PHP, you can see one PHP tutorial at http://www.w3schools.com/php/default.asp, another at http://php.net/manual/en/tutorial.php and several videos in YouTube at https://www.youtube.com/results?search_query=learn+php. There is a very old unmaintained Introduction to Moodle 1.8 Programming course at http://dev.moodle.org/course/view.php?id=2.<br /> <br /> Code examples can be found on GitHub at https://github.com/abgreeve/devcourse where a working plugin is located.<br /> <br /> ==Background==<br /> ===What's in the box===<br /> If you [http://download.moodle.org/ download] Moodle source code or clone it from [https://github.com/moodle/moodle git], you will see a bunch of files and folders. This code consists of [[Core_APIs|Moodle core]] (that consists of the Very core and Core components), [[Moodle_libraries_credits|third party libraries]] and [[Plugin_types|plugins]]. Their mixed locations can be quite confusing at first but as you start working with it it will become more clear. Moodle developers should avoid modifications of the third party libraries (unless required) and core can never call methods defined in plugins. See also [[Communication Between Components]]<br /> <br /> ===Setting up your development environment===<br /> * Moodle uses Git for developement. View the link below for basic information about Git and Moodle.<br /> <br /> links<br /> <br /> * [[Git for developers]]<br /> <br /> ===The Moodle development framework===<br /> ===What type of plugin are you developing?===<br /> * Moodle has lots of different types of plugins.<br /> * There are 24 different categories of plugin listed on the moodle plugin database. Before starting check here to see if someone else has not already created what you are looking for. Perhaps you could contribute to their plugin instead of creating a new one.<br /> <br /> links<br /> <br /> * https://moodle.org/plugins/<br /> * [[Plugin types]]<br /> <br /> ==Let's make a plugin==<br /> ===The skeleton of your plugin===<br /> <br /> You plugin code will be organised into multiple files within a single root directory (and the subdirectories).<br /> <br /> The page [[Plugin files]] provides a list of common plugins files and their purpose.<br /> <br /> See also:<br /> <br /> * [[Moodle architecture]] - general overview of Moodle code architecture<br /> * [[Plugin types]] - list of all supported plugin types<br /> * [https://moodle.org/plugins/ Moodle plugins directory] - repository of contributed plugins for Moodle<br /> * [https://moodle.org/plugins/tool_pluginskel Moodle plugin skeleton generator] - allows to quickly generate code skeleton for a new plugin<br /> <br /> ===Basic page structure===<br /> <br /> The link below explains how to create and display a simple page in Moodle.<br /> <br /> links<br /> <br /> * [[Page API]]<br /> <br /> ===How to support over 100 languages===<br /> * Language files are stored in the &quot;lang&quot; directory. English strings would be found in &quot;lang/en&quot;. Each language contains a file named after the plugin which contains all of the strings. For example the language strings for the assignment activity are found in &quot;mod/assign/lang/en/assign.php&quot;.<br /> * [[:en:Language FAQ#Which_is_the_official_language_for_Moodle.3F| Moodle's default is Australian English]]. <br /> ** American English is a separate language pack (en_us). Please use only Australian (UK) English grammar and spelling when writing Moodle plugins.<br /> ** There is no need to include languages other than the default English, as almost all approved [https://lang.moodle.org/mod/forum/discuss.php?d=2485 plugin strings will be automatically imported into AMOS] for translation by the language packs translators. <br /> * get_string() is used in most cases for displaying text.<br /> * lang_string() is used in situations where the text may not necessarily be displayed.<br /> <br /> &lt;code php&gt;<br /> // Declaration in language file (lang/en/{pluginname}.php)<br /> $string['nameofstring'] = 'Actual string';<br /> &lt;/code&gt;<br /> <br /> The get_string() function takes four parameters, but in this example we are only filling in the first two. The last two parameters are optional. The first parameter is the identifier for the string. The second is the component.<br /> The component will be the name of the language file.<br /> The following example shows a string in the badges block.<br /> &lt;code php&gt;<br /> // Use of string in code.<br /> echo html_writer::tag('p', get_string('numbadgestodisplay', 'block_badges'));<br /> &lt;/code&gt;<br /> <br /> <br /> links<br /> <br /> * [[String API]]<br /> * [[Places to search for lang strings]]<br /> * [[:en:Language customisation]]<br /> * [[Plugin contribution checklist#Strings]]<br /> <br /> ===Moodle file structure===<br /> ==== Automatic Class Loading ====<br /> Automatic class loading helps us to automatically include class files as and when they are required instead of manually including them everytime. Moodle supports automatic class loading. See the link below for the explanation of rules associated with it - <br /> <br /> links<br /> <br /> [[ Automatic class loading]]<br /> <br /> ==== Callbacks ====<br /> You can add a lot of features to your plugin by providing certain callbacks that Moodle expects to be present in your plugin's lib.php file. A detailed list can be found at - <br /> <br /> links<br /> <br /> [[ Callbacks ]]<br /> <br /> ==== Plugin types ====<br /> Moodle supports a wide range of plugin types. The complete list can be found at - <br /> <br /> links<br /> <br /> [[ Plugin types ]]<br /> <br /> ==== Core APIs ====<br /> Moodle provides apis for a plugin to interact with core and other external systems. For example you don't have to manually do any SQL queries, Moodle provides it's own DDL and DML layers. The link below lists all major core apis in Moodle - <br /> <br /> links<br /> <br /> [[ Core APIs ]]<br /> <br /> ==== Browser accessible pages ====<br /> Any php file in your plugin will either be browser accessible or be an internal file. <br /> <br /> For browser accessible pages you must include config.php with code something similar to this - <br /> &lt;code php&gt;<br /> require_once('../../config.php');<br /> &lt;/code&gt;<br /> <br /> For internal files the code should use the following - <br /> &lt;code php&gt;<br /> defined('MOODLE_INTERNAL') || die();<br /> &lt;/code&gt;<br /> <br /> ===Add content to your page===<br /> * Content for a page is added through renderers.<br /> * Renderers are typically stored in the &quot;classes/output&quot; directory.<br /> * Putting content in renderers allows themers to override the visual display of the content.<br /> * Very basic information is presented using the html_writer class.<br /> * In most cases templates should be used.<br /> * templates are stored in the &quot;templates&quot; directory. The templates use mustache files.<br /> * Mustache files allow for more generic html with placeholders inserted, that inserts the data (context) at run time.<br /> <br /> The example used below is an admin tool and would be located under admin/tool.<br /> <br /> Step One: Create a class for rendering. This class collects information to display and has a method for formatting that information into a format that the template will understand.<br /> <br /> '''devcourse/classes/output/developer_course_main_page.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use renderable;<br /> use renderer_base;<br /> use templatable;<br /> use stdClass;<br /> <br /> <br /> class developer_course_main_page implements renderable, templatable {<br /> <br /> protected $comment;<br /> <br /> /**<br /> * Construct this renderable.<br /> * @param int $courseid The course record for this page.<br /> */<br /> public function __construct($comment) {<br /> $this-&gt;comment = $comment;<br /> }<br /> <br /> /**<br /> * Export this data so it can be used as the context for a mustache template.<br /> *<br /> * @param renderer_base $output Renderer base.<br /> * @return stdClass<br /> */<br /> public function export_for_template(renderer_base $output) {<br /> $data = new stdClass();<br /> $data-&gt;comment = $this-&gt;comment;<br /> return $data;<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step Two: To render this information a custom renderer is created for the plugin. This renderer class must extend plugin_renderer_base.<br /> <br /> '''devcourse/classes/output/renderer.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> <br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use plugin_renderer_base;<br /> use renderable;<br /> <br /> class renderer extends plugin_renderer_base {<br /> <br /> /**<br /> * Defer to template.<br /> *<br /> * @param developer_course_main_page $page<br /> *<br /> * @return string html for the page<br /> */<br /> public function render_developer_course_main_page(developer_course_main_page $page) {<br /> $data = $page-&gt;export_for_template($this);<br /> return parent::render_from_template('tool_devcourse/developer_course_main_page', $data);<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step three: A mustache template is to then be created. The information is sent to the template and at this point the information is known as the context (not to be confused with the normal definition of context throughout Moodle).<br /> <br /> '''devcourse/templates/developer_course_main_page.mustache'''<br /> &lt;code html&gt;<br /> {{!<br /> @template tool_devcourse/developer_course_main_page<br /> <br /> Example context (json):<br /> {<br /> &quot;comment&quot;: &quot;Example comment for the context&quot;<br /> }<br /> }}<br /> &lt;h2&gt;{{#str}}maintitle, tool_devdoc{{/str}}&lt;/h2&gt;<br /> &lt;div&gt;{{comment}}&lt;/div&gt;<br /> &lt;/code&gt;<br /> This shows an extremely simple mustache template with one item in the context (comment). It also shows how strings are defined in the template.<br /> <br /> Step four: To actually have this template be displayed we get the custom renderer. This chunk of code would be located in a place such as devcourse/index.php after the appropriate setup outlined in the [[Tutorial#Basic_page_structure|basic page structure]].<br /> &lt;code php&gt;<br /> $output = $PAGE-&gt;get_renderer('tool_devcourse');<br /> //Then we get the class for rendering and provide it with information (if needed).<br /> $randomcomment = 'This comment is random';<br /> $page = new \tool_devdoc\output\developer_course_main_page($randomcomment);<br /> //Finally we echo out the template<br /> echo $output-&gt;render($page);<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Output API]]<br /> * [[Output functions]]<br /> * [[Templates]]<br /> * [[Output renderers]]<br /> * [[Renderer]]<br /> * [[Overriding a renderer]]<br /> <br /> ===Adding your plugin into Moodle's navigation===<br /> * The moodle navigation system has hooks which allows plugins to add links to the navigation menu.<br /> * Hooks are located in lib.php. Try to keep lib.php as small as possible as this file is included on every page. Put classes and functions elsewhere.<br /> * Course navigation extension example:<br /> &lt;code php&gt;<br /> function tool_devcourse_extend_navigation_course($navigation, $course, $coursecontext) {<br /> $url = new moodle_url('/admin/tool/devcourse/index.php');<br /> $devcoursenode = navigation_node::create('Development course', $url, navigation_node::TYPE_CUSTOM, 'Dev course', 'devcourse');<br /> $navigation-&gt;add_node($devcoursenode);<br /> }<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Navigation API]]<br /> * [[:en:Navigation]]<br /> <br /> ===Database queries===<br /> * Moodle has a generic database query library. Behind this library are additional libraries which allow Moodle to work with MySQL, PostgreSQL, Oracle, SQL Server, and Maria DB.<br /> * Where possible it is advisable to use the predefined functions rather than write out SQL. Writing SQL has a greater chance of not working with one of the supported databases.<br /> * The return of the select functions tends to be an object or an array of objects.<br /> <br /> Example call to retrieve data from the course table.<br /> &lt;code php&gt;<br /> global $DB;<br /> $courses = $DB-&gt;get_records('course', null, '', 'id, category, fullname, shortname');<br /> &lt;/code&gt;<br /> Example of data returned from the above code.<br /> &lt;code&gt;<br /> Array<br /> (<br /> [43] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 43<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX -Test 5<br /> [shortname] =&gt; xxt5<br /> )<br /> <br /> [5] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 5<br /> [category] =&gt; 1<br /> [fullname] =&gt; With the glossary<br /> [shortname] =&gt; wtg<br /> )<br /> <br /> [39] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 39<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX - Test 1<br /> [shortname] =&gt; xxt1<br /> )<br /> )<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Database]]<br /> * [[Data manipulation API]]<br /> <br /> ===Creating your own database tables===<br /> * We create our database tables in Moodle using the XMLDB editor. This is located in the administration block &quot;Site administration | Development | XMLDB editor&quot;.<br /> * The {plugin}\db directory needs to have write access for the XMLDB editor to be most effective.<br /> * XMLDB editor creates an install.xml file in the db directory. This file will be loaded during the install to create your tables.<br /> * XMLDB editor will produce php update code for adding and updating moodle database tables.<br /> <br /> The XMLDB main page.<br /> <br /> [[{{ns:file}}:xmldb-main.png]]<br /> <br /> Upgrade code generated by the XMLDB<br /> <br /> [[{{ns:file}}:xmldb-upgrade-code.png]]<br /> <br /> links<br /> * [[XMLDB editor]]<br /> * [[Using XMLDB]]<br /> * [[XMLDB Documentation]]<br /> * [[Upgrade API]]<br /> * [[XMLDB introduction]]<br /> <br /> ===Supporting access permissions: roles, capabilities and contexts===<br /> * Capabilities are controlled in &quot;access.php&quot; under the &quot;db&quot; directory.<br /> * This file has an array of capabilities with the following:<br /> ** name<br /> ** possible security risks behind giving this capability.<br /> ** The context that this capability works in.<br /> ** The default roles (teacher, manager, student, etc) that have this capability.<br /> ** Various other information.<br /> * These capabilities are checked in code to allow access to pages, sections, and abilities (saving, deleting, etc).<br /> <br /> links<br /> * [[Access API]]<br /> * [[Roles#Context]]<br /> * [[:en:Category:Capabilities]]<br /> * [[:en:Roles and permissions]]<br /> <br /> ===Adding web forms===<br /> * Moodle has it's own forms library.<br /> * The forms lib includes a lot of accessibility code, and error checking, by default.<br /> * Moodle forms can be displayed in JavaScript using 'fragments'.<br /> <br /> links<br /> <br /> * [[Form API]]<br /> * [[lib/formslib.php Form Definition]]<br /> * [[Fragment]]<br /> <br /> ===Maintaining good security===<br /> * Use the sesskey when directing to pages to do actions.<br /> * Use the appropriate filters when retrieving parameters<br /> <br /> links<br /> <br /> * [[lib/formslib.php Form Definition#Most Commonly Used PARAM .2A Types]]<br /> * [[Output functions#p.28.29 and s.28.29]]<br /> <br /> ===Handling files===<br /> * Files are conceptually stored in file areas.<br /> * Plugins can only access files from it's own component.<br /> <br /> links<br /> <br /> * [[File API]]<br /> * [[File API internals]]<br /> * [[Using the File API in Moodle forms]]<br /> <br /> ===Adding Javascript===<br /> * Moodle is currently using jquery and AMD (Asynchronous Module Definition).<br /> * JavaScript files are located in the &quot;amd/src&quot; directory.<br /> * Use grunt to build your JavaScript.<br /> * Include your JavaScript in php files as follows:<br /> &lt;code php&gt;<br /> $this-&gt;page-&gt;requires-&gt;js_call_amd('{JScriptfilename}');<br /> &lt;/code&gt;<br /> * Can also be included in mustache templates.<br /> <br /> links<br /> <br /> * [[Javascript Modules]]<br /> * [[jQuery]]<br /> * [[Javascript FAQ]]<br /> * [[JavaScript guidelines]]<br /> * [[Grunt]]<br /> <br /> ===Adding events and logging===<br /> * All logging in moodle is done through the events system.<br /> * New events should be located in the &quot;classes/event&quot; directory.<br /> * It is possible to create observers and subscribe to events.<br /> <br /> links<br /> <br /> * [[Event 2]]<br /> * [[Logging 2]]<br /> <br /> ===Accessibility===<br /> <br /> Accessibility is an important consideration while developing a plugin to make sure your plugin is accessible to all users and doesn't discriminate against users with disablities. This often is a mandated requirement in many countries. The links below explain common practices that we follow at Moodle to make the interface more accessible.<br /> <br /> links<br /> * [[Accessibility]]<br /> * [[Usability]]<br /> ===Web Services and AJAX===<br /> * Moodle web services uses the external functions API.<br /> * The recommended way to make AJAX requests is to use the ajax AMD file which uses the external functions API.<br /> * External functions should be located in the &quot;classes/external.php&quot; file.<br /> * A list of services should be included in &quot;db/services.php&quot;. This file is required to register the web services with Moodle.<br /> * The services list is an array which contains:<br /> ** '''classname''' Name of the external class.<br /> ** '''methodname''' The name of the external function.<br /> ** '''classpath''' system path to the external function file.<br /> ** '''description''' Description of the function<br /> ** '''type''' Create, read, update, delete<br /> ** '''ajax''' Can this function be used with ajax?<br /> ** '''capabilities''' Capabilities required to use this function.<br /> <br /> links<br /> <br /> * [[External functions API]]<br /> * [[Adding a web service to a plugin]]<br /> * [[Web services API]]<br /> <br /> ===Using caching to improve performance===<br /> * The main cache used by moodle is the Moodle Universal Cache (MUC).<br /> * The MUC has several cache definitions - <br /> ** Request cache<br /> ** Session cache<br /> ** Application<br /> <br /> links<br /> <br /> * [[The Moodle Universal Cache (MUC)]]<br /> * [[:en:MUC FAQ]]<br /> * [[:en:Caching]]<br /> <br /> ===Supporting backup and restore===<br /> * Supporting backup and restore requires creating several files in the 'backup/moodle2' directory.<br /> * Back requires a class to extend the backup_task of some sort. There may be a specific plugin task to extend.<br /> * Restore requires a class to extend the restore_task of some sort. There may be a specific plugin task to extend.<br /> * The restore steps lib defines the structure of the plugin to be restored.<br /> * The backup steps lib defines steps, settings, attributes, etc.<br /> <br /> links<br /> <br /> * [[Backup 2.0 for developers]] - provides an example of step-by-step implementation of backup support to your plugin<br /> * [[:en:Backup and restore FAQ]]<br /> <br /> ===Supporting automated testing===<br /> * Moodle has two types of automated testing: php unit tests, and behat tests.<br /> * Unit tests are for testing functions.<br /> * Behat tests runs through scenarios.<br /> ** Behat tests follows a script and navigates through moodle pages.<br /> * unit tests should be located in the &quot;tests&quot; directory.<br /> * behat tests should be located in the &quot;tests/behat&quot; directory.<br /> * Tests located in these directories will be run through when a full test run is initiated.<br /> * behat tests are actually feature files and end with the extension &quot;.feature&quot;.<br /> <br /> links<br /> <br /> * [[Writing PHPUnit tests]]<br /> * [[PHPUnit]]<br /> * [[Acceptance testing]]<br /> * [[Behat integration]]<br /> <br /> ==Publishing your plugin==<br /> ===Adding your plugin to moodle.org===<br /> * publish your plugins at https://moodle.org/plugins/<br /> * Publishing plugins on the moodle site leads you through a bunch of steps that need to be completed in order for the plugin to be approved and published.<br /> * Plugins will be run through a pre-checker to give suggestions about possible issues with the code.<br /> <br /> ===Supporting your plugin===<br /> <br /> <br /> =TODO=<br /> <br /> Finishing this tutorial:<br /> # About one or two screens for each section with a very generic overview for beginners, containing links to relevant docs WITH COMMENTS ABOUT QUALITY, USEFULNESS, CAVEATS etc.<br /> # Go through all the linked pages and make sure they are current and accurate.<br /> # Add a worked example to this page, so that each section has suggestions about things to add to the admin tool being built as an exercise. If the code is long, it could be placed on separate pages. A good reference for style is [[Moodle_Mobile_Developing_a_plugin_tutorial]] and [[Blocks]].<br /> <br /> ==See also==<br /> * See [https://moodle.org/mod/forum/discuss.php?d=352360 this forum thread] about Getting Started with Moodle Development.<br /> <br /> =See also these older tutorials =<br /> * [[Blocks|A Step-by-step Guide To Creating Blocks]] <br /> * [[NEWMODULE Tutorial]]<br /> * [http://dev.moodle.org Introduction to Moodle programming (based on Moodle 1.8)]<br /> * [[Moodle_Mobile_Developing_a_plugin_tutorial|Moodle Mobile plugin tutorial]]<br /> * [[Category:Tutorial|Other tutorials in these docs]]<br /> <br /> [[Category:Tutorial]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Tutorial&diff=52842 2017-08-23T06:20:11Z

<p>Ankitfrenz: /* Automatic Class Loading */</p> <hr /> <div>Welcome to Moodle development!<br /> <br /> This is a tutorial to help you learn how to write plugins for Moodle from start to finish, while showing you how to navigate the most important developer documentation along the way.<br /> <br /> PRE-REQUISITES: We assume you are fairly comfortable with [[PHP FAQ|PHP]] in general and that you are able to [[:en:Installing AMP|install a database and web server]] on your local machine. <br /> <br /> If you need to learn PHP, you can see one PHP tutorial at http://www.w3schools.com/php/default.asp, another at http://php.net/manual/en/tutorial.php and several videos in YouTube at https://www.youtube.com/results?search_query=learn+php. There is a very old unmaintained Introduction to Moodle 1.8 Programming course at http://dev.moodle.org/course/view.php?id=2.<br /> <br /> Code examples can be found on GitHub at https://github.com/abgreeve/devcourse where a working plugin is located.<br /> <br /> ==Background==<br /> ===What's in the box===<br /> If you [http://download.moodle.org/ download] Moodle source code or clone it from [https://github.com/moodle/moodle git], you will see a bunch of files and folders. This code consists of [[Core_APIs|Moodle core]] (that consists of the Very core and Core components), [[Moodle_libraries_credits|third party libraries]] and [[Plugin_types|plugins]]. Their mixed locations can be quite confusing at first but as you start working with it it will become more clear. Moodle developers should avoid modifications of the third party libraries (unless required) and core can never call methods defined in plugins. See also [[Communication Between Components]]<br /> <br /> ===Setting up your development environment===<br /> * Moodle uses Git for developement. View the link below for basic information about Git and Moodle.<br /> <br /> links<br /> <br /> * [[Git for developers]]<br /> <br /> ===The Moodle development framework===<br /> ===What type of plugin are you developing?===<br /> * Moodle has lots of different types of plugins.<br /> * There are 24 different categories of plugin listed on the moodle plugin database. Before starting check here to see if someone else has not already created what you are looking for. Perhaps you could contribute to their plugin instead of creating a new one.<br /> <br /> links<br /> <br /> * https://moodle.org/plugins/<br /> * [[Plugin types]]<br /> <br /> ==Let's make a plugin==<br /> ===The skeleton of your plugin===<br /> <br /> You plugin code will be organised into multiple files within a single root directory (and the subdirectories).<br /> <br /> The page [[Plugin files]] provides a list of common plugins files and their purpose.<br /> <br /> See also:<br /> <br /> * [[Moodle architecture]] - general overview of Moodle code architecture<br /> * [[Plugin types]] - list of all supported plugin types<br /> * [https://moodle.org/plugins/ Moodle plugins directory] - repository of contributed plugins for Moodle<br /> * [https://moodle.org/plugins/tool_pluginskel Moodle plugin skeleton generator] - allows to quickly generate code skeleton for a new plugin<br /> <br /> ===Basic page structure===<br /> <br /> The link below explains how to create and display a simple page in Moodle.<br /> <br /> links<br /> <br /> * [[Page API]]<br /> <br /> ===How to support over 100 languages===<br /> * Language files are stored in the &quot;lang&quot; directory. English strings would be found in &quot;lang/en&quot;. Each language contains a file named after the plugin which contains all of the strings. For example the language strings for the assignment activity are found in &quot;mod/assign/lang/en/assign.php&quot;.<br /> * [[:en:Language FAQ#Which_is_the_official_language_for_Moodle.3F| Moodle's default is Australian English]]. <br /> ** American English is a separate language pack (en_us). Please use only Australian (UK) English grammar and spelling when writing Moodle plugins.<br /> ** There is no need to include languages other than the default English, as almost all approved [https://lang.moodle.org/mod/forum/discuss.php?d=2485 plugin strings will be automatically imported into AMOS] for translation by the language packs translators. <br /> * get_string() is used in most cases for displaying text.<br /> * lang_string() is used in situations where the text may not necessarily be displayed.<br /> <br /> &lt;code php&gt;<br /> // Declaration in language file (lang/en/{pluginname}.php)<br /> $string['nameofstring'] = 'Actual string';<br /> &lt;/code&gt;<br /> <br /> The get_string() function takes four parameters, but in this example we are only filling in the first two. The last two parameters are optional. The first parameter is the identifier for the string. The second is the component.<br /> The component will be the name of the language file.<br /> The following example shows a string in the badges block.<br /> &lt;code php&gt;<br /> // Use of string in code.<br /> echo html_writer::tag('p', get_string('numbadgestodisplay', 'block_badges'));<br /> &lt;/code&gt;<br /> <br /> <br /> links<br /> <br /> * [[String API]]<br /> * [[Places to search for lang strings]]<br /> * [[:en:Language customisation]]<br /> * [[Plugin contribution checklist#Strings]]<br /> <br /> ===Moodle file structure===<br /> ==== Automatic Class Loading ====<br /> Automatic class loading helps us to automatically include class files as and when they are required instead of manually including them everytime. Moodle supports automatic class loading. See the link below for the explanation of rules associated with it - <br /> <br /> links<br /> <br /> [[ Automatic class loading]]<br /> <br /> ==== Callbacks ====<br /> You can add a lot of features to your plugin by providing certain callbacks that Moodle expects to be present in your plugin's lib.php file. A detailed list can be found at - <br /> <br /> links<br /> <br /> [[ Callbacks ]]<br /> <br /> ==== Plugin types ====<br /> Moodle supports a wide range of plugin types. The complete list can be found at - <br /> <br /> links<br /> <br /> [[ Plugin types ]]<br /> <br /> ==== Core APIs ====<br /> The link below lists all major core apis in Moodle - <br /> <br /> links<br /> <br /> [[ Core APIs ]]<br /> <br /> ==== Browser accessible pages ====<br /> Any php file in your plugin will either be browser accessible or be an internal file. <br /> <br /> For browser accessible pages you must include config.php with code something similar to this - <br /> &lt;code php&gt;<br /> require_once('../../config.php');<br /> &lt;/code&gt;<br /> <br /> For internal files the code should use the following - <br /> &lt;code php&gt;<br /> defined('MOODLE_INTERNAL') || die();<br /> &lt;/code&gt;<br /> <br /> ===Add content to your page===<br /> * Content for a page is added through renderers.<br /> * Renderers are typically stored in the &quot;classes/output&quot; directory.<br /> * Putting content in renderers allows themers to override the visual display of the content.<br /> * Very basic information is presented using the html_writer class.<br /> * In most cases templates should be used.<br /> * templates are stored in the &quot;templates&quot; directory. The templates use mustache files.<br /> * Mustache files allow for more generic html with placeholders inserted, that inserts the data (context) at run time.<br /> <br /> The example used below is an admin tool and would be located under admin/tool.<br /> <br /> Step One: Create a class for rendering. This class collects information to display and has a method for formatting that information into a format that the template will understand.<br /> <br /> '''devcourse/classes/output/developer_course_main_page.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use renderable;<br /> use renderer_base;<br /> use templatable;<br /> use stdClass;<br /> <br /> <br /> class developer_course_main_page implements renderable, templatable {<br /> <br /> protected $comment;<br /> <br /> /**<br /> * Construct this renderable.<br /> * @param int $courseid The course record for this page.<br /> */<br /> public function __construct($comment) {<br /> $this-&gt;comment = $comment;<br /> }<br /> <br /> /**<br /> * Export this data so it can be used as the context for a mustache template.<br /> *<br /> * @param renderer_base $output Renderer base.<br /> * @return stdClass<br /> */<br /> public function export_for_template(renderer_base $output) {<br /> $data = new stdClass();<br /> $data-&gt;comment = $this-&gt;comment;<br /> return $data;<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step Two: To render this information a custom renderer is created for the plugin. This renderer class must extend plugin_renderer_base.<br /> <br /> '''devcourse/classes/output/renderer.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> <br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use plugin_renderer_base;<br /> use renderable;<br /> <br /> class renderer extends plugin_renderer_base {<br /> <br /> /**<br /> * Defer to template.<br /> *<br /> * @param developer_course_main_page $page<br /> *<br /> * @return string html for the page<br /> */<br /> public function render_developer_course_main_page(developer_course_main_page $page) {<br /> $data = $page-&gt;export_for_template($this);<br /> return parent::render_from_template('tool_devcourse/developer_course_main_page', $data);<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step three: A mustache template is to then be created. The information is sent to the template and at this point the information is known as the context (not to be confused with the normal definition of context throughout Moodle).<br /> <br /> '''devcourse/templates/developer_course_main_page.mustache'''<br /> &lt;code html&gt;<br /> {{!<br /> @template tool_devcourse/developer_course_main_page<br /> <br /> Example context (json):<br /> {<br /> &quot;comment&quot;: &quot;Example comment for the context&quot;<br /> }<br /> }}<br /> &lt;h2&gt;{{#str}}maintitle, tool_devdoc{{/str}}&lt;/h2&gt;<br /> &lt;div&gt;{{comment}}&lt;/div&gt;<br /> &lt;/code&gt;<br /> This shows an extremely simple mustache template with one item in the context (comment). It also shows how strings are defined in the template.<br /> <br /> Step four: To actually have this template be displayed we get the custom renderer. This chunk of code would be located in a place such as devcourse/index.php after the appropriate setup outlined in the [[Tutorial#Basic_page_structure|basic page structure]].<br /> &lt;code php&gt;<br /> $output = $PAGE-&gt;get_renderer('tool_devcourse');<br /> //Then we get the class for rendering and provide it with information (if needed).<br /> $randomcomment = 'This comment is random';<br /> $page = new \tool_devdoc\output\developer_course_main_page($randomcomment);<br /> //Finally we echo out the template<br /> echo $output-&gt;render($page);<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Output API]]<br /> * [[Output functions]]<br /> * [[Templates]]<br /> * [[Output renderers]]<br /> * [[Renderer]]<br /> * [[Overriding a renderer]]<br /> <br /> ===Adding your plugin into Moodle's navigation===<br /> * The moodle navigation system has hooks which allows plugins to add links to the navigation menu.<br /> * Hooks are located in lib.php. Try to keep lib.php as small as possible as this file is included on every page. Put classes and functions elsewhere.<br /> * Course navigation extension example:<br /> &lt;code php&gt;<br /> function tool_devcourse_extend_navigation_course($navigation, $course, $coursecontext) {<br /> $url = new moodle_url('/admin/tool/devcourse/index.php');<br /> $devcoursenode = navigation_node::create('Development course', $url, navigation_node::TYPE_CUSTOM, 'Dev course', 'devcourse');<br /> $navigation-&gt;add_node($devcoursenode);<br /> }<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Navigation API]]<br /> * [[:en:Navigation]]<br /> <br /> ===Database queries===<br /> * Moodle has a generic database query library. Behind this library are additional libraries which allow Moodle to work with MySQL, PostgreSQL, Oracle, SQL Server, and Maria DB.<br /> * Where possible it is advisable to use the predefined functions rather than write out SQL. Writing SQL has a greater chance of not working with one of the supported databases.<br /> * The return of the select functions tends to be an object or an array of objects.<br /> <br /> Example call to retrieve data from the course table.<br /> &lt;code php&gt;<br /> global $DB;<br /> $courses = $DB-&gt;get_records('course', null, '', 'id, category, fullname, shortname');<br /> &lt;/code&gt;<br /> Example of data returned from the above code.<br /> &lt;code&gt;<br /> Array<br /> (<br /> [43] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 43<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX -Test 5<br /> [shortname] =&gt; xxt5<br /> )<br /> <br /> [5] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 5<br /> [category] =&gt; 1<br /> [fullname] =&gt; With the glossary<br /> [shortname] =&gt; wtg<br /> )<br /> <br /> [39] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 39<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX - Test 1<br /> [shortname] =&gt; xxt1<br /> )<br /> )<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Database]]<br /> * [[Data manipulation API]]<br /> <br /> ===Creating your own database tables===<br /> * We create our database tables in Moodle using the XMLDB editor. This is located in the administration block &quot;Site administration | Development | XMLDB editor&quot;.<br /> * The {plugin}\db directory needs to have write access for the XMLDB editor to be most effective.<br /> * XMLDB editor creates an install.xml file in the db directory. This file will be loaded during the install to create your tables.<br /> * XMLDB editor will produce php update code for adding and updating moodle database tables.<br /> <br /> The XMLDB main page.<br /> <br /> [[{{ns:file}}:xmldb-main.png]]<br /> <br /> Upgrade code generated by the XMLDB<br /> <br /> [[{{ns:file}}:xmldb-upgrade-code.png]]<br /> <br /> links<br /> * [[XMLDB editor]]<br /> * [[Using XMLDB]]<br /> * [[XMLDB Documentation]]<br /> * [[Upgrade API]]<br /> * [[XMLDB introduction]]<br /> <br /> ===Supporting access permissions: roles, capabilities and contexts===<br /> * Capabilities are controlled in &quot;access.php&quot; under the &quot;db&quot; directory.<br /> * This file has an array of capabilities with the following:<br /> ** name<br /> ** possible security risks behind giving this capability.<br /> ** The context that this capability works in.<br /> ** The default roles (teacher, manager, student, etc) that have this capability.<br /> ** Various other information.<br /> * These capabilities are checked in code to allow access to pages, sections, and abilities (saving, deleting, etc).<br /> <br /> links<br /> * [[Access API]]<br /> * [[Roles#Context]]<br /> * [[:en:Category:Capabilities]]<br /> * [[:en:Roles and permissions]]<br /> <br /> ===Adding web forms===<br /> * Moodle has it's own forms library.<br /> * The forms lib includes a lot of accessibility code, and error checking, by default.<br /> * Moodle forms can be displayed in JavaScript using 'fragments'.<br /> <br /> links<br /> <br /> * [[Form API]]<br /> * [[lib/formslib.php Form Definition]]<br /> * [[Fragment]]<br /> <br /> ===Maintaining good security===<br /> * Use the sesskey when directing to pages to do actions.<br /> * Use the appropriate filters when retrieving parameters<br /> <br /> links<br /> <br /> * [[lib/formslib.php Form Definition#Most Commonly Used PARAM .2A Types]]<br /> * [[Output functions#p.28.29 and s.28.29]]<br /> <br /> ===Handling files===<br /> * Files are conceptually stored in file areas.<br /> * Plugins can only access files from it's own component.<br /> <br /> links<br /> <br /> * [[File API]]<br /> * [[File API internals]]<br /> * [[Using the File API in Moodle forms]]<br /> <br /> ===Adding Javascript===<br /> * Moodle is currently using jquery and AMD (Asynchronous Module Definition).<br /> * JavaScript files are located in the &quot;amd/src&quot; directory.<br /> * Use grunt to build your JavaScript.<br /> * Include your JavaScript in php files as follows:<br /> &lt;code php&gt;<br /> $this-&gt;page-&gt;requires-&gt;js_call_amd('{JScriptfilename}');<br /> &lt;/code&gt;<br /> * Can also be included in mustache templates.<br /> <br /> links<br /> <br /> * [[Javascript Modules]]<br /> * [[jQuery]]<br /> * [[Javascript FAQ]]<br /> * [[JavaScript guidelines]]<br /> * [[Grunt]]<br /> <br /> ===Adding events and logging===<br /> * All logging in moodle is done through the events system.<br /> * New events should be located in the &quot;classes/event&quot; directory.<br /> * It is possible to create observers and subscribe to events.<br /> <br /> links<br /> <br /> * [[Event 2]]<br /> * [[Logging 2]]<br /> <br /> ===Accessibility===<br /> <br /> Accessibility is an important consideration while developing a plugin to make sure your plugin is accessible to all users and doesn't discriminate against users with disablities. This often is a mandated requirement in many countries. The links below explain common practices that we follow at Moodle to make the interface more accessible.<br /> <br /> links<br /> * [[Accessibility]]<br /> * [[Usability]]<br /> ===Web Services and AJAX===<br /> * Moodle web services uses the external functions API.<br /> * The recommended way to make AJAX requests is to use the ajax AMD file which uses the external functions API.<br /> * External functions should be located in the &quot;classes/external.php&quot; file.<br /> * A list of services should be included in &quot;db/services.php&quot;. This file is required to register the web services with Moodle.<br /> * The services list is an array which contains:<br /> ** '''classname''' Name of the external class.<br /> ** '''methodname''' The name of the external function.<br /> ** '''classpath''' system path to the external function file.<br /> ** '''description''' Description of the function<br /> ** '''type''' Create, read, update, delete<br /> ** '''ajax''' Can this function be used with ajax?<br /> ** '''capabilities''' Capabilities required to use this function.<br /> <br /> links<br /> <br /> * [[External functions API]]<br /> * [[Adding a web service to a plugin]]<br /> * [[Web services API]]<br /> <br /> ===Using caching to improve performance===<br /> * The main cache used by moodle is the Moodle Universal Cache (MUC).<br /> * The MUC has several cache definitions - <br /> ** Request cache<br /> ** Session cache<br /> ** Application<br /> <br /> links<br /> <br /> * [[The Moodle Universal Cache (MUC)]]<br /> * [[:en:MUC FAQ]]<br /> * [[:en:Caching]]<br /> <br /> ===Supporting backup and restore===<br /> * Supporting backup and restore requires creating several files in the 'backup/moodle2' directory.<br /> * Back requires a class to extend the backup_task of some sort. There may be a specific plugin task to extend.<br /> * Restore requires a class to extend the restore_task of some sort. There may be a specific plugin task to extend.<br /> * The restore steps lib defines the structure of the plugin to be restored.<br /> * The backup steps lib defines steps, settings, attributes, etc.<br /> <br /> links<br /> <br /> * [[Backup 2.0 for developers]] - provides an example of step-by-step implementation of backup support to your plugin<br /> * [[:en:Backup and restore FAQ]]<br /> <br /> ===Supporting automated testing===<br /> * Moodle has two types of automated testing: php unit tests, and behat tests.<br /> * Unit tests are for testing functions.<br /> * Behat tests runs through scenarios.<br /> ** Behat tests follows a script and navigates through moodle pages.<br /> * unit tests should be located in the &quot;tests&quot; directory.<br /> * behat tests should be located in the &quot;tests/behat&quot; directory.<br /> * Tests located in these directories will be run through when a full test run is initiated.<br /> * behat tests are actually feature files and end with the extension &quot;.feature&quot;.<br /> <br /> links<br /> <br /> * [[Writing PHPUnit tests]]<br /> * [[PHPUnit]]<br /> * [[Acceptance testing]]<br /> * [[Behat integration]]<br /> <br /> ==Publishing your plugin==<br /> ===Adding your plugin to moodle.org===<br /> * publish your plugins at https://moodle.org/plugins/<br /> * Publishing plugins on the moodle site leads you through a bunch of steps that need to be completed in order for the plugin to be approved and published.<br /> * Plugins will be run through a pre-checker to give suggestions about possible issues with the code.<br /> <br /> ===Supporting your plugin===<br /> <br /> <br /> =TODO=<br /> <br /> Finishing this tutorial:<br /> # About one or two screens for each section with a very generic overview for beginners, containing links to relevant docs WITH COMMENTS ABOUT QUALITY, USEFULNESS, CAVEATS etc.<br /> # Go through all the linked pages and make sure they are current and accurate.<br /> # Add a worked example to this page, so that each section has suggestions about things to add to the admin tool being built as an exercise. If the code is long, it could be placed on separate pages. A good reference for style is [[Moodle_Mobile_Developing_a_plugin_tutorial]] and [[Blocks]].<br /> <br /> ==See also==<br /> * See [https://moodle.org/mod/forum/discuss.php?d=352360 this forum thread] about Getting Started with Moodle Development.<br /> <br /> =See also these older tutorials =<br /> * [[Blocks|A Step-by-step Guide To Creating Blocks]] <br /> * [[NEWMODULE Tutorial]]<br /> * [http://dev.moodle.org Introduction to Moodle programming (based on Moodle 1.8)]<br /> * [[Moodle_Mobile_Developing_a_plugin_tutorial|Moodle Mobile plugin tutorial]]<br /> * [[Category:Tutorial|Other tutorials in these docs]]<br /> <br /> [[Category:Tutorial]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Tutorial&diff=52841 2017-08-23T06:07:47Z

<p>Ankitfrenz: /* Browser end points */</p> <hr /> <div>Welcome to Moodle development!<br /> <br /> This is a tutorial to help you learn how to write plugins for Moodle from start to finish, while showing you how to navigate the most important developer documentation along the way.<br /> <br /> PRE-REQUISITES: We assume you are fairly comfortable with [[PHP FAQ|PHP]] in general and that you are able to [[:en:Installing AMP|install a database and web server]] on your local machine. <br /> <br /> If you need to learn PHP, you can see one PHP tutorial at http://www.w3schools.com/php/default.asp, another at http://php.net/manual/en/tutorial.php and several videos in YouTube at https://www.youtube.com/results?search_query=learn+php. There is a very old unmaintained Introduction to Moodle 1.8 Programming course at http://dev.moodle.org/course/view.php?id=2.<br /> <br /> Code examples can be found on GitHub at https://github.com/abgreeve/devcourse where a working plugin is located.<br /> <br /> ==Background==<br /> ===What's in the box===<br /> If you [http://download.moodle.org/ download] Moodle source code or clone it from [https://github.com/moodle/moodle git], you will see a bunch of files and folders. This code consists of [[Core_APIs|Moodle core]] (that consists of the Very core and Core components), [[Moodle_libraries_credits|third party libraries]] and [[Plugin_types|plugins]]. Their mixed locations can be quite confusing at first but as you start working with it it will become more clear. Moodle developers should avoid modifications of the third party libraries (unless required) and core can never call methods defined in plugins. See also [[Communication Between Components]]<br /> <br /> ===Setting up your development environment===<br /> * Moodle uses Git for developement. View the link below for basic information about Git and Moodle.<br /> <br /> links<br /> <br /> * [[Git for developers]]<br /> <br /> ===The Moodle development framework===<br /> ===What type of plugin are you developing?===<br /> * Moodle has lots of different types of plugins.<br /> * There are 24 different categories of plugin listed on the moodle plugin database. Before starting check here to see if someone else has not already created what you are looking for. Perhaps you could contribute to their plugin instead of creating a new one.<br /> <br /> links<br /> <br /> * https://moodle.org/plugins/<br /> * [[Plugin types]]<br /> <br /> ==Let's make a plugin==<br /> ===The skeleton of your plugin===<br /> <br /> You plugin code will be organised into multiple files within a single root directory (and the subdirectories).<br /> <br /> The page [[Plugin files]] provides a list of common plugins files and their purpose.<br /> <br /> See also:<br /> <br /> * [[Moodle architecture]] - general overview of Moodle code architecture<br /> * [[Plugin types]] - list of all supported plugin types<br /> * [https://moodle.org/plugins/ Moodle plugins directory] - repository of contributed plugins for Moodle<br /> * [https://moodle.org/plugins/tool_pluginskel Moodle plugin skeleton generator] - allows to quickly generate code skeleton for a new plugin<br /> <br /> ===Basic page structure===<br /> <br /> The link below explains how to create and display a simple page in Moodle.<br /> <br /> links<br /> <br /> * [[Page API]]<br /> <br /> ===How to support over 100 languages===<br /> * Language files are stored in the &quot;lang&quot; directory. English strings would be found in &quot;lang/en&quot;. Each language contains a file named after the plugin which contains all of the strings. For example the language strings for the assignment activity are found in &quot;mod/assign/lang/en/assign.php&quot;.<br /> * [[:en:Language FAQ#Which_is_the_official_language_for_Moodle.3F| Moodle's default is Australian English]]. <br /> ** American English is a separate language pack (en_us). Please use only Australian (UK) English grammar and spelling when writing Moodle plugins.<br /> ** There is no need to include languages other than the default English, as almost all approved [https://lang.moodle.org/mod/forum/discuss.php?d=2485 plugin strings will be automatically imported into AMOS] for translation by the language packs translators. <br /> * get_string() is used in most cases for displaying text.<br /> * lang_string() is used in situations where the text may not necessarily be displayed.<br /> <br /> &lt;code php&gt;<br /> // Declaration in language file (lang/en/{pluginname}.php)<br /> $string['nameofstring'] = 'Actual string';<br /> &lt;/code&gt;<br /> <br /> The get_string() function takes four parameters, but in this example we are only filling in the first two. The last two parameters are optional. The first parameter is the identifier for the string. The second is the component.<br /> The component will be the name of the language file.<br /> The following example shows a string in the badges block.<br /> &lt;code php&gt;<br /> // Use of string in code.<br /> echo html_writer::tag('p', get_string('numbadgestodisplay', 'block_badges'));<br /> &lt;/code&gt;<br /> <br /> <br /> links<br /> <br /> * [[String API]]<br /> * [[Places to search for lang strings]]<br /> * [[:en:Language customisation]]<br /> * [[Plugin contribution checklist#Strings]]<br /> <br /> ===Moodle file structure===<br /> ==== Automatic Class Loading ====<br /> Moodle supports automatic class loading. See the link below for the explanation of rules associated with it - <br /> <br /> links<br /> <br /> [[ Automatic class loading]]<br /> <br /> ==== Callbacks ====<br /> You can add a lot of features to your plugin by providing certain callbacks that Moodle expects to be present in your plugin's lib.php file. A detailed list can be found at - <br /> <br /> links<br /> <br /> [[ Callbacks ]]<br /> <br /> ==== Plugin types ====<br /> Moodle supports a wide range of plugin types. The complete list can be found at - <br /> <br /> links<br /> <br /> [[ Plugin types ]]<br /> <br /> ==== Core APIs ====<br /> The link below lists all major core apis in Moodle - <br /> <br /> links<br /> <br /> [[ Core APIs ]]<br /> <br /> ==== Browser accessible pages ====<br /> Any php file in your plugin will either be browser accessible or be an internal file. <br /> <br /> For browser accessible pages you must include config.php with code something similar to this - <br /> &lt;code php&gt;<br /> require_once('../../config.php');<br /> &lt;/code&gt;<br /> <br /> For internal files the code should use the following - <br /> &lt;code php&gt;<br /> defined('MOODLE_INTERNAL') || die();<br /> &lt;/code&gt;<br /> <br /> ===Add content to your page===<br /> * Content for a page is added through renderers.<br /> * Renderers are typically stored in the &quot;classes/output&quot; directory.<br /> * Putting content in renderers allows themers to override the visual display of the content.<br /> * Very basic information is presented using the html_writer class.<br /> * In most cases templates should be used.<br /> * templates are stored in the &quot;templates&quot; directory. The templates use mustache files.<br /> * Mustache files allow for more generic html with placeholders inserted, that inserts the data (context) at run time.<br /> <br /> The example used below is an admin tool and would be located under admin/tool.<br /> <br /> Step One: Create a class for rendering. This class collects information to display and has a method for formatting that information into a format that the template will understand.<br /> <br /> '''devcourse/classes/output/developer_course_main_page.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use renderable;<br /> use renderer_base;<br /> use templatable;<br /> use stdClass;<br /> <br /> <br /> class developer_course_main_page implements renderable, templatable {<br /> <br /> protected $comment;<br /> <br /> /**<br /> * Construct this renderable.<br /> * @param int $courseid The course record for this page.<br /> */<br /> public function __construct($comment) {<br /> $this-&gt;comment = $comment;<br /> }<br /> <br /> /**<br /> * Export this data so it can be used as the context for a mustache template.<br /> *<br /> * @param renderer_base $output Renderer base.<br /> * @return stdClass<br /> */<br /> public function export_for_template(renderer_base $output) {<br /> $data = new stdClass();<br /> $data-&gt;comment = $this-&gt;comment;<br /> return $data;<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step Two: To render this information a custom renderer is created for the plugin. This renderer class must extend plugin_renderer_base.<br /> <br /> '''devcourse/classes/output/renderer.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> <br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use plugin_renderer_base;<br /> use renderable;<br /> <br /> class renderer extends plugin_renderer_base {<br /> <br /> /**<br /> * Defer to template.<br /> *<br /> * @param developer_course_main_page $page<br /> *<br /> * @return string html for the page<br /> */<br /> public function render_developer_course_main_page(developer_course_main_page $page) {<br /> $data = $page-&gt;export_for_template($this);<br /> return parent::render_from_template('tool_devcourse/developer_course_main_page', $data);<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step three: A mustache template is to then be created. The information is sent to the template and at this point the information is known as the context (not to be confused with the normal definition of context throughout Moodle).<br /> <br /> '''devcourse/templates/developer_course_main_page.mustache'''<br /> &lt;code html&gt;<br /> {{!<br /> @template tool_devcourse/developer_course_main_page<br /> <br /> Example context (json):<br /> {<br /> &quot;comment&quot;: &quot;Example comment for the context&quot;<br /> }<br /> }}<br /> &lt;h2&gt;{{#str}}maintitle, tool_devdoc{{/str}}&lt;/h2&gt;<br /> &lt;div&gt;{{comment}}&lt;/div&gt;<br /> &lt;/code&gt;<br /> This shows an extremely simple mustache template with one item in the context (comment). It also shows how strings are defined in the template.<br /> <br /> Step four: To actually have this template be displayed we get the custom renderer. This chunk of code would be located in a place such as devcourse/index.php after the appropriate setup outlined in the [[Tutorial#Basic_page_structure|basic page structure]].<br /> &lt;code php&gt;<br /> $output = $PAGE-&gt;get_renderer('tool_devcourse');<br /> //Then we get the class for rendering and provide it with information (if needed).<br /> $randomcomment = 'This comment is random';<br /> $page = new \tool_devdoc\output\developer_course_main_page($randomcomment);<br /> //Finally we echo out the template<br /> echo $output-&gt;render($page);<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Output API]]<br /> * [[Output functions]]<br /> * [[Templates]]<br /> * [[Output renderers]]<br /> * [[Renderer]]<br /> * [[Overriding a renderer]]<br /> <br /> ===Adding your plugin into Moodle's navigation===<br /> * The moodle navigation system has hooks which allows plugins to add links to the navigation menu.<br /> * Hooks are located in lib.php. Try to keep lib.php as small as possible as this file is included on every page. Put classes and functions elsewhere.<br /> * Course navigation extension example:<br /> &lt;code php&gt;<br /> function tool_devcourse_extend_navigation_course($navigation, $course, $coursecontext) {<br /> $url = new moodle_url('/admin/tool/devcourse/index.php');<br /> $devcoursenode = navigation_node::create('Development course', $url, navigation_node::TYPE_CUSTOM, 'Dev course', 'devcourse');<br /> $navigation-&gt;add_node($devcoursenode);<br /> }<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Navigation API]]<br /> * [[:en:Navigation]]<br /> <br /> ===Database queries===<br /> * Moodle has a generic database query library. Behind this library are additional libraries which allow Moodle to work with MySQL, PostgreSQL, Oracle, SQL Server, and Maria DB.<br /> * Where possible it is advisable to use the predefined functions rather than write out SQL. Writing SQL has a greater chance of not working with one of the supported databases.<br /> * The return of the select functions tends to be an object or an array of objects.<br /> <br /> Example call to retrieve data from the course table.<br /> &lt;code php&gt;<br /> global $DB;<br /> $courses = $DB-&gt;get_records('course', null, '', 'id, category, fullname, shortname');<br /> &lt;/code&gt;<br /> Example of data returned from the above code.<br /> &lt;code&gt;<br /> Array<br /> (<br /> [43] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 43<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX -Test 5<br /> [shortname] =&gt; xxt5<br /> )<br /> <br /> [5] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 5<br /> [category] =&gt; 1<br /> [fullname] =&gt; With the glossary<br /> [shortname] =&gt; wtg<br /> )<br /> <br /> [39] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 39<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX - Test 1<br /> [shortname] =&gt; xxt1<br /> )<br /> )<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Database]]<br /> * [[Data manipulation API]]<br /> <br /> ===Creating your own database tables===<br /> * We create our database tables in Moodle using the XMLDB editor. This is located in the administration block &quot;Site administration | Development | XMLDB editor&quot;.<br /> * The {plugin}\db directory needs to have write access for the XMLDB editor to be most effective.<br /> * XMLDB editor creates an install.xml file in the db directory. This file will be loaded during the install to create your tables.<br /> * XMLDB editor will produce php update code for adding and updating moodle database tables.<br /> <br /> The XMLDB main page.<br /> <br /> [[{{ns:file}}:xmldb-main.png]]<br /> <br /> Upgrade code generated by the XMLDB<br /> <br /> [[{{ns:file}}:xmldb-upgrade-code.png]]<br /> <br /> links<br /> * [[XMLDB editor]]<br /> * [[Using XMLDB]]<br /> * [[XMLDB Documentation]]<br /> * [[Upgrade API]]<br /> * [[XMLDB introduction]]<br /> <br /> ===Supporting access permissions: roles, capabilities and contexts===<br /> * Capabilities are controlled in &quot;access.php&quot; under the &quot;db&quot; directory.<br /> * This file has an array of capabilities with the following:<br /> ** name<br /> ** possible security risks behind giving this capability.<br /> ** The context that this capability works in.<br /> ** The default roles (teacher, manager, student, etc) that have this capability.<br /> ** Various other information.<br /> * These capabilities are checked in code to allow access to pages, sections, and abilities (saving, deleting, etc).<br /> <br /> links<br /> * [[Access API]]<br /> * [[Roles#Context]]<br /> * [[:en:Category:Capabilities]]<br /> * [[:en:Roles and permissions]]<br /> <br /> ===Adding web forms===<br /> * Moodle has it's own forms library.<br /> * The forms lib includes a lot of accessibility code, and error checking, by default.<br /> * Moodle forms can be displayed in JavaScript using 'fragments'.<br /> <br /> links<br /> <br /> * [[Form API]]<br /> * [[lib/formslib.php Form Definition]]<br /> * [[Fragment]]<br /> <br /> ===Maintaining good security===<br /> * Use the sesskey when directing to pages to do actions.<br /> * Use the appropriate filters when retrieving parameters<br /> <br /> links<br /> <br /> * [[lib/formslib.php Form Definition#Most Commonly Used PARAM .2A Types]]<br /> * [[Output functions#p.28.29 and s.28.29]]<br /> <br /> ===Handling files===<br /> * Files are conceptually stored in file areas.<br /> * Plugins can only access files from it's own component.<br /> <br /> links<br /> <br /> * [[File API]]<br /> * [[File API internals]]<br /> * [[Using the File API in Moodle forms]]<br /> <br /> ===Adding Javascript===<br /> * Moodle is currently using jquery and AMD (Asynchronous Module Definition).<br /> * JavaScript files are located in the &quot;amd/src&quot; directory.<br /> * Use grunt to build your JavaScript.<br /> * Include your JavaScript in php files as follows:<br /> &lt;code php&gt;<br /> $this-&gt;page-&gt;requires-&gt;js_call_amd('{JScriptfilename}');<br /> &lt;/code&gt;<br /> * Can also be included in mustache templates.<br /> <br /> links<br /> <br /> * [[Javascript Modules]]<br /> * [[jQuery]]<br /> * [[Javascript FAQ]]<br /> * [[JavaScript guidelines]]<br /> * [[Grunt]]<br /> <br /> ===Adding events and logging===<br /> * All logging in moodle is done through the events system.<br /> * New events should be located in the &quot;classes/event&quot; directory.<br /> * It is possible to create observers and subscribe to events.<br /> <br /> links<br /> <br /> * [[Event 2]]<br /> * [[Logging 2]]<br /> <br /> ===Accessibility===<br /> <br /> Accessibility is an important consideration while developing a plugin to make sure your plugin is accessible to all users and doesn't discriminate against users with disablities. This often is a mandated requirement in many countries. The links below explain common practices that we follow at Moodle to make the interface more accessible.<br /> <br /> links<br /> * [[Accessibility]]<br /> * [[Usability]]<br /> ===Web Services and AJAX===<br /> * Moodle web services uses the external functions API.<br /> * The recommended way to make AJAX requests is to use the ajax AMD file which uses the external functions API.<br /> * External functions should be located in the &quot;classes/external.php&quot; file.<br /> * A list of services should be included in &quot;db/services.php&quot;. This file is required to register the web services with Moodle.<br /> * The services list is an array which contains:<br /> ** '''classname''' Name of the external class.<br /> ** '''methodname''' The name of the external function.<br /> ** '''classpath''' system path to the external function file.<br /> ** '''description''' Description of the function<br /> ** '''type''' Create, read, update, delete<br /> ** '''ajax''' Can this function be used with ajax?<br /> ** '''capabilities''' Capabilities required to use this function.<br /> <br /> links<br /> <br /> * [[External functions API]]<br /> * [[Adding a web service to a plugin]]<br /> * [[Web services API]]<br /> <br /> ===Using caching to improve performance===<br /> * The main cache used by moodle is the Moodle Universal Cache (MUC).<br /> * The MUC has several cache definitions - <br /> ** Request cache<br /> ** Session cache<br /> ** Application<br /> <br /> links<br /> <br /> * [[The Moodle Universal Cache (MUC)]]<br /> * [[:en:MUC FAQ]]<br /> * [[:en:Caching]]<br /> <br /> ===Supporting backup and restore===<br /> * Supporting backup and restore requires creating several files in the 'backup/moodle2' directory.<br /> * Back requires a class to extend the backup_task of some sort. There may be a specific plugin task to extend.<br /> * Restore requires a class to extend the restore_task of some sort. There may be a specific plugin task to extend.<br /> * The restore steps lib defines the structure of the plugin to be restored.<br /> * The backup steps lib defines steps, settings, attributes, etc.<br /> <br /> links<br /> <br /> * [[Backup 2.0 for developers]] - provides an example of step-by-step implementation of backup support to your plugin<br /> * [[:en:Backup and restore FAQ]]<br /> <br /> ===Supporting automated testing===<br /> * Moodle has two types of automated testing: php unit tests, and behat tests.<br /> * Unit tests are for testing functions.<br /> * Behat tests runs through scenarios.<br /> ** Behat tests follows a script and navigates through moodle pages.<br /> * unit tests should be located in the &quot;tests&quot; directory.<br /> * behat tests should be located in the &quot;tests/behat&quot; directory.<br /> * Tests located in these directories will be run through when a full test run is initiated.<br /> * behat tests are actually feature files and end with the extension &quot;.feature&quot;.<br /> <br /> links<br /> <br /> * [[Writing PHPUnit tests]]<br /> * [[PHPUnit]]<br /> * [[Acceptance testing]]<br /> * [[Behat integration]]<br /> <br /> ==Publishing your plugin==<br /> ===Adding your plugin to moodle.org===<br /> * publish your plugins at https://moodle.org/plugins/<br /> * Publishing plugins on the moodle site leads you through a bunch of steps that need to be completed in order for the plugin to be approved and published.<br /> * Plugins will be run through a pre-checker to give suggestions about possible issues with the code.<br /> <br /> ===Supporting your plugin===<br /> <br /> <br /> =TODO=<br /> <br /> Finishing this tutorial:<br /> # About one or two screens for each section with a very generic overview for beginners, containing links to relevant docs WITH COMMENTS ABOUT QUALITY, USEFULNESS, CAVEATS etc.<br /> # Go through all the linked pages and make sure they are current and accurate.<br /> # Add a worked example to this page, so that each section has suggestions about things to add to the admin tool being built as an exercise. If the code is long, it could be placed on separate pages. A good reference for style is [[Moodle_Mobile_Developing_a_plugin_tutorial]] and [[Blocks]].<br /> <br /> ==See also==<br /> * See [https://moodle.org/mod/forum/discuss.php?d=352360 this forum thread] about Getting Started with Moodle Development.<br /> <br /> =See also these older tutorials =<br /> * [[Blocks|A Step-by-step Guide To Creating Blocks]] <br /> * [[NEWMODULE Tutorial]]<br /> * [http://dev.moodle.org Introduction to Moodle programming (based on Moodle 1.8)]<br /> * [[Moodle_Mobile_Developing_a_plugin_tutorial|Moodle Mobile plugin tutorial]]<br /> * [[Category:Tutorial|Other tutorials in these docs]]<br /> <br /> [[Category:Tutorial]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Tutorial&diff=52840 2017-08-22T17:31:27Z

<p>Ankitfrenz: /* Moodle file structure */</p> <hr /> <div>Welcome to Moodle development!<br /> <br /> This is a tutorial to help you learn how to write plugins for Moodle from start to finish, while showing you how to navigate the most important developer documentation along the way.<br /> <br /> PRE-REQUISITES: We assume you are fairly comfortable with [[PHP FAQ|PHP]] in general and that you are able to [[:en:Installing AMP|install a database and web server]] on your local machine. <br /> <br /> If you need to learn PHP, you can see one PHP tutorial at http://www.w3schools.com/php/default.asp, another at http://php.net/manual/en/tutorial.php and several videos in YouTube at https://www.youtube.com/results?search_query=learn+php. There is a very old unmaintained Introduction to Moodle 1.8 Programming course at http://dev.moodle.org/course/view.php?id=2.<br /> <br /> Code examples can be found on GitHub at https://github.com/abgreeve/devcourse where a working plugin is located.<br /> <br /> ==Background==<br /> ===What's in the box===<br /> If you [http://download.moodle.org/ download] Moodle source code or clone it from [https://github.com/moodle/moodle git], you will see a bunch of files and folders. This code consists of [[Core_APIs|Moodle core]] (that consists of the Very core and Core components), [[Moodle_libraries_credits|third party libraries]] and [[Plugin_types|plugins]]. Their mixed locations can be quite confusing at first but as you start working with it it will become more clear. Moodle developers should avoid modifications of the third party libraries (unless required) and core can never call methods defined in plugins. See also [[Communication Between Components]]<br /> <br /> ===Setting up your development environment===<br /> * Moodle uses Git for developement. View the link below for basic information about Git and Moodle.<br /> <br /> links<br /> <br /> * [[Git for developers]]<br /> <br /> ===The Moodle development framework===<br /> ===What type of plugin are you developing?===<br /> * Moodle has lots of different types of plugins.<br /> * There are 24 different categories of plugin listed on the moodle plugin database. Before starting check here to see if someone else has not already created what you are looking for. Perhaps you could contribute to their plugin instead of creating a new one.<br /> <br /> links<br /> <br /> * https://moodle.org/plugins/<br /> * [[Plugin types]]<br /> <br /> ==Let's make a plugin==<br /> ===The skeleton of your plugin===<br /> <br /> You plugin code will be organised into multiple files within a single root directory (and the subdirectories).<br /> <br /> The page [[Plugin files]] provides a list of common plugins files and their purpose.<br /> <br /> See also:<br /> <br /> * [[Moodle architecture]] - general overview of Moodle code architecture<br /> * [[Plugin types]] - list of all supported plugin types<br /> * [https://moodle.org/plugins/ Moodle plugins directory] - repository of contributed plugins for Moodle<br /> * [https://moodle.org/plugins/tool_pluginskel Moodle plugin skeleton generator] - allows to quickly generate code skeleton for a new plugin<br /> <br /> ===Basic page structure===<br /> <br /> The link below explains how to create and display a simple page in Moodle.<br /> <br /> links<br /> <br /> * [[Page API]]<br /> <br /> ===How to support over 100 languages===<br /> * Language files are stored in the &quot;lang&quot; directory. English strings would be found in &quot;lang/en&quot;. Each language contains a file named after the plugin which contains all of the strings. For example the language strings for the assignment activity are found in &quot;mod/assign/lang/en/assign.php&quot;.<br /> * [[:en:Language FAQ#Which_is_the_official_language_for_Moodle.3F| Moodle's default is Australian English]]. <br /> ** American English is a separate language pack (en_us). Please use only Australian (UK) English grammar and spelling when writing Moodle plugins.<br /> ** There is no need to include languages other than the default English, as almost all approved [https://lang.moodle.org/mod/forum/discuss.php?d=2485 plugin strings will be automatically imported into AMOS] for translation by the language packs translators. <br /> * get_string() is used in most cases for displaying text.<br /> * lang_string() is used in situations where the text may not necessarily be displayed.<br /> <br /> &lt;code php&gt;<br /> // Declaration in language file (lang/en/{pluginname}.php)<br /> $string['nameofstring'] = 'Actual string';<br /> &lt;/code&gt;<br /> <br /> The get_string() function takes four parameters, but in this example we are only filling in the first two. The last two parameters are optional. The first parameter is the identifier for the string. The second is the component.<br /> The component will be the name of the language file.<br /> The following example shows a string in the badges block.<br /> &lt;code php&gt;<br /> // Use of string in code.<br /> echo html_writer::tag('p', get_string('numbadgestodisplay', 'block_badges'));<br /> &lt;/code&gt;<br /> <br /> <br /> links<br /> <br /> * [[String API]]<br /> * [[Places to search for lang strings]]<br /> * [[:en:Language customisation]]<br /> * [[Plugin contribution checklist#Strings]]<br /> <br /> ===Moodle file structure===<br /> ==== Automatic Class Loading ====<br /> Moodle supports automatic class loading. See the link below for the explanation of rules associated with it - <br /> <br /> links<br /> <br /> [[ Automatic class loading]]<br /> <br /> ==== Callbacks ====<br /> You can add a lot of features to your plugin by providing certain callbacks that Moodle expects to be present in your plugin's lib.php file. A detailed list can be found at - <br /> <br /> links<br /> <br /> [[ Callbacks ]]<br /> <br /> ==== Plugin types ====<br /> Moodle supports a wide range of plugin types. The complete list can be found at - <br /> <br /> links<br /> <br /> [[ Plugin types ]]<br /> <br /> ==== Core APIs ====<br /> The link below lists all major core apis in Moodle - <br /> <br /> links<br /> <br /> [[ Core APIs ]]<br /> <br /> ==== Browser end points ====<br /> Any php file in your plugin will either be an end point for browser entry or be an internal file. <br /> <br /> For end points you must include config.php with code something similar to this - <br /> &lt;code php&gt;<br /> require_once('../../config.php');<br /> &lt;/code&gt;<br /> <br /> For internal files the code should use the following - <br /> &lt;code php&gt;<br /> defined('MOODLE_INTERNAL') || die();<br /> &lt;/code&gt;<br /> <br /> ===Add content to your page===<br /> * Content for a page is added through renderers.<br /> * Renderers are typically stored in the &quot;classes/output&quot; directory.<br /> * Putting content in renderers allows themers to override the visual display of the content.<br /> * Very basic information is presented using the html_writer class.<br /> * In most cases templates should be used.<br /> * templates are stored in the &quot;templates&quot; directory. The templates use mustache files.<br /> * Mustache files allow for more generic html with placeholders inserted, that inserts the data (context) at run time.<br /> <br /> The example used below is an admin tool and would be located under admin/tool.<br /> <br /> Step One: Create a class for rendering. This class collects information to display and has a method for formatting that information into a format that the template will understand.<br /> <br /> '''devcourse/classes/output/developer_course_main_page.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use renderable;<br /> use renderer_base;<br /> use templatable;<br /> use stdClass;<br /> <br /> <br /> class developer_course_main_page implements renderable, templatable {<br /> <br /> protected $comment;<br /> <br /> /**<br /> * Construct this renderable.<br /> * @param int $courseid The course record for this page.<br /> */<br /> public function __construct($comment) {<br /> $this-&gt;comment = $comment;<br /> }<br /> <br /> /**<br /> * Export this data so it can be used as the context for a mustache template.<br /> *<br /> * @param renderer_base $output Renderer base.<br /> * @return stdClass<br /> */<br /> public function export_for_template(renderer_base $output) {<br /> $data = new stdClass();<br /> $data-&gt;comment = $this-&gt;comment;<br /> return $data;<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step Two: To render this information a custom renderer is created for the plugin. This renderer class must extend plugin_renderer_base.<br /> <br /> '''devcourse/classes/output/renderer.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> <br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use plugin_renderer_base;<br /> use renderable;<br /> <br /> class renderer extends plugin_renderer_base {<br /> <br /> /**<br /> * Defer to template.<br /> *<br /> * @param developer_course_main_page $page<br /> *<br /> * @return string html for the page<br /> */<br /> public function render_developer_course_main_page(developer_course_main_page $page) {<br /> $data = $page-&gt;export_for_template($this);<br /> return parent::render_from_template('tool_devcourse/developer_course_main_page', $data);<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step three: A mustache template is to then be created. The information is sent to the template and at this point the information is known as the context (not to be confused with the normal definition of context throughout Moodle).<br /> <br /> '''devcourse/templates/developer_course_main_page.mustache'''<br /> &lt;code html&gt;<br /> {{!<br /> @template tool_devcourse/developer_course_main_page<br /> <br /> Example context (json):<br /> {<br /> &quot;comment&quot;: &quot;Example comment for the context&quot;<br /> }<br /> }}<br /> &lt;h2&gt;{{#str}}maintitle, tool_devdoc{{/str}}&lt;/h2&gt;<br /> &lt;div&gt;{{comment}}&lt;/div&gt;<br /> &lt;/code&gt;<br /> This shows an extremely simple mustache template with one item in the context (comment). It also shows how strings are defined in the template.<br /> <br /> Step four: To actually have this template be displayed we get the custom renderer. This chunk of code would be located in a place such as devcourse/index.php after the appropriate setup outlined in the [[Tutorial#Basic_page_structure|basic page structure]].<br /> &lt;code php&gt;<br /> $output = $PAGE-&gt;get_renderer('tool_devcourse');<br /> //Then we get the class for rendering and provide it with information (if needed).<br /> $randomcomment = 'This comment is random';<br /> $page = new \tool_devdoc\output\developer_course_main_page($randomcomment);<br /> //Finally we echo out the template<br /> echo $output-&gt;render($page);<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Output API]]<br /> * [[Output functions]]<br /> * [[Templates]]<br /> * [[Output renderers]]<br /> * [[Renderer]]<br /> * [[Overriding a renderer]]<br /> <br /> ===Adding your plugin into Moodle's navigation===<br /> * The moodle navigation system has hooks which allows plugins to add links to the navigation menu.<br /> * Hooks are located in lib.php. Try to keep lib.php as small as possible as this file is included on every page. Put classes and functions elsewhere.<br /> * Course navigation extension example:<br /> &lt;code php&gt;<br /> function tool_devcourse_extend_navigation_course($navigation, $course, $coursecontext) {<br /> $url = new moodle_url('/admin/tool/devcourse/index.php');<br /> $devcoursenode = navigation_node::create('Development course', $url, navigation_node::TYPE_CUSTOM, 'Dev course', 'devcourse');<br /> $navigation-&gt;add_node($devcoursenode);<br /> }<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Navigation API]]<br /> * [[:en:Navigation]]<br /> <br /> ===Database queries===<br /> * Moodle has a generic database query library. Behind this library are additional libraries which allow Moodle to work with MySQL, PostgreSQL, Oracle, SQL Server, and Maria DB.<br /> * Where possible it is advisable to use the predefined functions rather than write out SQL. Writing SQL has a greater chance of not working with one of the supported databases.<br /> * The return of the select functions tends to be an object or an array of objects.<br /> <br /> Example call to retrieve data from the course table.<br /> &lt;code php&gt;<br /> global $DB;<br /> $courses = $DB-&gt;get_records('course', null, '', 'id, category, fullname, shortname');<br /> &lt;/code&gt;<br /> Example of data returned from the above code.<br /> &lt;code&gt;<br /> Array<br /> (<br /> [43] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 43<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX -Test 5<br /> [shortname] =&gt; xxt5<br /> )<br /> <br /> [5] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 5<br /> [category] =&gt; 1<br /> [fullname] =&gt; With the glossary<br /> [shortname] =&gt; wtg<br /> )<br /> <br /> [39] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 39<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX - Test 1<br /> [shortname] =&gt; xxt1<br /> )<br /> )<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Database]]<br /> * [[Data manipulation API]]<br /> <br /> ===Creating your own database tables===<br /> * We create our database tables in Moodle using the XMLDB editor. This is located in the administration block &quot;Site administration | Development | XMLDB editor&quot;.<br /> * The {plugin}\db directory needs to have write access for the XMLDB editor to be most effective.<br /> * XMLDB editor creates an install.xml file in the db directory. This file will be loaded during the install to create your tables.<br /> * XMLDB editor will produce php update code for adding and updating moodle database tables.<br /> <br /> The XMLDB main page.<br /> <br /> [[{{ns:file}}:xmldb-main.png]]<br /> <br /> Upgrade code generated by the XMLDB<br /> <br /> [[{{ns:file}}:xmldb-upgrade-code.png]]<br /> <br /> links<br /> * [[XMLDB editor]]<br /> * [[Using XMLDB]]<br /> * [[XMLDB Documentation]]<br /> * [[Upgrade API]]<br /> * [[XMLDB introduction]]<br /> <br /> ===Supporting access permissions: roles, capabilities and contexts===<br /> * Capabilities are controlled in &quot;access.php&quot; under the &quot;db&quot; directory.<br /> * This file has an array of capabilities with the following:<br /> ** name<br /> ** possible security risks behind giving this capability.<br /> ** The context that this capability works in.<br /> ** The default roles (teacher, manager, student, etc) that have this capability.<br /> ** Various other information.<br /> * These capabilities are checked in code to allow access to pages, sections, and abilities (saving, deleting, etc).<br /> <br /> links<br /> * [[Access API]]<br /> * [[Roles#Context]]<br /> * [[:en:Category:Capabilities]]<br /> * [[:en:Roles and permissions]]<br /> <br /> ===Adding web forms===<br /> * Moodle has it's own forms library.<br /> * The forms lib includes a lot of accessibility code, and error checking, by default.<br /> * Moodle forms can be displayed in JavaScript using 'fragments'.<br /> <br /> links<br /> <br /> * [[Form API]]<br /> * [[lib/formslib.php Form Definition]]<br /> * [[Fragment]]<br /> <br /> ===Maintaining good security===<br /> * Use the sesskey when directing to pages to do actions.<br /> * Use the appropriate filters when retrieving parameters<br /> <br /> links<br /> <br /> * [[lib/formslib.php Form Definition#Most Commonly Used PARAM .2A Types]]<br /> * [[Output functions#p.28.29 and s.28.29]]<br /> <br /> ===Handling files===<br /> * Files are conceptually stored in file areas.<br /> * Plugins can only access files from it's own component.<br /> <br /> links<br /> <br /> * [[File API]]<br /> * [[File API internals]]<br /> * [[Using the File API in Moodle forms]]<br /> <br /> ===Adding Javascript===<br /> * Moodle is currently using jquery and AMD (Asynchronous Module Definition).<br /> * JavaScript files are located in the &quot;amd/src&quot; directory.<br /> * Use grunt to build your JavaScript.<br /> * Include your JavaScript in php files as follows:<br /> &lt;code php&gt;<br /> $this-&gt;page-&gt;requires-&gt;js_call_amd('{JScriptfilename}');<br /> &lt;/code&gt;<br /> * Can also be included in mustache templates.<br /> <br /> links<br /> <br /> * [[Javascript Modules]]<br /> * [[jQuery]]<br /> * [[Javascript FAQ]]<br /> * [[JavaScript guidelines]]<br /> * [[Grunt]]<br /> <br /> ===Adding events and logging===<br /> * All logging in moodle is done through the events system.<br /> * New events should be located in the &quot;classes/event&quot; directory.<br /> * It is possible to create observers and subscribe to events.<br /> <br /> links<br /> <br /> * [[Event 2]]<br /> * [[Logging 2]]<br /> <br /> ===Accessibility===<br /> <br /> Accessibility is an important consideration while developing a plugin to make sure your plugin is accessible to all users and doesn't discriminate against users with disablities. This often is a mandated requirement in many countries. The links below explain common practices that we follow at Moodle to make the interface more accessible.<br /> <br /> links<br /> * [[Accessibility]]<br /> * [[Usability]]<br /> ===Web Services and AJAX===<br /> * Moodle web services uses the external functions API.<br /> * The recommended way to make AJAX requests is to use the ajax AMD file which uses the external functions API.<br /> * External functions should be located in the &quot;classes/external.php&quot; file.<br /> * A list of services should be included in &quot;db/services.php&quot;. This file is required to register the web services with Moodle.<br /> * The services list is an array which contains:<br /> ** '''classname''' Name of the external class.<br /> ** '''methodname''' The name of the external function.<br /> ** '''classpath''' system path to the external function file.<br /> ** '''description''' Description of the function<br /> ** '''type''' Create, read, update, delete<br /> ** '''ajax''' Can this function be used with ajax?<br /> ** '''capabilities''' Capabilities required to use this function.<br /> <br /> links<br /> <br /> * [[External functions API]]<br /> * [[Adding a web service to a plugin]]<br /> * [[Web services API]]<br /> <br /> ===Using caching to improve performance===<br /> * The main cache used by moodle is the Moodle Universal Cache (MUC).<br /> * The MUC has several cache definitions - <br /> ** Request cache<br /> ** Session cache<br /> ** Application<br /> <br /> links<br /> <br /> * [[The Moodle Universal Cache (MUC)]]<br /> * [[:en:MUC FAQ]]<br /> * [[:en:Caching]]<br /> <br /> ===Supporting backup and restore===<br /> * Supporting backup and restore requires creating several files in the 'backup/moodle2' directory.<br /> * Back requires a class to extend the backup_task of some sort. There may be a specific plugin task to extend.<br /> * Restore requires a class to extend the restore_task of some sort. There may be a specific plugin task to extend.<br /> * The restore steps lib defines the structure of the plugin to be restored.<br /> * The backup steps lib defines steps, settings, attributes, etc.<br /> <br /> links<br /> <br /> * [[Backup 2.0 for developers]] - provides an example of step-by-step implementation of backup support to your plugin<br /> * [[:en:Backup and restore FAQ]]<br /> <br /> ===Supporting automated testing===<br /> * Moodle has two types of automated testing: php unit tests, and behat tests.<br /> * Unit tests are for testing functions.<br /> * Behat tests runs through scenarios.<br /> ** Behat tests follows a script and navigates through moodle pages.<br /> * unit tests should be located in the &quot;tests&quot; directory.<br /> * behat tests should be located in the &quot;tests/behat&quot; directory.<br /> * Tests located in these directories will be run through when a full test run is initiated.<br /> * behat tests are actually feature files and end with the extension &quot;.feature&quot;.<br /> <br /> links<br /> <br /> * [[Writing PHPUnit tests]]<br /> * [[PHPUnit]]<br /> * [[Acceptance testing]]<br /> * [[Behat integration]]<br /> <br /> ==Publishing your plugin==<br /> ===Adding your plugin to moodle.org===<br /> * publish your plugins at https://moodle.org/plugins/<br /> * Publishing plugins on the moodle site leads you through a bunch of steps that need to be completed in order for the plugin to be approved and published.<br /> * Plugins will be run through a pre-checker to give suggestions about possible issues with the code.<br /> <br /> ===Supporting your plugin===<br /> <br /> <br /> =TODO=<br /> <br /> Finishing this tutorial:<br /> # About one or two screens for each section with a very generic overview for beginners, containing links to relevant docs WITH COMMENTS ABOUT QUALITY, USEFULNESS, CAVEATS etc.<br /> # Go through all the linked pages and make sure they are current and accurate.<br /> # Add a worked example to this page, so that each section has suggestions about things to add to the admin tool being built as an exercise. If the code is long, it could be placed on separate pages. A good reference for style is [[Moodle_Mobile_Developing_a_plugin_tutorial]] and [[Blocks]].<br /> <br /> ==See also==<br /> * See [https://moodle.org/mod/forum/discuss.php?d=352360 this forum thread] about Getting Started with Moodle Development.<br /> <br /> =See also these older tutorials =<br /> * [[Blocks|A Step-by-step Guide To Creating Blocks]] <br /> * [[NEWMODULE Tutorial]]<br /> * [http://dev.moodle.org Introduction to Moodle programming (based on Moodle 1.8)]<br /> * [[Moodle_Mobile_Developing_a_plugin_tutorial|Moodle Mobile plugin tutorial]]<br /> * [[Category:Tutorial|Other tutorials in these docs]]<br /> <br /> [[Category:Tutorial]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Tutorial&diff=52839 2017-08-22T05:46:32Z

<p>Ankitfrenz: </p> <hr /> <div>Welcome to Moodle development!<br /> <br /> This is a tutorial to help you learn how to write plugins for Moodle from start to finish, while showing you how to navigate the most important developer documentation along the way.<br /> <br /> PRE-REQUISITES: We assume you are fairly comfortable with [[PHP FAQ|PHP]] in general and that you are able to [[:en:Installing AMP|install a database and web server]] on your local machine. <br /> <br /> If you need to learn PHP, you can see one PHP tutorial at http://www.w3schools.com/php/default.asp, another at http://php.net/manual/en/tutorial.php and several videos in YouTube at https://www.youtube.com/results?search_query=learn+php. There is a very old unmaintained Introduction to Moodle 1.8 Programming course at http://dev.moodle.org/course/view.php?id=2.<br /> <br /> Code examples can be found on GitHub at https://github.com/abgreeve/devcourse where a working plugin is located.<br /> <br /> ==Background==<br /> ===What's in the box===<br /> If you [http://download.moodle.org/ download] Moodle source code or clone it from [https://github.com/moodle/moodle git], you will see a bunch of files and folders. This code consists of [[Core_APIs|Moodle core]] (that consists of the Very core and Core components), [[Moodle_libraries_credits|third party libraries]] and [[Plugin_types|plugins]]. Their mixed locations can be quite confusing at first but as you start working with it it will become more clear. Moodle developers should avoid modifications of the third party libraries (unless required) and core can never call methods defined in plugins. See also [[Communication Between Components]]<br /> <br /> ===Setting up your development environment===<br /> * Moodle uses Git for developement. View the link below for basic information about Git and Moodle.<br /> <br /> links<br /> <br /> * [[Git for developers]]<br /> <br /> ===The Moodle development framework===<br /> ===What type of plugin are you developing?===<br /> * Moodle has lots of different types of plugins.<br /> * There are 24 different categories of plugin listed on the moodle plugin database. Before starting check here to see if someone else has not already created what you are looking for. Perhaps you could contribute to their plugin instead of creating a new one.<br /> <br /> links<br /> <br /> * https://moodle.org/plugins/<br /> * [[Plugin types]]<br /> <br /> ==Let's make a plugin==<br /> ===The skeleton of your plugin===<br /> <br /> You plugin code will be organised into multiple files within a single root directory (and the subdirectories).<br /> <br /> The page [[Plugin files]] provides a list of common plugins files and their purpose.<br /> <br /> See also:<br /> <br /> * [[Moodle architecture]] - general overview of Moodle code architecture<br /> * [[Plugin types]] - list of all supported plugin types<br /> * [https://moodle.org/plugins/ Moodle plugins directory] - repository of contributed plugins for Moodle<br /> * [https://moodle.org/plugins/tool_pluginskel Moodle plugin skeleton generator] - allows to quickly generate code skeleton for a new plugin<br /> <br /> ===Basic page structure===<br /> <br /> The link below explains how to create and display a simple page in Moodle.<br /> <br /> links<br /> <br /> * [[Page API]]<br /> <br /> ===How to support over 100 languages===<br /> * Language files are stored in the &quot;lang&quot; directory. English strings would be found in &quot;lang/en&quot;. Each language contains a file named after the plugin which contains all of the strings. For example the language strings for the assignment activity are found in &quot;mod/assign/lang/en/assign.php&quot;.<br /> * [[:en:Language FAQ#Which_is_the_official_language_for_Moodle.3F| Moodle's default is Australian English]]. <br /> ** American English is a separate language pack (en_us). Please use only Australian (UK) English grammar and spelling when writing Moodle plugins.<br /> ** There is no need to include languages other than the default English, as almost all approved [https://lang.moodle.org/mod/forum/discuss.php?d=2485 plugin strings will be automatically imported into AMOS] for translation by the language packs translators. <br /> * get_string() is used in most cases for displaying text.<br /> * lang_string() is used in situations where the text may not necessarily be displayed.<br /> <br /> &lt;code php&gt;<br /> // Declaration in language file (lang/en/{pluginname}.php)<br /> $string['nameofstring'] = 'Actual string';<br /> &lt;/code&gt;<br /> <br /> The get_string() function takes four parameters, but in this example we are only filling in the first two. The last two parameters are optional. The first parameter is the identifier for the string. The second is the component.<br /> The component will be the name of the language file.<br /> The following example shows a string in the badges block.<br /> &lt;code php&gt;<br /> // Use of string in code.<br /> echo html_writer::tag('p', get_string('numbadgestodisplay', 'block_badges'));<br /> &lt;/code&gt;<br /> <br /> <br /> links<br /> <br /> * [[String API]]<br /> * [[Places to search for lang strings]]<br /> * [[:en:Language customisation]]<br /> * [[Plugin contribution checklist#Strings]]<br /> <br /> ===Moodle file structure===<br /> ==== Automatic Class Loading ====<br /> Moodle supports automatic class loading. See the link below for the explanation of rules associated with it - <br /> <br /> links<br /> <br /> [[ Automatic class loading]]<br /> <br /> ==== Callbacks ====<br /> You can add a lot of features to your plugin by providing certain callbacks that Moodle expects to be present in your plugin's lib.php file. A detailed list can be found at - <br /> <br /> links<br /> <br /> [[ Callbacks ]]<br /> <br /> ==== Plugin types ====<br /> Moodle supports a wide range of plugin types. The complete list can be found at - <br /> <br /> links<br /> <br /> [[ Plugin types ]]<br /> <br /> ==== Core APIS ====<br /> The link below lists all major core apis in Moodle - <br /> <br /> links<br /> <br /> [[ Core APIs ]]<br /> <br /> ===Add content to your page===<br /> * Content for a page is added through renderers.<br /> * Renderers are typically stored in the &quot;classes/output&quot; directory.<br /> * Putting content in renderers allows themers to override the visual display of the content.<br /> * Very basic information is presented using the html_writer class.<br /> * In most cases templates should be used.<br /> * templates are stored in the &quot;templates&quot; directory. The templates use mustache files.<br /> * Mustache files allow for more generic html with placeholders inserted, that inserts the data (context) at run time.<br /> <br /> The example used below is an admin tool and would be located under admin/tool.<br /> <br /> Step One: Create a class for rendering. This class collects information to display and has a method for formatting that information into a format that the template will understand.<br /> <br /> '''devcourse/classes/output/developer_course_main_page.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use renderable;<br /> use renderer_base;<br /> use templatable;<br /> use stdClass;<br /> <br /> <br /> class developer_course_main_page implements renderable, templatable {<br /> <br /> protected $comment;<br /> <br /> /**<br /> * Construct this renderable.<br /> * @param int $courseid The course record for this page.<br /> */<br /> public function __construct($comment) {<br /> $this-&gt;comment = $comment;<br /> }<br /> <br /> /**<br /> * Export this data so it can be used as the context for a mustache template.<br /> *<br /> * @param renderer_base $output Renderer base.<br /> * @return stdClass<br /> */<br /> public function export_for_template(renderer_base $output) {<br /> $data = new stdClass();<br /> $data-&gt;comment = $this-&gt;comment;<br /> return $data;<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step Two: To render this information a custom renderer is created for the plugin. This renderer class must extend plugin_renderer_base.<br /> <br /> '''devcourse/classes/output/renderer.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> <br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use plugin_renderer_base;<br /> use renderable;<br /> <br /> class renderer extends plugin_renderer_base {<br /> <br /> /**<br /> * Defer to template.<br /> *<br /> * @param developer_course_main_page $page<br /> *<br /> * @return string html for the page<br /> */<br /> public function render_developer_course_main_page(developer_course_main_page $page) {<br /> $data = $page-&gt;export_for_template($this);<br /> return parent::render_from_template('tool_devcourse/developer_course_main_page', $data);<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step three: A mustache template is to then be created. The information is sent to the template and at this point the information is known as the context (not to be confused with the normal definition of context throughout Moodle).<br /> <br /> '''devcourse/templates/developer_course_main_page.mustache'''<br /> &lt;code html&gt;<br /> {{!<br /> @template tool_devcourse/developer_course_main_page<br /> <br /> Example context (json):<br /> {<br /> &quot;comment&quot;: &quot;Example comment for the context&quot;<br /> }<br /> }}<br /> &lt;h2&gt;{{#str}}maintitle, tool_devdoc{{/str}}&lt;/h2&gt;<br /> &lt;div&gt;{{comment}}&lt;/div&gt;<br /> &lt;/code&gt;<br /> This shows an extremely simple mustache template with one item in the context (comment). It also shows how strings are defined in the template.<br /> <br /> Step four: To actually have this template be displayed we get the custom renderer. This chunk of code would be located in a place such as devcourse/index.php after the appropriate setup outlined in the [[Tutorial#Basic_page_structure|basic page structure]].<br /> &lt;code php&gt;<br /> $output = $PAGE-&gt;get_renderer('tool_devcourse');<br /> //Then we get the class for rendering and provide it with information (if needed).<br /> $randomcomment = 'This comment is random';<br /> $page = new \tool_devdoc\output\developer_course_main_page($randomcomment);<br /> //Finally we echo out the template<br /> echo $output-&gt;render($page);<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Output API]]<br /> * [[Output functions]]<br /> * [[Templates]]<br /> * [[Output renderers]]<br /> * [[Renderer]]<br /> * [[Overriding a renderer]]<br /> <br /> ===Adding your plugin into Moodle's navigation===<br /> * The moodle navigation system has hooks which allows plugins to add links to the navigation menu.<br /> * Hooks are located in lib.php. Try to keep lib.php as small as possible as this file is included on every page. Put classes and functions elsewhere.<br /> * Course navigation extension example:<br /> &lt;code php&gt;<br /> function tool_devcourse_extend_navigation_course($navigation, $course, $coursecontext) {<br /> $url = new moodle_url('/admin/tool/devcourse/index.php');<br /> $devcoursenode = navigation_node::create('Development course', $url, navigation_node::TYPE_CUSTOM, 'Dev course', 'devcourse');<br /> $navigation-&gt;add_node($devcoursenode);<br /> }<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Navigation API]]<br /> * [[:en:Navigation]]<br /> <br /> ===Database queries===<br /> * Moodle has a generic database query library. Behind this library are additional libraries which allow Moodle to work with MySQL, PostgreSQL, Oracle, SQL Server, and Maria DB.<br /> * Where possible it is advisable to use the predefined functions rather than write out SQL. Writing SQL has a greater chance of not working with one of the supported databases.<br /> * The return of the select functions tends to be an object or an array of objects.<br /> <br /> Example call to retrieve data from the course table.<br /> &lt;code php&gt;<br /> global $DB;<br /> $courses = $DB-&gt;get_records('course', null, '', 'id, category, fullname, shortname');<br /> &lt;/code&gt;<br /> Example of data returned from the above code.<br /> &lt;code&gt;<br /> Array<br /> (<br /> [43] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 43<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX -Test 5<br /> [shortname] =&gt; xxt5<br /> )<br /> <br /> [5] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 5<br /> [category] =&gt; 1<br /> [fullname] =&gt; With the glossary<br /> [shortname] =&gt; wtg<br /> )<br /> <br /> [39] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 39<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX - Test 1<br /> [shortname] =&gt; xxt1<br /> )<br /> )<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Database]]<br /> * [[Data manipulation API]]<br /> <br /> ===Creating your own database tables===<br /> * We create our database tables in Moodle using the XMLDB editor. This is located in the administration block &quot;Site administration | Development | XMLDB editor&quot;.<br /> * The {plugin}\db directory needs to have write access for the XMLDB editor to be most effective.<br /> * XMLDB editor creates an install.xml file in the db directory. This file will be loaded during the install to create your tables.<br /> * XMLDB editor will produce php update code for adding and updating moodle database tables.<br /> <br /> The XMLDB main page.<br /> <br /> [[{{ns:file}}:xmldb-main.png]]<br /> <br /> Upgrade code generated by the XMLDB<br /> <br /> [[{{ns:file}}:xmldb-upgrade-code.png]]<br /> <br /> links<br /> * [[XMLDB editor]]<br /> * [[Using XMLDB]]<br /> * [[XMLDB Documentation]]<br /> * [[Upgrade API]]<br /> * [[XMLDB introduction]]<br /> <br /> ===Supporting access permissions: roles, capabilities and contexts===<br /> * Capabilities are controlled in &quot;access.php&quot; under the &quot;db&quot; directory.<br /> * This file has an array of capabilities with the following:<br /> ** name<br /> ** possible security risks behind giving this capability.<br /> ** The context that this capability works in.<br /> ** The default roles (teacher, manager, student, etc) that have this capability.<br /> ** Various other information.<br /> * These capabilities are checked in code to allow access to pages, sections, and abilities (saving, deleting, etc).<br /> <br /> links<br /> * [[Access API]]<br /> * [[Roles#Context]]<br /> * [[:en:Category:Capabilities]]<br /> * [[:en:Roles and permissions]]<br /> <br /> ===Adding web forms===<br /> * Moodle has it's own forms library.<br /> * The forms lib includes a lot of accessibility code, and error checking, by default.<br /> * Moodle forms can be displayed in JavaScript using 'fragments'.<br /> <br /> links<br /> <br /> * [[Form API]]<br /> * [[lib/formslib.php Form Definition]]<br /> * [[Fragment]]<br /> <br /> ===Maintaining good security===<br /> * Use the sesskey when directing to pages to do actions.<br /> * Use the appropriate filters when retrieving parameters<br /> <br /> links<br /> <br /> * [[lib/formslib.php Form Definition#Most Commonly Used PARAM .2A Types]]<br /> * [[Output functions#p.28.29 and s.28.29]]<br /> <br /> ===Handling files===<br /> * Files are conceptually stored in file areas.<br /> * Plugins can only access files from it's own component.<br /> <br /> links<br /> <br /> * [[File API]]<br /> * [[File API internals]]<br /> * [[Using the File API in Moodle forms]]<br /> <br /> ===Adding Javascript===<br /> * Moodle is currently using jquery and AMD (Asynchronous Module Definition).<br /> * JavaScript files are located in the &quot;amd/src&quot; directory.<br /> * Use grunt to build your JavaScript.<br /> * Include your JavaScript in php files as follows:<br /> &lt;code php&gt;<br /> $this-&gt;page-&gt;requires-&gt;js_call_amd('{JScriptfilename}');<br /> &lt;/code&gt;<br /> * Can also be included in mustache templates.<br /> <br /> links<br /> <br /> * [[Javascript Modules]]<br /> * [[jQuery]]<br /> * [[Javascript FAQ]]<br /> * [[JavaScript guidelines]]<br /> * [[Grunt]]<br /> <br /> ===Adding events and logging===<br /> * All logging in moodle is done through the events system.<br /> * New events should be located in the &quot;classes/event&quot; directory.<br /> * It is possible to create observers and subscribe to events.<br /> <br /> links<br /> <br /> * [[Event 2]]<br /> * [[Logging 2]]<br /> <br /> ===Accessibility===<br /> <br /> Accessibility is an important consideration while developing a plugin to make sure your plugin is accessible to all users and doesn't discriminate against users with disablities. This often is a mandated requirement in many countries. The links below explain common practices that we follow at Moodle to make the interface more accessible.<br /> <br /> links<br /> * [[Accessibility]]<br /> * [[Usability]]<br /> ===Web Services and AJAX===<br /> * Moodle web services uses the external functions API.<br /> * The recommended way to make AJAX requests is to use the ajax AMD file which uses the external functions API.<br /> * External functions should be located in the &quot;classes/external.php&quot; file.<br /> * A list of services should be included in &quot;db/services.php&quot;. This file is required to register the web services with Moodle.<br /> * The services list is an array which contains:<br /> ** '''classname''' Name of the external class.<br /> ** '''methodname''' The name of the external function.<br /> ** '''classpath''' system path to the external function file.<br /> ** '''description''' Description of the function<br /> ** '''type''' Create, read, update, delete<br /> ** '''ajax''' Can this function be used with ajax?<br /> ** '''capabilities''' Capabilities required to use this function.<br /> <br /> links<br /> <br /> * [[External functions API]]<br /> * [[Adding a web service to a plugin]]<br /> * [[Web services API]]<br /> <br /> ===Using caching to improve performance===<br /> * The main cache used by moodle is the Moodle Universal Cache (MUC).<br /> * The MUC has several cache definitions - <br /> ** Request cache<br /> ** Session cache<br /> ** Application<br /> <br /> links<br /> <br /> * [[The Moodle Universal Cache (MUC)]]<br /> * [[:en:MUC FAQ]]<br /> * [[:en:Caching]]<br /> <br /> ===Supporting backup and restore===<br /> * Supporting backup and restore requires creating several files in the 'backup/moodle2' directory.<br /> * Back requires a class to extend the backup_task of some sort. There may be a specific plugin task to extend.<br /> * Restore requires a class to extend the restore_task of some sort. There may be a specific plugin task to extend.<br /> * The restore steps lib defines the structure of the plugin to be restored.<br /> * The backup steps lib defines steps, settings, attributes, etc.<br /> <br /> links<br /> <br /> * [[Backup 2.0 for developers]] - provides an example of step-by-step implementation of backup support to your plugin<br /> * [[:en:Backup and restore FAQ]]<br /> <br /> ===Supporting automated testing===<br /> * Moodle has two types of automated testing: php unit tests, and behat tests.<br /> * Unit tests are for testing functions.<br /> * Behat tests runs through scenarios.<br /> ** Behat tests follows a script and navigates through moodle pages.<br /> * unit tests should be located in the &quot;tests&quot; directory.<br /> * behat tests should be located in the &quot;tests/behat&quot; directory.<br /> * Tests located in these directories will be run through when a full test run is initiated.<br /> * behat tests are actually feature files and end with the extension &quot;.feature&quot;.<br /> <br /> links<br /> <br /> * [[Writing PHPUnit tests]]<br /> * [[PHPUnit]]<br /> * [[Acceptance testing]]<br /> * [[Behat integration]]<br /> <br /> ==Publishing your plugin==<br /> ===Adding your plugin to moodle.org===<br /> * publish your plugins at https://moodle.org/plugins/<br /> * Publishing plugins on the moodle site leads you through a bunch of steps that need to be completed in order for the plugin to be approved and published.<br /> * Plugins will be run through a pre-checker to give suggestions about possible issues with the code.<br /> <br /> ===Supporting your plugin===<br /> <br /> <br /> =TODO=<br /> <br /> Finishing this tutorial:<br /> # About one or two screens for each section with a very generic overview for beginners, containing links to relevant docs WITH COMMENTS ABOUT QUALITY, USEFULNESS, CAVEATS etc.<br /> # Go through all the linked pages and make sure they are current and accurate.<br /> # Add a worked example to this page, so that each section has suggestions about things to add to the admin tool being built as an exercise. If the code is long, it could be placed on separate pages. A good reference for style is [[Moodle_Mobile_Developing_a_plugin_tutorial]] and [[Blocks]].<br /> <br /> ==See also==<br /> * See [https://moodle.org/mod/forum/discuss.php?d=352360 this forum thread] about Getting Started with Moodle Development.<br /> <br /> =See also these older tutorials =<br /> * [[Blocks|A Step-by-step Guide To Creating Blocks]] <br /> * [[NEWMODULE Tutorial]]<br /> * [http://dev.moodle.org Introduction to Moodle programming (based on Moodle 1.8)]<br /> * [[Moodle_Mobile_Developing_a_plugin_tutorial|Moodle Mobile plugin tutorial]]<br /> * [[Category:Tutorial|Other tutorials in these docs]]<br /> <br /> [[Category:Tutorial]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Tutorial&diff=52838 2017-08-21T07:28:04Z

<p>Ankitfrenz: </p> <hr /> <div>Welcome to Moodle development!<br /> <br /> This is a tutorial to help you learn how to write plugins for Moodle from start to finish, while showing you how to navigate the most important developer documentation along the way.<br /> <br /> PRE-REQUISITES: We assume you are fairly comfortable with [[PHP FAQ|PHP]] in general and that you are able to [[:en:Installing AMP|install a database and web server]] on your local machine. <br /> <br /> If you need to learn PHP, you can see one PHP tutorial at http://www.w3schools.com/php/default.asp, another at http://php.net/manual/en/tutorial.php and several videos in YouTube at https://www.youtube.com/results?search_query=learn+php. There is a very old unmaintained Introduction to Moodle 1.8 Programming course at http://dev.moodle.org/course/view.php?id=2.<br /> <br /> Code examples can be found on GitHub at https://github.com/abgreeve/devcourse where a working plugin is located.<br /> <br /> ==Background==<br /> ===What's in the box===<br /> If you [http://download.moodle.org/ download] Moodle source code or clone it from [https://github.com/moodle/moodle git], you will see a bunch of files and folders. This code consists of [[Core_APIs|Moodle core]] (that consists of the Very core and Core components), [[Moodle_libraries_credits|third party libraries]] and [[Plugin_types|plugins]]. Their mixed locations can be quite confusing at first but as you start working with it it will become more clear. Moodle developers should avoid modifications of the third party libraries (unless required) and core can never call methods defined in plugins. See also [[Communication Between Components]]<br /> <br /> ===Setting up your development environment===<br /> * Moodle uses Git for developement. View the link below for basic information about Git and Moodle.<br /> <br /> links<br /> <br /> * [[Git for developers]]<br /> <br /> ===The Moodle development framework===<br /> ===What type of plugin are you developing?===<br /> * Moodle has lots of different types of plugins.<br /> * There are 24 different categories of plugin listed on the moodle plugin database. Before starting check here to see if someone else has not already created what you are looking for. Perhaps you could contribute to their plugin instead of creating a new one.<br /> <br /> links<br /> <br /> * https://moodle.org/plugins/<br /> * [[Plugin types]]<br /> <br /> ==Let's make a plugin==<br /> ===The skeleton of your plugin===<br /> <br /> You plugin code will be organised into multiple files within a single root directory (and the subdirectories).<br /> <br /> The page [[Plugin files]] provides a list of common plugins files and their purpose.<br /> <br /> See also:<br /> <br /> * [[Moodle architecture]] - general overview of Moodle code architecture<br /> * [[Plugin types]] - list of all supported plugin types<br /> * [https://moodle.org/plugins/ Moodle plugins directory] - repository of contributed plugins for Moodle<br /> * [https://moodle.org/plugins/tool_pluginskel Moodle plugin skeleton generator] - allows to quickly generate code skeleton for a new plugin<br /> <br /> ===Basic page structure===<br /> <br /> The link below explains how to create and display a simple page in Moodle.<br /> <br /> links<br /> <br /> * [[Page API]]<br /> <br /> ===How to support over 100 languages===<br /> * Language files are stored in the &quot;lang&quot; directory. English strings would be found in &quot;lang/en&quot;. Each language contains a file named after the plugin which contains all of the strings. For example the language strings for the assignment activity are found in &quot;mod/assign/lang/en/assign.php&quot;.<br /> * [[:en:Language FAQ#Which_is_the_official_language_for_Moodle.3F| Moodle's default is Australian English]]. <br /> ** American English is a separate language pack (en_us). Please use only Australian (UK) English grammar and spelling when writing Moodle plugins.<br /> ** There is no need to include languages other than the default English, as almost all approved [https://lang.moodle.org/mod/forum/discuss.php?d=2485 plugin strings will be automatically imported into AMOS] for translation by the language packs translators. <br /> * get_string() is used in most cases for displaying text.<br /> * lang_string() is used in situations where the text may not necessarily be displayed.<br /> <br /> &lt;code php&gt;<br /> // Declaration in language file (lang/en/{pluginname}.php)<br /> $string['nameofstring'] = 'Actual string';<br /> &lt;/code&gt;<br /> <br /> The get_string() function takes four parameters, but in this example we are only filling in the first two. The last two parameters are optional. The first parameter is the identifier for the string. The second is the component.<br /> The component will be the name of the language file.<br /> The following example shows a string in the badges block.<br /> &lt;code php&gt;<br /> // Use of string in code.<br /> echo html_writer::tag('p', get_string('numbadgestodisplay', 'block_badges'));<br /> &lt;/code&gt;<br /> <br /> <br /> links<br /> <br /> * [[String API]]<br /> * [[Places to search for lang strings]]<br /> * [[:en:Language customisation]]<br /> * [[Plugin contribution checklist#Strings]]<br /> <br /> ===Add content to your page===<br /> * Content for a page is added through renderers.<br /> * Renderers are typically stored in the &quot;classes/output&quot; directory.<br /> * Putting content in renderers allows themers to override the visual display of the content.<br /> * Very basic information is presented using the html_writer class.<br /> * In most cases templates should be used.<br /> * templates are stored in the &quot;templates&quot; directory. The templates use mustache files.<br /> * Mustache files allow for more generic html with placeholders inserted, that inserts the data (context) at run time.<br /> <br /> The example used below is an admin tool and would be located under admin/tool.<br /> <br /> Step One: Create a class for rendering. This class collects information to display and has a method for formatting that information into a format that the template will understand.<br /> <br /> '''devcourse/classes/output/developer_course_main_page.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use renderable;<br /> use renderer_base;<br /> use templatable;<br /> use stdClass;<br /> <br /> <br /> class developer_course_main_page implements renderable, templatable {<br /> <br /> protected $comment;<br /> <br /> /**<br /> * Construct this renderable.<br /> * @param int $courseid The course record for this page.<br /> */<br /> public function __construct($comment) {<br /> $this-&gt;comment = $comment;<br /> }<br /> <br /> /**<br /> * Export this data so it can be used as the context for a mustache template.<br /> *<br /> * @param renderer_base $output Renderer base.<br /> * @return stdClass<br /> */<br /> public function export_for_template(renderer_base $output) {<br /> $data = new stdClass();<br /> $data-&gt;comment = $this-&gt;comment;<br /> return $data;<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step Two: To render this information a custom renderer is created for the plugin. This renderer class must extend plugin_renderer_base.<br /> <br /> '''devcourse/classes/output/renderer.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> <br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use plugin_renderer_base;<br /> use renderable;<br /> <br /> class renderer extends plugin_renderer_base {<br /> <br /> /**<br /> * Defer to template.<br /> *<br /> * @param developer_course_main_page $page<br /> *<br /> * @return string html for the page<br /> */<br /> public function render_developer_course_main_page(developer_course_main_page $page) {<br /> $data = $page-&gt;export_for_template($this);<br /> return parent::render_from_template('tool_devcourse/developer_course_main_page', $data);<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step three: A mustache template is to then be created. The information is sent to the template and at this point the information is known as the context (not to be confused with the normal definition of context throughout Moodle).<br /> <br /> '''devcourse/templates/developer_course_main_page.mustache'''<br /> &lt;code html&gt;<br /> {{!<br /> @template tool_devcourse/developer_course_main_page<br /> <br /> Example context (json):<br /> {<br /> &quot;comment&quot;: &quot;Example comment for the context&quot;<br /> }<br /> }}<br /> &lt;h2&gt;{{#str}}maintitle, tool_devdoc{{/str}}&lt;/h2&gt;<br /> &lt;div&gt;{{comment}}&lt;/div&gt;<br /> &lt;/code&gt;<br /> This shows an extremely simple mustache template with one item in the context (comment). It also shows how strings are defined in the template.<br /> <br /> Step four: To actually have this template be displayed we get the custom renderer. This chunk of code would be located in a place such as devcourse/index.php after the appropriate setup outlined in the [[Tutorial#Basic_page_structure|basic page structure]].<br /> &lt;code php&gt;<br /> $output = $PAGE-&gt;get_renderer('tool_devcourse');<br /> //Then we get the class for rendering and provide it with information (if needed).<br /> $randomcomment = 'This comment is random';<br /> $page = new \tool_devdoc\output\developer_course_main_page($randomcomment);<br /> //Finally we echo out the template<br /> echo $output-&gt;render($page);<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Output API]]<br /> * [[Output functions]]<br /> * [[Templates]]<br /> * [[Output renderers]]<br /> * [[Renderer]]<br /> * [[Overriding a renderer]]<br /> <br /> ===Adding your plugin into Moodle's navigation===<br /> * The moodle navigation system has hooks which allows plugins to add links to the navigation menu.<br /> * Hooks are located in lib.php. Try to keep lib.php as small as possible as this file is included on every page. Put classes and functions elsewhere.<br /> * Course navigation extension example:<br /> &lt;code php&gt;<br /> function tool_devcourse_extend_navigation_course($navigation, $course, $coursecontext) {<br /> $url = new moodle_url('/admin/tool/devcourse/index.php');<br /> $devcoursenode = navigation_node::create('Development course', $url, navigation_node::TYPE_CUSTOM, 'Dev course', 'devcourse');<br /> $navigation-&gt;add_node($devcoursenode);<br /> }<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Navigation API]]<br /> * [[:en:Navigation]]<br /> <br /> ===Database queries===<br /> * Moodle has a generic database query library. Behind this library are additional libraries which allow Moodle to work with MySQL, PostgreSQL, Oracle, SQL Server, and Maria DB.<br /> * Where possible it is advisable to use the predefined functions rather than write out SQL. Writing SQL has a greater chance of not working with one of the supported databases.<br /> * The return of the select functions tends to be an object or an array of objects.<br /> <br /> Example call to retrieve data from the course table.<br /> &lt;code php&gt;<br /> global $DB;<br /> $courses = $DB-&gt;get_records('course', null, '', 'id, category, fullname, shortname');<br /> &lt;/code&gt;<br /> Example of data returned from the above code.<br /> &lt;code&gt;<br /> Array<br /> (<br /> [43] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 43<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX -Test 5<br /> [shortname] =&gt; xxt5<br /> )<br /> <br /> [5] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 5<br /> [category] =&gt; 1<br /> [fullname] =&gt; With the glossary<br /> [shortname] =&gt; wtg<br /> )<br /> <br /> [39] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 39<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX - Test 1<br /> [shortname] =&gt; xxt1<br /> )<br /> )<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Database]]<br /> * [[Data manipulation API]]<br /> <br /> ===Creating your own database tables===<br /> * We create our database tables in Moodle using the XMLDB editor. This is located in the administration block &quot;Site administration | Development | XMLDB editor&quot;.<br /> * The {plugin}\db directory needs to have write access for the XMLDB editor to be most effective.<br /> * XMLDB editor creates an install.xml file in the db directory. This file will be loaded during the install to create your tables.<br /> * XMLDB editor will produce php update code for adding and updating moodle database tables.<br /> <br /> The XMLDB main page.<br /> <br /> [[{{ns:file}}:xmldb-main.png]]<br /> <br /> Upgrade code generated by the XMLDB<br /> <br /> [[{{ns:file}}:xmldb-upgrade-code.png]]<br /> <br /> links<br /> * [[XMLDB editor]]<br /> * [[Using XMLDB]]<br /> * [[XMLDB Documentation]]<br /> * [[Upgrade API]]<br /> * [[XMLDB introduction]]<br /> <br /> ===Supporting access permissions: roles, capabilities and contexts===<br /> * Capabilities are controlled in &quot;access.php&quot; under the &quot;db&quot; directory.<br /> * This file has an array of capabilities with the following:<br /> ** name<br /> ** possible security risks behind giving this capability.<br /> ** The context that this capability works in.<br /> ** The default roles (teacher, manager, student, etc) that have this capability.<br /> ** Various other information.<br /> * These capabilities are checked in code to allow access to pages, sections, and abilities (saving, deleting, etc).<br /> <br /> links<br /> * [[Access API]]<br /> * [[Roles#Context]]<br /> * [[:en:Category:Capabilities]]<br /> * [[:en:Roles and permissions]]<br /> <br /> ===Adding web forms===<br /> * Moodle has it's own forms library.<br /> * The forms lib includes a lot of accessibility code, and error checking, by default.<br /> * Moodle forms can be displayed in JavaScript using 'fragments'.<br /> <br /> links<br /> <br /> * [[Form API]]<br /> * [[lib/formslib.php Form Definition]]<br /> * [[Fragment]]<br /> <br /> ===Maintaining good security===<br /> * Use the sesskey when directing to pages to do actions.<br /> * Use the appropriate filters when retrieving parameters<br /> <br /> links<br /> <br /> * [[lib/formslib.php Form Definition#Most Commonly Used PARAM .2A Types]]<br /> * [[Output functions#p.28.29 and s.28.29]]<br /> <br /> ===Handling files===<br /> * Files are conceptually stored in file areas.<br /> * Plugins can only access files from it's own component.<br /> <br /> links<br /> <br /> * [[File API]]<br /> * [[File API internals]]<br /> * [[Using the File API in Moodle forms]]<br /> <br /> ===Adding Javascript===<br /> * Moodle is currently using jquery and AMD (Asynchronous Module Definition).<br /> * JavaScript files are located in the &quot;amd/src&quot; directory.<br /> * Use grunt to build your JavaScript.<br /> * Include your JavaScript in php files as follows:<br /> &lt;code php&gt;<br /> $this-&gt;page-&gt;requires-&gt;js_call_amd('{JScriptfilename}');<br /> &lt;/code&gt;<br /> * Can also be included in mustache templates.<br /> <br /> links<br /> <br /> * [[Javascript Modules]]<br /> * [[jQuery]]<br /> * [[Javascript FAQ]]<br /> * [[JavaScript guidelines]]<br /> * [[Grunt]]<br /> <br /> ===Adding events and logging===<br /> * All logging in moodle is done through the events system.<br /> * New events should be located in the &quot;classes/event&quot; directory.<br /> * It is possible to create observers and subscribe to events.<br /> <br /> links<br /> <br /> * [[Event 2]]<br /> * [[Logging 2]]<br /> <br /> ===Accessibility===<br /> <br /> Accessibility is an important consideration while developing a plugin to make sure your plugin is accessible to all users and doesn't discriminate against users with disablities. This often is a mandated requirement in many countries. The links below explain common practices that we follow at Moodle to make the interface more accessible.<br /> <br /> links<br /> * [[Accessibility]]<br /> * [[Usability]]<br /> ===Web Services and AJAX===<br /> * Moodle web services uses the external functions API.<br /> * The recommended way to make AJAX requests is to use the ajax AMD file which uses the external functions API.<br /> * External functions should be located in the &quot;classes/external.php&quot; file.<br /> * A list of services should be included in &quot;db/services.php&quot;. This file is required to register the web services with Moodle.<br /> * The services list is an array which contains:<br /> ** '''classname''' Name of the external class.<br /> ** '''methodname''' The name of the external function.<br /> ** '''classpath''' system path to the external function file.<br /> ** '''description''' Description of the function<br /> ** '''type''' Create, read, update, delete<br /> ** '''ajax''' Can this function be used with ajax?<br /> ** '''capabilities''' Capabilities required to use this function.<br /> <br /> links<br /> <br /> * [[External functions API]]<br /> * [[Adding a web service to a plugin]]<br /> * [[Web services API]]<br /> <br /> ===Using caching to improve performance===<br /> * The main cache used by moodle is the Moodle Universal Cache (MUC).<br /> * The MUC has several cache definitions - <br /> ** Request cache<br /> ** Session cache<br /> ** Application<br /> <br /> links<br /> <br /> * [[The Moodle Universal Cache (MUC)]]<br /> * [[:en:MUC FAQ]]<br /> * [[:en:Caching]]<br /> <br /> ===Supporting backup and restore===<br /> * Supporting backup and restore requires creating several files in the 'backup/moodle2' directory.<br /> * Back requires a class to extend the backup_task of some sort. There may be a specific plugin task to extend.<br /> * Restore requires a class to extend the restore_task of some sort. There may be a specific plugin task to extend.<br /> * The restore steps lib defines the structure of the plugin to be restored.<br /> * The backup steps lib defines steps, settings, attributes, etc.<br /> <br /> links<br /> <br /> * [[Backup 2.0 for developers]] - provides an example of step-by-step implementation of backup support to your plugin<br /> * [[:en:Backup and restore FAQ]]<br /> <br /> ===Supporting automated testing===<br /> * Moodle has two types of automated testing: php unit tests, and behat tests.<br /> * Unit tests are for testing functions.<br /> * Behat tests runs through scenarios.<br /> ** Behat tests follows a script and navigates through moodle pages.<br /> * unit tests should be located in the &quot;tests&quot; directory.<br /> * behat tests should be located in the &quot;tests/behat&quot; directory.<br /> * Tests located in these directories will be run through when a full test run is initiated.<br /> * behat tests are actually feature files and end with the extension &quot;.feature&quot;.<br /> <br /> links<br /> <br /> * [[Writing PHPUnit tests]]<br /> * [[PHPUnit]]<br /> * [[Acceptance testing]]<br /> * [[Behat integration]]<br /> <br /> ==Publishing your plugin==<br /> ===Adding your plugin to moodle.org===<br /> * publish your plugins at https://moodle.org/plugins/<br /> * Publishing plugins on the moodle site leads you through a bunch of steps that need to be completed in order for the plugin to be approved and published.<br /> * Plugins will be run through a pre-checker to give suggestions about possible issues with the code.<br /> <br /> ===Supporting your plugin===<br /> <br /> <br /> =TODO=<br /> <br /> Finishing this tutorial:<br /> # About one or two screens for each section with a very generic overview for beginners, containing links to relevant docs WITH COMMENTS ABOUT QUALITY, USEFULNESS, CAVEATS etc.<br /> # Go through all the linked pages and make sure they are current and accurate.<br /> # Add a worked example to this page, so that each section has suggestions about things to add to the admin tool being built as an exercise. If the code is long, it could be placed on separate pages. A good reference for style is [[Moodle_Mobile_Developing_a_plugin_tutorial]] and [[Blocks]].<br /> <br /> ==See also==<br /> * See [https://moodle.org/mod/forum/discuss.php?d=352360 this forum thread] about Getting Started with Moodle Development.<br /> <br /> =See also these older tutorials =<br /> * [[Blocks|A Step-by-step Guide To Creating Blocks]] <br /> * [[NEWMODULE Tutorial]]<br /> * [http://dev.moodle.org Introduction to Moodle programming (based on Moodle 1.8)]<br /> * [[Moodle_Mobile_Developing_a_plugin_tutorial|Moodle Mobile plugin tutorial]]<br /> * [[Category:Tutorial|Other tutorials in these docs]]<br /> <br /> [[Category:Tutorial]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Tutorial&diff=52837 2017-08-21T06:05:41Z

<p>Ankitfrenz: /* Basic page structure */</p> <hr /> <div>Welcome to Moodle development!<br /> <br /> This is a tutorial to help you learn how to write plugins for Moodle from start to finish, while showing you how to navigate the most important developer documentation along the way.<br /> <br /> PRE-REQUISITES: We assume you are fairly comfortable with [[PHP FAQ|PHP]] in general and that you are able to [[:en:Installing AMP|install a database and web server]] on your local machine. <br /> <br /> If you need to learn PHP, you can see one PHP tutorial at http://www.w3schools.com/php/default.asp, another at http://php.net/manual/en/tutorial.php and several videos in YouTube at https://www.youtube.com/results?search_query=learn+php. There is a very old unmaintained Introduction to Moodle 1.8 Programming course at http://dev.moodle.org/course/view.php?id=2.<br /> <br /> Code examples can be found on GitHub at https://github.com/abgreeve/devcourse where a working plugin is located.<br /> <br /> ==Background==<br /> ===What's in the box===<br /> If you [http://download.moodle.org/ download] Moodle source code or clone it from [https://github.com/moodle/moodle git], you will see a bunch of files and folders. This code consists of [[Core_APIs|Moodle core]] (that consists of the Very core and Core components), [[Moodle_libraries_credits|third party libraries]] and [[Plugin_types|plugins]]. Their mixed locations can be quite confusing at first but as you start working with it it will become more clear. Moodle developers should avoid modifications of the third party libraries (unless required) and core can never call methods defined in plugins. See also [[Communication Between Components]]<br /> <br /> ===Setting up your development environment===<br /> * Moodle uses Git for developement. View the link below for basic information about Git and Moodle.<br /> <br /> links<br /> <br /> * [[Git for developers]]<br /> <br /> ===The Moodle development framework===<br /> ===What type of plugin are you developing?===<br /> * Moodle has lots of different types of plugins.<br /> * There are 24 different categories of plugin listed on the moodle plugin database. Before starting check here to see if someone else has not already created what you are looking for. Perhaps you could contribute to their plugin instead of creating a new one.<br /> <br /> links<br /> <br /> * https://moodle.org/plugins/<br /> * [[Plugin types]]<br /> <br /> ==Let's make a plugin==<br /> ===The skeleton of your plugin===<br /> <br /> You plugin code will be organised into multiple files within a single root directory (and the subdirectories).<br /> <br /> The page [[Plugin files]] provides a list of common plugins files and their purpose.<br /> <br /> See also:<br /> <br /> * [[Moodle architecture]] - general overview of Moodle code architecture<br /> * [[Plugin types]] - list of all supported plugin types<br /> * [https://moodle.org/plugins/ Moodle plugins directory] - repository of contributed plugins for Moodle<br /> * [https://moodle.org/plugins/tool_pluginskel Moodle plugin skeleton generator] - allows to quickly generate code skeleton for a new plugin<br /> <br /> ===Basic page structure===<br /> <br /> The link below explains how to create and display a simple page in Moodle.<br /> <br /> links<br /> <br /> * [[Page API]]<br /> <br /> ===How to support over 100 languages===<br /> * Language files are stored in the &quot;lang&quot; directory. English strings would be found in &quot;lang/en&quot;. Each language contains a file named after the plugin which contains all of the strings. For example the language strings for the assignment activity are found in &quot;mod/assign/lang/en/assign.php&quot;.<br /> * [[:en:Language FAQ#Which_is_the_official_language_for_Moodle.3F| Moodle's default is Australian English]]. <br /> ** American English is a separate language pack (en_us). Please use only Australian (UK) English grammar and spelling when writing Moodle plugins.<br /> ** There is no need to include languages other than the default English, as almost all approved [https://lang.moodle.org/mod/forum/discuss.php?d=2485 plugin strings will be automatically imported into AMOS] for translation by the language packs translators. <br /> * get_string() is used in most cases for displaying text.<br /> * lang_string() is used in situations where the text may not necessarily be displayed.<br /> <br /> &lt;code php&gt;<br /> // Declaration in language file (lang/en/{pluginname}.php)<br /> $string['nameofstring'] = 'Actual string';<br /> &lt;/code&gt;<br /> <br /> The get_string() function takes four parameters, but in this example we are only filling in the first two. The last two parameters are optional. The first parameter is the identifier for the string. The second is the component.<br /> The component will be the name of the language file.<br /> The following example shows a string in the badges block.<br /> &lt;code php&gt;<br /> // Use of string in code.<br /> echo html_writer::tag('p', get_string('numbadgestodisplay', 'block_badges'));<br /> &lt;/code&gt;<br /> <br /> <br /> links<br /> <br /> * [[String API]]<br /> * [[Places to search for lang strings]]<br /> * [[:en:Language customisation]]<br /> * [[Plugin contribution checklist#Strings]]<br /> <br /> ===Add content to your page===<br /> * Content for a page is added through renderers.<br /> * Renderers are typically stored in the &quot;classes/output&quot; directory.<br /> * Putting content in renderers allows themers to override the visual display of the content.<br /> * Very basic information is presented using the html_writer class.<br /> * In most cases templates should be used.<br /> * templates are stored in the &quot;templates&quot; directory. The templates use mustache files.<br /> * Mustache files allow for more generic html with placeholders inserted, that inserts the data (context) at run time.<br /> <br /> The example used below is an admin tool and would be located under admin/tool.<br /> <br /> Step One: Create a class for rendering. This class collects information to display and has a method for formatting that information into a format that the template will understand.<br /> <br /> '''devcourse/classes/output/developer_course_main_page.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use renderable;<br /> use renderer_base;<br /> use templatable;<br /> use stdClass;<br /> <br /> <br /> class developer_course_main_page implements renderable, templatable {<br /> <br /> protected $comment;<br /> <br /> /**<br /> * Construct this renderable.<br /> * @param int $courseid The course record for this page.<br /> */<br /> public function __construct($comment) {<br /> $this-&gt;comment = $comment;<br /> }<br /> <br /> /**<br /> * Export this data so it can be used as the context for a mustache template.<br /> *<br /> * @param renderer_base $output Renderer base.<br /> * @return stdClass<br /> */<br /> public function export_for_template(renderer_base $output) {<br /> $data = new stdClass();<br /> $data-&gt;comment = $this-&gt;comment;<br /> return $data;<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step Two: To render this information a custom renderer is created for the plugin. This renderer class must extend plugin_renderer_base.<br /> <br /> '''devcourse/classes/output/renderer.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> <br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use plugin_renderer_base;<br /> use renderable;<br /> <br /> class renderer extends plugin_renderer_base {<br /> <br /> /**<br /> * Defer to template.<br /> *<br /> * @param developer_course_main_page $page<br /> *<br /> * @return string html for the page<br /> */<br /> public function render_developer_course_main_page(developer_course_main_page $page) {<br /> $data = $page-&gt;export_for_template($this);<br /> return parent::render_from_template('tool_devcourse/developer_course_main_page', $data);<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step three: A mustache template is to then be created. The information is sent to the template and at this point the information is known as the context (not to be confused with the normal definition of context throughout Moodle).<br /> <br /> '''devcourse/templates/developer_course_main_page.mustache'''<br /> &lt;code html&gt;<br /> {{!<br /> @template tool_devcourse/developer_course_main_page<br /> <br /> Example context (json):<br /> {<br /> &quot;comment&quot;: &quot;Example comment for the context&quot;<br /> }<br /> }}<br /> &lt;h2&gt;{{#str}}maintitle, tool_devdoc{{/str}}&lt;/h2&gt;<br /> &lt;div&gt;{{comment}}&lt;/div&gt;<br /> &lt;/code&gt;<br /> This shows an extremely simple mustache template with one item in the context (comment). It also shows how strings are defined in the template.<br /> <br /> Step four: To actually have this template be displayed we get the custom renderer. This chunk of code would be located in a place such as devcourse/index.php after the appropriate setup outlined in the [[Tutorial#Basic_page_structure|basic page structure]].<br /> &lt;code php&gt;<br /> $output = $PAGE-&gt;get_renderer('tool_devcourse');<br /> //Then we get the class for rendering and provide it with information (if needed).<br /> $randomcomment = 'This comment is random';<br /> $page = new \tool_devdoc\output\developer_course_main_page($randomcomment);<br /> //Finally we echo out the template<br /> echo $output-&gt;render($page);<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Output API]]<br /> * [[Output functions]]<br /> * [[Templates]]<br /> * [[Output renderers]]<br /> * [[Renderer]]<br /> * [[Overriding a renderer]]<br /> <br /> ===Adding your plugin into Moodle's navigation===<br /> * The moodle navigation system has hooks which allows plugins to add links to the navigation menu.<br /> * Hooks are located in lib.php. Try to keep lib.php as small as possible as this file is included on every page. Put classes and functions elsewhere.<br /> * Course navigation extension example:<br /> &lt;code php&gt;<br /> function tool_devcourse_extend_navigation_course($navigation, $course, $coursecontext) {<br /> $url = new moodle_url('/admin/tool/devcourse/index.php');<br /> $devcoursenode = navigation_node::create('Development course', $url, navigation_node::TYPE_CUSTOM, 'Dev course', 'devcourse');<br /> $navigation-&gt;add_node($devcoursenode);<br /> }<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Navigation API]]<br /> * [[:en:Navigation]]<br /> <br /> ===Database queries===<br /> * Moodle has a generic database query library. Behind this library are additional libraries which allow Moodle to work with MySQL, PostgreSQL, Oracle, SQL Server, and Maria DB.<br /> * Where possible it is advisable to use the predefined functions rather than write out SQL. Writing SQL has a greater chance of not working with one of the supported databases.<br /> * The return of the select functions tends to be an object or an array of objects.<br /> <br /> Example call to retrieve data from the course table.<br /> &lt;code php&gt;<br /> global $DB;<br /> $courses = $DB-&gt;get_records('course', null, '', 'id, category, fullname, shortname');<br /> &lt;/code&gt;<br /> Example of data returned from the above code.<br /> &lt;code&gt;<br /> Array<br /> (<br /> [43] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 43<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX -Test 5<br /> [shortname] =&gt; xxt5<br /> )<br /> <br /> [5] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 5<br /> [category] =&gt; 1<br /> [fullname] =&gt; With the glossary<br /> [shortname] =&gt; wtg<br /> )<br /> <br /> [39] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 39<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX - Test 1<br /> [shortname] =&gt; xxt1<br /> )<br /> )<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Database]]<br /> * [[Data manipulation API]]<br /> <br /> ===Creating your own database tables===<br /> * We create our database tables in Moodle using the XMLDB editor. This is located in the administration block &quot;Site administration | Development | XMLDB editor&quot;.<br /> * The {plugin}\db directory needs to have write access for the XMLDB editor to be most effective.<br /> * XMLDB editor creates an install.xml file in the db directory. This file will be loaded during the install to create your tables.<br /> * XMLDB editor will produce php update code for adding and updating moodle database tables.<br /> <br /> The XMLDB main page.<br /> <br /> [[{{ns:file}}:xmldb-main.png]]<br /> <br /> Upgrade code generated by the XMLDB<br /> <br /> [[{{ns:file}}:xmldb-upgrade-code.png]]<br /> <br /> links<br /> * [[XMLDB editor]]<br /> * [[Using XMLDB]]<br /> * [[XMLDB Documentation]]<br /> * [[Upgrade API]]<br /> * [[XMLDB introduction]]<br /> <br /> ===Supporting access permissions: roles, capabilities and contexts===<br /> * Capabilities are controlled in &quot;access.php&quot; under the &quot;db&quot; directory.<br /> * This file has an array of capabilities with the following:<br /> ** name<br /> ** possible security risks behind giving this capability.<br /> ** The context that this capability works in.<br /> ** The default roles (teacher, manager, student, etc) that have this capability.<br /> ** Various other information.<br /> * These capabilities are checked in code to allow access to pages, sections, and abilities (saving, deleting, etc).<br /> <br /> links<br /> * [[Access API]]<br /> * [[Roles#Context]]<br /> * [[:en:Category:Capabilities]]<br /> * [[:en:Roles and permissions]]<br /> <br /> ===Adding web forms===<br /> * Moodle has it's own forms library.<br /> * The forms lib includes a lot of accessibility code, and error checking, by default.<br /> * Moodle forms can be displayed in JavaScript using 'fragments'.<br /> <br /> links<br /> <br /> * [[Form API]]<br /> * [[lib/formslib.php Form Definition]]<br /> * [[Fragment]]<br /> <br /> ===Maintaining good security===<br /> * Use the sesskey when directing to pages to do actions.<br /> * Use the appropriate filters when retrieving parameters<br /> <br /> links<br /> <br /> * [[lib/formslib.php Form Definition#Most Commonly Used PARAM .2A Types]]<br /> * [[Output functions#p.28.29 and s.28.29]]<br /> <br /> ===Handling files===<br /> * Files are conceptually stored in file areas.<br /> * Plugins can only access files from it's own component.<br /> <br /> links<br /> <br /> * [[File API]]<br /> * [[File API internals]]<br /> * [[Using the File API in Moodle forms]]<br /> <br /> ===Adding Javascript===<br /> * Moodle is currently using jquery and AMD (Asynchronous Module Definition).<br /> * JavaScript files are located in the &quot;amd/src&quot; directory.<br /> * Use grunt to build your JavaScript.<br /> * Include your JavaScript in php files as follows:<br /> &lt;code php&gt;<br /> $this-&gt;page-&gt;requires-&gt;js_call_amd('{JScriptfilename}');<br /> &lt;/code&gt;<br /> * Can also be included in mustache templates.<br /> <br /> links<br /> <br /> * [[Javascript Modules]]<br /> * [[jQuery]]<br /> * [[Javascript FAQ]]<br /> * [[JavaScript guidelines]]<br /> * [[Grunt]]<br /> <br /> ===Adding events and logging===<br /> * All logging in moodle is done through the events system.<br /> * New events should be located in the &quot;classes/event&quot; directory.<br /> * It is possible to create observers and subscribe to events.<br /> <br /> links<br /> <br /> * [[Event 2]]<br /> * [[Logging 2]]<br /> <br /> ===Web Services and AJAX===<br /> * Moodle web services uses the external functions API.<br /> * The recommended way to make AJAX requests is to use the ajax AMD file which uses the external functions API.<br /> * External functions should be located in the &quot;classes/external.php&quot; file.<br /> * A list of services should be included in &quot;db/services.php&quot;. This file is required to register the web services with Moodle.<br /> * The services list is an array which contains:<br /> ** '''classname''' Name of the external class.<br /> ** '''methodname''' The name of the external function.<br /> ** '''classpath''' system path to the external function file.<br /> ** '''description''' Description of the function<br /> ** '''type''' Create, read, update, delete<br /> ** '''ajax''' Can this function be used with ajax?<br /> ** '''capabilities''' Capabilities required to use this function.<br /> <br /> links<br /> <br /> * [[External functions API]]<br /> * [[Adding a web service to a plugin]]<br /> * [[Web services API]]<br /> <br /> ===Using caching to improve performance===<br /> * The main cache used by moodle is the Moodle Universal Cache (MUC).<br /> * The MUC has several cache definitions - <br /> ** Request cache<br /> ** Session cache<br /> ** Application<br /> <br /> links<br /> <br /> * [[The Moodle Universal Cache (MUC)]]<br /> * [[:en:MUC FAQ]]<br /> * [[:en:Caching]]<br /> <br /> ===Supporting backup and restore===<br /> * Supporting backup and restore requires creating several files in the 'backup/moodle2' directory.<br /> * Back requires a class to extend the backup_task of some sort. There may be a specific plugin task to extend.<br /> * Restore requires a class to extend the restore_task of some sort. There may be a specific plugin task to extend.<br /> * The restore steps lib defines the structure of the plugin to be restored.<br /> * The backup steps lib defines steps, settings, attributes, etc.<br /> <br /> links<br /> <br /> * [[Backup 2.0 for developers]] - provides an example of step-by-step implementation of backup support to your plugin<br /> * [[:en:Backup and restore FAQ]]<br /> <br /> ===Supporting automated testing===<br /> * Moodle has two types of automated testing: php unit tests, and behat tests.<br /> * Unit tests are for testing functions.<br /> * Behat tests runs through scenarios.<br /> ** Behat tests follows a script and navigates through moodle pages.<br /> * unit tests should be located in the &quot;tests&quot; directory.<br /> * behat tests should be located in the &quot;tests/behat&quot; directory.<br /> * Tests located in these directories will be run through when a full test run is initiated.<br /> * behat tests are actually feature files and end with the extension &quot;.feature&quot;.<br /> <br /> links<br /> <br /> * [[Writing PHPUnit tests]]<br /> * [[PHPUnit]]<br /> * [[Acceptance testing]]<br /> * [[Behat integration]]<br /> <br /> ==Publishing your plugin==<br /> ===Adding your plugin to moodle.org===<br /> * publish your plugins at https://moodle.org/plugins/<br /> * Publishing plugins on the moodle site leads you through a bunch of steps that need to be completed in order for the plugin to be approved and published.<br /> * Plugins will be run through a pre-checker to give suggestions about possible issues with the code.<br /> <br /> ===Supporting your plugin===<br /> <br /> <br /> =TODO=<br /> <br /> Finishing this tutorial:<br /> # About one or two screens for each section with a very generic overview for beginners, containing links to relevant docs WITH COMMENTS ABOUT QUALITY, USEFULNESS, CAVEATS etc.<br /> # Go through all the linked pages and make sure they are current and accurate.<br /> # Add a worked example to this page, so that each section has suggestions about things to add to the admin tool being built as an exercise. If the code is long, it could be placed on separate pages. A good reference for style is [[Moodle_Mobile_Developing_a_plugin_tutorial]] and [[Blocks]].<br /> <br /> ==See also==<br /> * See [https://moodle.org/mod/forum/discuss.php?d=352360 this forum thread] about Getting Started with Moodle Development.<br /> <br /> =See also these older tutorials =<br /> * [[Blocks|A Step-by-step Guide To Creating Blocks]] <br /> * [[NEWMODULE Tutorial]]<br /> * [http://dev.moodle.org Introduction to Moodle programming (based on Moodle 1.8)]<br /> * [[Moodle_Mobile_Developing_a_plugin_tutorial|Moodle Mobile plugin tutorial]]<br /> * [[Category:Tutorial|Other tutorials in these docs]]<br /> <br /> [[Category:Tutorial]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Page_API&diff=52836 2017-08-21T06:04:30Z

<p>Ankitfrenz: </p> <hr /> <div>The Page API is used to set up the current page, add JavaScript, and configure how things will be displayed to the user.<br /> <br /> ==Overview==<br /> The Page API is an integral part of any Moodle page. It allows the developer to set things up the way they envisage it. Through the Page API you can set things like the title, initial heading, where the user is for the navigation, and which layout you think the page should use.<br /> <br /> This document starts off with a simple example, and then proceeds to provide a more complete description of how to set up a page for display.<br /> <br /> ==A simple example==<br /> This example covers how to set up a basic page for use within an activity plugin and is undoubtedly the simplest example as much of the work is done behind the scenes for you.<br /> &lt;code php&gt;<br /> // File: /mod/mymodulename/view.php<br /> require_once('../../config.php');<br /> $cmid = required_param('id', PARAM_INT);<br /> $cm = get_coursemodule_from_id('mymodulename', $cmid, 0, false, MUST_EXIST);<br /> $course = $DB-&gt;get_record('course', array('id' =&gt; $cm-&gt;course), '*', MUST_EXIST);<br /> <br /> require_login($course, true, $cm);<br /> $PAGE-&gt;set_url('/mod/mymodulename/view.php', array('id' =&gt; $cm-&gt;id));<br /> $PAGE-&gt;set_title('My modules page title');<br /> $PAGE-&gt;set_heading('My modules page heading');<br /> <br /> // The rest of your code goes below this.<br /> &lt;/code&gt;<br /> If you are not familiar with what the first four lines are doing try going through these docs before proceeding - <br /> <br /> * [https://docs.moodle.org/en/Context Context explained]<br /> * [https://docs.moodle.org/dev/Course_module Course module explained]<br /> <br /> <br /> So lets start at require_login and assume you already have the course and course module objects ready to use. When you call require_login part of the magic it does for you is set up the basic for the current page.&lt;br /&gt;<br /> In the case of the example above because require_login is given a course and course module it is already setting up much of the page for you. It is giving the course and course module objects to the page, setting the context for the page to the course modules context, and setting the page layout to ''incourse'' so that you get the standard look of a course module.<br /> <br /> The set up that we are having to do is as follows:<br /> # Set the URL for the page. This MUST be done.<br /> # Set a title for the page. Most likely will be shown in the &lt;title&gt; tag.<br /> # Set the heading for the page. Most likely used in the pages header.<br /> <br /> It's important to mention that this has to be done before output starts. That means you must set up the page before the header is printed and before you instantiate any moodleform instances.<br /> <br /> And that is it, if you were to add a bit of simple output there you would get a page that already looks like other module pages you would have seen. Simple as.<br /> <br /> ==$PAGE The Moodle page global==<br /> For every page request Moodle sets up a couple of global structures that you will likely need. $DB the database object, and $CFG which stores configuration are two that you are likely already aware of. $PAGE is the focus of this article, it is a moodle_page instance that stores all of the information and is used by the output library $OUTPUT when displaying the page.&lt;br /&gt;<br /> It's important to note the difference between $PAGE and $OUTPUT, $PAGE is for setting up the page and $OUTPUT is for displaying the page. $PAGE contains lots of logic and magic, $OUTPUT is purely about display and does little more than produce HTML.<br /> <br /> ==Setting up the page==<br /> When creating a page in Moodle there are a couple of things that you must set, and a couple of things that get set for you in many cases but not all of the time.<br /> <br /> ===URL===<br /> This is an absolute must, failing to set this will lead Moodle to display an error that it has not been set.&lt;br /&gt;<br /> It can be set in the following manner:<br /> <br /> &lt;code php&gt;<br /> $PAGE-&gt;set_url(new moodle_url('/path/to/your/file.php', array('key' =&gt; 'value', 'id' =&gt; 3)));<br /> $PAGE-&gt;set_url('/path/to/your/file.php', array('key' =&gt; 'value', 'id' =&gt; 3));<br /> $PAGE-&gt;set_url('/path/to/your/file.php?key=value&amp;id=3');<br /> &lt;/code&gt;<br /> <br /> The above code sets the page URL 3 times, and highlights the 3 different ways you can set the URL. Either of the first two methods are the preferred way as it provides 100% accuracy when processing the URL. Internally set_url() converts what ever you give it to a moodle_url object.<br /> <br /> The URL that you give to the page is going to be used by many Moodle core API's. Most importantly it is going to be used to create the navigation for your page so it's very important you set it accurately.<br /> <br /> ===Context===<br /> This is an absolute must as well, however in many cases it will be set for you magically by Moodle.<br /> <br /> In order to set the context for the page you must provide a context object, in Moodle 2.2 and greater this will look as follows:<br /> &lt;code php&gt;<br /> // Moodle 2.2 and greater<br /> $PAGE-&gt;set_context(context_system::instance());<br /> $PAGE-&gt;set_context(context_coursecat::instance($categoryid));<br /> $PAGE-&gt;set_context(context_course::instance($courseid));<br /> $PAGE-&gt;set_context(context_module::instance($moduleid));<br /> &lt;/code&gt;<br /> <br /> In Moodle 2.0+, and Moodle 2.1+ the following is the equivalent code:<br /> &lt;code php&gt;<br /> // Moodle 2.0 and 2.1<br /> $PAGE-&gt;set_context(get_system_context());<br /> $PAGE-&gt;set_context(get_context_instance(CONTEXT_COURSECAT, $categoryid));<br /> $PAGE-&gt;set_context(get_context_instance(CONTEXT_COURSE, $courseid));<br /> $PAGE-&gt;set_context(get_context_instance(CONTEXT_MODULE, $moduleid));<br /> &lt;/code&gt;<br /> <br /> In both examples above setting different types of contexts has been illustrated however you should only ever call set_context() once with the context that is most appropriate to the page you are creating.&lt;br /&gt;<br /> If it is a plugin then the context to use would be the context you are using for your capability checks.<br /> <br /> As mentioned above the other thing to be aware of is that in some circumstances this gets automatically set for you.&lt;br /&gt;<br /> If your script calls require_login (and most scripts have to) and you are providing a course, or a module to your require login call then you will not need to call set_context().&lt;br /&gt;<br /> This is because require_login handles it for you.<br /> <br /> If your script doesn't call require_login, or you don't call it with a course and/or module then you will need to manually set the context as shown.<br /> <br /> ===Optional set up===<br /> The following are optional extras you can set up against the PAGE object that you are likely to encounter throughout Moodle core, and are likely to want to use yourself.<br /> ====Page layout====<br /> The following code sets the pages layout to the standard layout, the most generic layout in the arsenal.<br /> &lt;code php&gt;<br /> $PAGE-&gt;set_pagelayout('standard');<br /> &lt;/code&gt;<br /> When setting the page layout you should use the layout that is the closest match to the page you are creating. Layouts are used by themes to determine what is shown on the page. The most prominent difference between layouts is the block regions they support. The default layout `''base''` for example doesn't normally have any block regions at all, where as normally `''standard''` has the most generic layout and several block regions.<br /> <br /> There are dozens of different layouts that can be, and are used throughout Moodle core that you can use within your code. For a full list of common layouts you are best too look at theme/base/config.php or refer to the list below.<br /> <br /> Note: It's important to know that the theme determines what layouts are available and how each looks. If you select a layout that the theme doesn't support then it will revert to the default layout while using that theme.&lt;br /&gt;Themes are also able to specify additional layouts, however its important to spot them and know that while they may work with one theme they are unlikely to work as you expect with other themes.<br /> <br /> ====Base theme page layouts====<br /> The following is a list of the layouts defined by the base theme. Theme designers are encouraged to make the base theme a parent of their custom theme so you can be sure that in 99% of cases these layouts will be available.<br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Layout<br /> ! Description<br /> |-<br /> | base<br /> | Most backwards compatible layout without the blocks. This is the layout used by default.<br /> |-<br /> | standard<br /> | Standard layout with blocks, this is recommended for most pages with general information<br /> |-<br /> | course<br /> | The course main page uses this layout.<br /> |-<br /> | coursecategory<br /> | Category course listings.<br /> |-<br /> | incourse<br /> | Used for areas within a course, typical for modules. Default page layout if $cm specified in require_login().<br /> |-<br /> | frontpage<br /> | The site home page uses this.<br /> |-<br /> | admin<br /> | Admin and settings pages as well as server administration scripts.<br /> |-<br /> | mydashboard<br /> | The users dashboard.<br /> |-<br /> | mypublic<br /> | A users public profile uses this layout.<br /> |-<br /> | login<br /> | The login screen.<br /> |-<br /> | popup<br /> | Pages that appear in popup windows, usually no navigation, blocks, or header.<br /> |-<br /> | frametop<br /> | Used for the outermost content of a page constructed with frames. Usually no blocks and minimal footer.<br /> |-<br /> | embedded<br /> | Embedded pages such as content for iframes/objects. Needs as much space as possible usually no blocks, header, or footer.<br /> |-<br /> | maintenance<br /> | Used during upgrade, installation, and when maintenance mode is enabled.<br /> |-<br /> | print<br /> | Gets used when printing a page. Normally just a simple header and no blocks.<br /> |-<br /> | redirect<br /> | A special layout used during a redirect. Normally with content only.<br /> |-<br /> | report<br /> | Used for reports within Moodle. Special layout designed to handle horizontal scrolling in a nice way.<br /> |}<br /> <br /> ====Title====<br /> Setting an appropriate title is certainly a must for any properly designed page. While it is optional it is highly recommended that you set the title.<br /> &lt;code php&gt;<br /> $PAGE-&gt;set_title('This is my title');<br /> &lt;/code&gt;<br /> When setting the title for the page you need to provide just the string you want to use for the title. It should be a basic string and contain no HTML. Any HTML will be stripped out as the title is used within the &lt;title&gt; tag in the HTML head.<br /> <br /> ====Heading====<br /> Like title it is highly recommended that you set a meaningful heading for the page, although it is optional.&lt;br /&gt;The heading is normally displayed at the top of the page before the rest of the content starts. However it is up to the layout defined by the theme as to where it is displayed. Not all layouts will display a heading but I encourage you to always set one even if you are using a layout that doesn't support headings. This way if you are using a theme that uses a heading on every page regardless of layout things still look consistent.<br /> <br /> &lt;code php&gt;<br /> $PAGE-&gt;set_heading(get_string('pluginname', 'local_myplugin'));<br /> &lt;/code&gt;<br /> <br /> When setting a heading there is just one argument, the string to use for the heading. It should be a basic string and contain no HTML.<br /> <br /> === Advanced set up ===<br /> The following are advanced optional methods you can call to further set up your page. In most cases you will never need to use these.<br /> <br /> ; set_activity_record : If you have called require_login with a course module, or you have manually set a course module on $PAGE then one other thing you may want to do is set the activity module record on $PAGE as well.&lt;br /&gt;This is best done when you have already fetched the activity record yourself in which case manually setting the activity record may reduce the number of queries for the page by 1.<br /> &lt;code php&gt;$PAGE-&gt;set_activity_record($activityrecord);&lt;/code&gt;<br /> <br /> ; set_blocks_editing_capability : Using this method you can set an additional capability that users must posses before being able to edit blocks on this page.&lt;br /&gt;By default 'moodle/site:manageblocks' is used however there are sometimes reasons to use a different capability.<br /> &lt;code php&gt;$PAGE-&gt;set_blocks_editing_capability($strcapability);&lt;/code&gt;<br /> <br /> ; set_button : This allows you to set some HTML that will be shown in the navigation bar where the `Turn on editing` button normally lives.<br /> &lt;code php&gt;$PAGE-&gt;set_button($htmlstring);&lt;/code&gt;<br /> <br /> ; set_cacheable : By setting this to false the page will be sent with headers to prevent the client from caching the page. Defaults to true.<br /> &lt;code php&gt;$PAGE-&gt;set_cacheable(true/false);&lt;/code&gt;<br /> <br /> ; set_category_by_id : Allows you to set a category that this page is displaying. Calling this will force the $PAGE-&gt;course to be set to the front page course.<br /> &lt;code php&gt;$PAGE-&gt;set_category_by_id($categoryid);&lt;/code&gt;<br /> <br /> ; set_cm : Like set page above, sometimes you need to manually set the course module for $PAGE. Again you must set the context to the context of the course module if you call this.<br /> &lt;code php&gt;$PAGE-&gt;set_cm($coursemodulerecord);&lt;/code&gt;<br /> <br /> ; set_course : This allows you to set the course the page belongs to. Normally when you call require_login the course you give it automatically gets sent to $PAGE for you.&lt;br /&gt;However if you don't want to require login for the course, but you need it in $PAGE then you can call set_course and provide it.&lt;br /&gt;Note that if you do this then you MUST use the context of the course when calling set_context().<br /> &lt;code php&gt;$PAGE-&gt;set_course($courserecord);&lt;/code&gt;<br /> <br /> ; set_docs_path : Normally this gets automatically constructed for you, however in some circumstances you may want to manually set it.&lt;br /&gt;This allows you to have several pages that all point to the same docs page rather than requiring a docs page for each.&lt;br /&gt;The docs page link is normally shown by a theme in the footer.<br /> &lt;code php&gt;$PAGE-&gt;set_docs_path($strpath);&lt;/code&gt;<br /> <br /> ; set_focuscontrol : If you pass this method an element id when the page loads on the client focus will be shifted to the element with the corresponding id.&lt;br /&gt;Using this function is a REALLY bad idea in most situations because changing focus automatically in a browser is a nightmare for the vision impaired and those using screen readers.<br /> &lt;code php&gt;$PAGE-&gt;set_focuscontrol($controlid);&lt;/code&gt;<br /> <br /> ; set_headingmenu : This allows you to set some HTML that will be shown next to the pages main heading where the language select box normally lives.<br /> &lt;code php&gt;$PAGE-&gt;set_headingmenu($htmlstring);&lt;/code&gt;<br /> <br /> ; set_other_editing_capability : Can be used to set an additional capability that the user must posses before they can turn editing on for this page.&lt;br /&gt;This is useful if you can an editing more for your page that is more than just editing blocks.<br /> &lt;code php&gt;$PAGE-&gt;set_other_editing_capability($strcapability);&lt;/code&gt;<br /> <br /> ; set_pagetype : This gets automatically set up for by default to the path of your file e.g. mod/mymod/index.php will set up as mod-mymod-index.&lt;br /&gt;This is absolutely fine in 99% of cases however every now and again there is a reason to override it.<br /> &lt;code php&gt;$PAGE-&gt;set_pagetype($strpagetype);&lt;/code&gt;<br /> <br /> ; set_periodic_refresh_delay : If set a meta tag gets added to the page header causing it to refresh intermittently.&lt;br /&gt;This is rarely needed but can be useful if you need to automatically refresh the likes of a chat page, or news feed.&lt;br /&gt;Today it is not recommended to use this, but instead to create a means of getting additional content via AJAX.<br /> &lt;code php&gt;$PAGE-&gt;set_periodic_refresh_delay($intdelay);&lt;/code&gt;<br /> <br /> ; set_popup_notification_allowed : Allow or disallow popup notifications on this page. Things like messaging can cause messages to popup at the bottom of the screen sometimes.&lt;br /&gt;On some pages this functionality is not desired and can be stopped by calling this method and using false as the first argument.&lt;br /&gt;Popups are allowed by default.<br /> &lt;code php&gt;$PAGE-&gt;set_popup_notification_allowed(true/false);&lt;/code&gt;<br /> <br /> ; set_subpage : If context-&gt;id and pagetype are not enough to uniquely identify this page and you need to include another string to make it more unique you can do it by calling this method setting a custom sub page type.<br /> &lt;code php&gt;$PAGE-&gt;set_subpage($strsubpage);&lt;/code&gt;<br /> <br /> ; add_body_class : Adds a CSS class to the body tag that will be printed by the Output API as part of the header.&lt;br /&gt;This is useful for adding classes to the body tag that describe the content of the page and may be required for styling the whole page, or for including indicator classes that may be useful to look for in JavaScript.<br /> &lt;code php&gt;$PAGE-&gt;add_body_class($strcssclass);&lt;/code&gt;<br /> <br /> ; add_body_classes : Adds an array of CSS classes to the body tag. Have a look at the above comment for '''add_body_class''' for more details.<br /> &lt;code php&gt;$PAGE-&gt;add_body_classes($arrayofclasses);&lt;/code&gt;<br /> <br /> ; force_settings_menu : Theme boost does it's best to find a place to put a settings cog for your activity / resource, but if for some reason it isn't displayed, you can manually set the settings cog to be displayed on the page. This should be called before main content is displayed. This setting only currently shows the setting cog on theme_boost.<br /> &lt;code php&gt;$PAGE-&gt;force_settings_menu();&lt;/code&gt;<br /> <br /> ==Getting information about the page==<br /> As well of setting up the page you can of course get information back from it about the page it has been set up to display.&lt;br /&gt;<br /> Anything you set against the page can be retrieved as can any information that was set magically for you by other methods.<br /> <br /> The following are the most interesting and likely useful things you can get back from the page.<br /> <br /> ; activityrecord : The activityrecord will be the record from the database that relates to the cm that was set by require_login, or manually by your code.&lt;br /&gt;For example if you provided a $cm instance that related to a forum this will be a row from the forum table.<br /> &lt;code php&gt;$var = $PAGE-&gt;activityrecord;&lt;/code&gt;<br /> <br /> ; blockmanager : This is the block manager responsible for loading the all of the blocks that will be shown on the page.&lt;br /&gt;For more information see the [[Blocks API]].<br /> &lt;code php&gt;$var = $PAGE-&gt;blockmanager;&lt;/code&gt;<br /> <br /> ; bodyid : The id that will be given to the body tag when the page is displayed.<br /> &lt;code php&gt;$var = $PAGE-&gt;bodyid;&lt;/code&gt;<br /> <br /> ; categories : An array of all the categories the page course belongs to, starting with the immediately containing category.<br /> &lt;code php&gt;$var = $PAGE-&gt;categories;&lt;/code&gt;<br /> <br /> ; category : The category that the page course belongs to.<br /> &lt;code php&gt;$var = $PAGE-&gt;category;&lt;/code&gt;<br /> <br /> ; cm : The course module that has been set for the page.<br /> &lt;code php&gt;$var = $PAGE-&gt;cm;&lt;/code&gt;<br /> <br /> ; course : The course that has been set for the page.<br /> &lt;code php&gt;$var = $PAGE-&gt;course;&lt;/code&gt;<br /> <br /> ; devicetypeinuse : The device the user is using browse the page.<br /> &lt;code php&gt;$var = $PAGE-&gt;devicetypeinuse;&lt;/code&gt;<br /> <br /> ; headerprinted : Is true if the page header has already been printed. <br /> &lt;code php&gt;$var = $PAGE-&gt;headerprinted;&lt;/code&gt;<br /> <br /> ; heading : The page heading.<br /> &lt;code php&gt;$var = $PAGE-&gt;heading;&lt;/code&gt;<br /> <br /> ; navbar : Gets a reference to the pages navigation bar so that you can interact with that. See the [[Navigation API]] for more information.<br /> &lt;code php&gt;$var = $PAGE-&gt;navbar;&lt;/code&gt;<br /> <br /> ; navigation : Gets a reference to the navigation for the page. See the [[Navigation API]] for more information.<br /> &lt;code php&gt;$var = $PAGE-&gt;navigation;&lt;/code&gt;<br /> <br /> ; requires : Gets the page requirements manager that handles any JavaScript and special CSS requirements for the page.<br /> &lt;code php&gt;$var = $PAGE-&gt;requires;&lt;/code&gt;<br /> <br /> ; settingsnav : Gets the settings navigation for the page. See the [[Navigation API]] for more information.<br /> &lt;code php&gt;$var = $PAGE-&gt;settingsnav;&lt;/code&gt;<br /> <br /> ; theme : Gets the theme that is being used for the page. Is a theme_config object.<br /> &lt;code php&gt;$var = $PAGE-&gt;theme;&lt;/code&gt;<br /> <br /> ; title : Gets the title for the page.<br /> &lt;code php&gt;$var = $PAGE-&gt;title;&lt;/code&gt;<br /> <br /> ; url : Gets the URL that was set for the page. Is a moodle_url object.<br /> &lt;code php&gt;$var = $PAGE-&gt;url;&lt;/code&gt;<br /> <br /> ==FAQs==<br /> <br /> ; I don't have any blocks on my page? : This has happened because you have not set a page layout that uses blocks OR you have set it after output has started. Once output has started you cannot change integral aspects of that page that are used for the initial output. Included is the page title, heading, url and layout.<br /> <br /> ; I am getting a notice about not having set the page URL but I have set it? : As above you must set up the page before output starts, trying to do so will lead to notices and developer warnings about having things in the wrong order.<br /> <br /> ; What starts output? : Output starts when either the script calls echo $OUTPUT-&gt;header OR a moodleform is instantiated.<br /> <br /> ==Related API's==<br /> There are a couple of API's that are closely related to the Page API that you should be aware of as well.<br /> <br /> ===Output API===<br /> The output API is an immediate relation of the page API. The page API is about setting things up, whereas the output API is all about displaying things.<br /> It's through the output API that content is actually produced, and much of the information you set up through the page is used to customise what is produced, and fill in the general blanks of any page (such as title and heading.<br /> <br /> See the [[Output API]] documentation for more information.<br /> <br /> ===Page requirements API===<br /> The page requirements API allows you the developer to include additional CSS, and JavaScript resources that should be included with the page, and to include JavaScript calls within the page through a variety of means.<br /> Technically this API is part of the Output API mentioned above, however it deserves special mention. If you are going to be using any JavaScript or CSS within your page you will need to know about this.<br /> <br /> See the [[Output API]] documentation for more information on the page requirements API.<br /> <br /> ===Navigation API===<br /> The final API to mention is the navigation API. This again is integral to both the page and output API and is used to recognise the context of the content being displayed and ensure that the correct blocks and navigaiton structure are loaded for the context.<br /> There is a good chance that you will encounter a need to customise the navigation early on in plugin page development and it's important to be aware of this important API.<br /> <br /> See the [[Navigation API]] documentation for more information on the page requirements API.<br /> <br /> ==See also==<br /> <br /> * [[Core APIs]] : A list of all the core API's in Moodle.<br /> * [[Output API]] : The Output API.<br /> * [[Navigation API]] : The Navigation API.<br /> * [http://moodle.org/mod/forum/view.php?id=55 General developer forum] : The place to ask question you may have about the Page API.<br /> * MDL-30977 : The issue to see the Page API properly documented.<br /> <br /> <br /> [[Category:API]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Tutorial&diff=52835 2017-08-21T03:55:09Z

<p>Ankitfrenz: </p> <hr /> <div>Welcome to Moodle development!<br /> <br /> This is a tutorial to help you learn how to write plugins for Moodle from start to finish, while showing you how to navigate the most important developer documentation along the way.<br /> <br /> PRE-REQUISITES: We assume you are fairly comfortable with [[PHP FAQ|PHP]] in general and that you are able to [[:en:Installing AMP|install a database and web server]] on your local machine. <br /> <br /> If you need to learn PHP, you can see one PHP tutorial at http://www.w3schools.com/php/default.asp, another at http://php.net/manual/en/tutorial.php and several videos in YouTube at https://www.youtube.com/results?search_query=learn+php. There is a very old unmaintained Introduction to Moodle 1.8 Programming course at http://dev.moodle.org/course/view.php?id=2.<br /> <br /> Code examples can be found on GitHub at https://github.com/abgreeve/devcourse where a working plugin is located.<br /> <br /> ==Background==<br /> ===What's in the box===<br /> If you [http://download.moodle.org/ download] Moodle source code or clone it from [https://github.com/moodle/moodle git], you will see a bunch of files and folders. This code consists of [[Core_APIs|Moodle core]] (that consists of the Very core and Core components), [[Moodle_libraries_credits|third party libraries]] and [[Plugin_types|plugins]]. Their mixed locations can be quite confusing at first but as you start working with it it will become more clear. Moodle developers should avoid modifications of the third party libraries (unless required) and core can never call methods defined in plugins. See also [[Communication Between Components]]<br /> <br /> ===Setting up your development environment===<br /> * Moodle uses Git for developement. View the link below for basic information about Git and Moodle.<br /> <br /> links<br /> <br /> * [[Git for developers]]<br /> <br /> ===The Moodle development framework===<br /> ===What type of plugin are you developing?===<br /> * Moodle has lots of different types of plugins.<br /> * There are 24 different categories of plugin listed on the moodle plugin database. Before starting check here to see if someone else has not already created what you are looking for. Perhaps you could contribute to their plugin instead of creating a new one.<br /> <br /> links<br /> <br /> * https://moodle.org/plugins/<br /> * [[Plugin types]]<br /> <br /> ==Let's make a plugin==<br /> ===The skeleton of your plugin===<br /> <br /> You plugin code will be organised into multiple files within a single root directory (and the subdirectories).<br /> <br /> The page [[Plugin files]] provides a list of common plugins files and their purpose.<br /> <br /> See also:<br /> <br /> * [[Moodle architecture]] - general overview of Moodle code architecture<br /> * [[Plugin types]] - list of all supported plugin types<br /> * [https://moodle.org/plugins/ Moodle plugins directory] - repository of contributed plugins for Moodle<br /> * [https://moodle.org/plugins/tool_pluginskel Moodle plugin skeleton generator] - allows to quickly generate code skeleton for a new plugin<br /> <br /> ===Basic page structure===<br /> <br /> * For a page that is displaying content to a user we have the following sections:<br /> ** Required files.<br /> ** POST and GET variables retrieved using required_param and optional_param.<br /> ** context.<br /> ** navigation setup.<br /> ** title, headings, headers.<br /> ** content.<br /> ** footers.<br /> <br /> &lt;code php&gt;<br /> // Required files.<br /> require_once(__DIR__ . '/config.php');<br /> // Required and optional parameters.<br /> $id = required_param('id', PARAM_INT);<br /> $text = optional_param('text', '', PARAM_ALPHA);<br /> <br /> // Setting context for the page.<br /> $PAGE-&gt;set_context(context_system::instance());<br /> // URL is created and then set for the page navigation.<br /> $url = new moodle_url('/test.php');<br /> $PAGE-&gt;set_url($url);<br /> // Heading, headers, page layout.<br /> $PAGE-&gt;set_heading(get_string('hello'));<br /> $PAGE-&gt;set_pagelayout('standard');<br /> echo $OUTPUT-&gt;header();<br /> // Displaying basic content.<br /> echo html_writer::tag('p', $text);<br /> // Display the footer.<br /> echo $OUTPUT-&gt;footer();<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Page API]]<br /> <br /> ===How to support over 100 languages===<br /> * Language files are stored in the &quot;lang&quot; directory. English strings would be found in &quot;lang/en&quot;. Each language contains a file named after the plugin which contains all of the strings. For example the language strings for the assignment activity are found in &quot;mod/assign/lang/en/assign.php&quot;.<br /> * [[:en:Language FAQ#Which_is_the_official_language_for_Moodle.3F| Moodle's default is Australian English]]. <br /> ** American English is a separate language pack (en_us). Please use only Australian (UK) English grammar and spelling when writing Moodle plugins.<br /> ** There is no need to include languages other than the default English, as almost all approved [https://lang.moodle.org/mod/forum/discuss.php?d=2485 plugin strings will be automatically imported into AMOS] for translation by the language packs translators. <br /> * get_string() is used in most cases for displaying text.<br /> * lang_string() is used in situations where the text may not necessarily be displayed.<br /> <br /> &lt;code php&gt;<br /> // Declaration in language file (lang/en/{pluginname}.php)<br /> $string['nameofstring'] = 'Actual string';<br /> &lt;/code&gt;<br /> <br /> The get_string() function takes four parameters, but in this example we are only filling in the first two. The last two parameters are optional. The first parameter is the identifier for the string. The second is the component.<br /> The component will be the name of the language file.<br /> The following example shows a string in the badges block.<br /> &lt;code php&gt;<br /> // Use of string in code.<br /> echo html_writer::tag('p', get_string('numbadgestodisplay', 'block_badges'));<br /> &lt;/code&gt;<br /> <br /> <br /> links<br /> <br /> * [[String API]]<br /> * [[Places to search for lang strings]]<br /> * [[:en:Language customisation]]<br /> * [[Plugin contribution checklist#Strings]]<br /> <br /> ===Add content to your page===<br /> * Content for a page is added through renderers.<br /> * Renderers are typically stored in the &quot;classes/output&quot; directory.<br /> * Putting content in renderers allows themers to override the visual display of the content.<br /> * Very basic information is presented using the html_writer class.<br /> * In most cases templates should be used.<br /> * templates are stored in the &quot;templates&quot; directory. The templates use mustache files.<br /> * Mustache files allow for more generic html with placeholders inserted, that inserts the data (context) at run time.<br /> <br /> The example used below is an admin tool and would be located under admin/tool.<br /> <br /> Step One: Create a class for rendering. This class collects information to display and has a method for formatting that information into a format that the template will understand.<br /> <br /> '''devcourse/classes/output/developer_course_main_page.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use renderable;<br /> use renderer_base;<br /> use templatable;<br /> use stdClass;<br /> <br /> <br /> class developer_course_main_page implements renderable, templatable {<br /> <br /> protected $comment;<br /> <br /> /**<br /> * Construct this renderable.<br /> * @param int $courseid The course record for this page.<br /> */<br /> public function __construct($comment) {<br /> $this-&gt;comment = $comment;<br /> }<br /> <br /> /**<br /> * Export this data so it can be used as the context for a mustache template.<br /> *<br /> * @param renderer_base $output Renderer base.<br /> * @return stdClass<br /> */<br /> public function export_for_template(renderer_base $output) {<br /> $data = new stdClass();<br /> $data-&gt;comment = $this-&gt;comment;<br /> return $data;<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step Two: To render this information a custom renderer is created for the plugin. This renderer class must extend plugin_renderer_base.<br /> <br /> '''devcourse/classes/output/renderer.php'''<br /> <br /> &lt;code php&gt;<br /> namespace tool_devcourse\output;<br /> <br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> use plugin_renderer_base;<br /> use renderable;<br /> <br /> class renderer extends plugin_renderer_base {<br /> <br /> /**<br /> * Defer to template.<br /> *<br /> * @param developer_course_main_page $page<br /> *<br /> * @return string html for the page<br /> */<br /> public function render_developer_course_main_page(developer_course_main_page $page) {<br /> $data = $page-&gt;export_for_template($this);<br /> return parent::render_from_template('tool_devcourse/developer_course_main_page', $data);<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> <br /> Step three: A mustache template is to then be created. The information is sent to the template and at this point the information is known as the context (not to be confused with the normal definition of context throughout Moodle).<br /> <br /> '''devcourse/templates/developer_course_main_page.mustache'''<br /> &lt;code html&gt;<br /> {{!<br /> @template tool_devcourse/developer_course_main_page<br /> <br /> Example context (json):<br /> {<br /> &quot;comment&quot;: &quot;Example comment for the context&quot;<br /> }<br /> }}<br /> &lt;h2&gt;{{#str}}maintitle, tool_devdoc{{/str}}&lt;/h2&gt;<br /> &lt;div&gt;{{comment}}&lt;/div&gt;<br /> &lt;/code&gt;<br /> This shows an extremely simple mustache template with one item in the context (comment). It also shows how strings are defined in the template.<br /> <br /> Step four: To actually have this template be displayed we get the custom renderer. This chunk of code would be located in a place such as devcourse/index.php after the appropriate setup outlined in the [[Tutorial#Basic_page_structure|basic page structure]].<br /> &lt;code php&gt;<br /> $output = $PAGE-&gt;get_renderer('tool_devcourse');<br /> //Then we get the class for rendering and provide it with information (if needed).<br /> $randomcomment = 'This comment is random';<br /> $page = new \tool_devdoc\output\developer_course_main_page($randomcomment);<br /> //Finally we echo out the template<br /> echo $output-&gt;render($page);<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Output API]]<br /> * [[Output functions]]<br /> * [[Templates]]<br /> * [[Output renderers]]<br /> * [[Renderer]]<br /> * [[Overriding a renderer]]<br /> <br /> ===Adding your plugin into Moodle's navigation===<br /> * The moodle navigation system has hooks which allows plugins to add links to the navigation menu.<br /> * Hooks are located in lib.php. Try to keep lib.php as small as possible as this file is included on every page. Put classes and functions elsewhere.<br /> * Course navigation extension example:<br /> &lt;code php&gt;<br /> function tool_devcourse_extend_navigation_course($navigation, $course, $coursecontext) {<br /> $url = new moodle_url('/admin/tool/devcourse/index.php');<br /> $devcoursenode = navigation_node::create('Development course', $url, navigation_node::TYPE_CUSTOM, 'Dev course', 'devcourse');<br /> $navigation-&gt;add_node($devcoursenode);<br /> }<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Navigation API]]<br /> * [[:en:Navigation]]<br /> <br /> ===Database queries===<br /> * Moodle has a generic database query library. Behind this library are additional libraries which allow Moodle to work with MySQL, PostgreSQL, Oracle, SQL Server, and Maria DB.<br /> * Where possible it is advisable to use the predefined functions rather than write out SQL. Writing SQL has a greater chance of not working with one of the supported databases.<br /> * The return of the select functions tends to be an object or an array of objects.<br /> <br /> Example call to retrieve data from the course table.<br /> &lt;code php&gt;<br /> global $DB;<br /> $courses = $DB-&gt;get_records('course', null, '', 'id, category, fullname, shortname');<br /> &lt;/code&gt;<br /> Example of data returned from the above code.<br /> &lt;code&gt;<br /> Array<br /> (<br /> [43] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 43<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX -Test 5<br /> [shortname] =&gt; xxt5<br /> )<br /> <br /> [5] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 5<br /> [category] =&gt; 1<br /> [fullname] =&gt; With the glossary<br /> [shortname] =&gt; wtg<br /> )<br /> <br /> [39] =&gt; stdClass Object<br /> (<br /> [id] =&gt; 39<br /> [category] =&gt; 1<br /> [fullname] =&gt; XX - Test 1<br /> [shortname] =&gt; xxt1<br /> )<br /> )<br /> &lt;/code&gt;<br /> <br /> links<br /> <br /> * [[Database]]<br /> * [[Data manipulation API]]<br /> <br /> ===Creating your own database tables===<br /> * We create our database tables in Moodle using the XMLDB editor. This is located in the administration block &quot;Site administration | Development | XMLDB editor&quot;.<br /> * The {plugin}\db directory needs to have write access for the XMLDB editor to be most effective.<br /> * XMLDB editor creates an install.xml file in the db directory. This file will be loaded during the install to create your tables.<br /> * XMLDB editor will produce php update code for adding and updating moodle database tables.<br /> <br /> The XMLDB main page.<br /> <br /> [[{{ns:file}}:xmldb-main.png]]<br /> <br /> Upgrade code generated by the XMLDB<br /> <br /> [[{{ns:file}}:xmldb-upgrade-code.png]]<br /> <br /> links<br /> * [[XMLDB editor]]<br /> * [[Using XMLDB]]<br /> * [[XMLDB Documentation]]<br /> * [[Upgrade API]]<br /> * [[XMLDB introduction]]<br /> <br /> ===Supporting access permissions: roles, capabilities and contexts===<br /> * Capabilities are controlled in &quot;access.php&quot; under the &quot;db&quot; directory.<br /> * This file has an array of capabilities with the following:<br /> ** name<br /> ** possible security risks behind giving this capability.<br /> ** The context that this capability works in.<br /> ** The default roles (teacher, manager, student, etc) that have this capability.<br /> ** Various other information.<br /> * These capabilities are checked in code to allow access to pages, sections, and abilities (saving, deleting, etc).<br /> <br /> links<br /> * [[Access API]]<br /> * [[Roles#Context]]<br /> * [[:en:Category:Capabilities]]<br /> * [[:en:Roles and permissions]]<br /> <br /> ===Adding web forms===<br /> * Moodle has it's own forms library.<br /> * The forms lib includes a lot of accessibility code, and error checking, by default.<br /> * Moodle forms can be displayed in JavaScript using 'fragments'.<br /> <br /> links<br /> <br /> * [[Form API]]<br /> * [[lib/formslib.php Form Definition]]<br /> * [[Fragment]]<br /> <br /> ===Maintaining good security===<br /> * Use the sesskey when directing to pages to do actions.<br /> * Use the appropriate filters when retrieving parameters<br /> <br /> links<br /> <br /> * [[lib/formslib.php Form Definition#Most Commonly Used PARAM .2A Types]]<br /> * [[Output functions#p.28.29 and s.28.29]]<br /> <br /> ===Handling files===<br /> * Files are conceptually stored in file areas.<br /> * Plugins can only access files from it's own component.<br /> <br /> links<br /> <br /> * [[File API]]<br /> * [[File API internals]]<br /> * [[Using the File API in Moodle forms]]<br /> <br /> ===Adding Javascript===<br /> * Moodle is currently using jquery and AMD (Asynchronous Module Definition).<br /> * JavaScript files are located in the &quot;amd/src&quot; directory.<br /> * Use grunt to build your JavaScript.<br /> * Include your JavaScript in php files as follows:<br /> &lt;code php&gt;<br /> $this-&gt;page-&gt;requires-&gt;js_call_amd('{JScriptfilename}');<br /> &lt;/code&gt;<br /> * Can also be included in mustache templates.<br /> <br /> links<br /> <br /> * [[Javascript Modules]]<br /> * [[jQuery]]<br /> * [[Javascript FAQ]]<br /> * [[JavaScript guidelines]]<br /> * [[Grunt]]<br /> <br /> ===Adding events and logging===<br /> * All logging in moodle is done through the events system.<br /> * New events should be located in the &quot;classes/event&quot; directory.<br /> * It is possible to create observers and subscribe to events.<br /> <br /> links<br /> <br /> * [[Event 2]]<br /> * [[Logging 2]]<br /> <br /> ===Web Services and AJAX===<br /> * Moodle web services uses the external functions API.<br /> * The recommended way to make AJAX requests is to use the ajax AMD file which uses the external functions API.<br /> * External functions should be located in the &quot;classes/external.php&quot; file.<br /> * A list of services should be included in &quot;db/services.php&quot;. This file is required to register the web services with Moodle.<br /> * The services list is an array which contains:<br /> ** '''classname''' Name of the external class.<br /> ** '''methodname''' The name of the external function.<br /> ** '''classpath''' system path to the external function file.<br /> ** '''description''' Description of the function<br /> ** '''type''' Create, read, update, delete<br /> ** '''ajax''' Can this function be used with ajax?<br /> ** '''capabilities''' Capabilities required to use this function.<br /> <br /> links<br /> <br /> * [[External functions API]]<br /> * [[Adding a web service to a plugin]]<br /> * [[Web services API]]<br /> <br /> ===Using caching to improve performance===<br /> * The main cache used by moodle is the Moodle Universal Cache (MUC).<br /> * The MUC has several cache definitions - <br /> ** Request cache<br /> ** Session cache<br /> ** Application<br /> <br /> links<br /> <br /> * [[The Moodle Universal Cache (MUC)]]<br /> * [[:en:MUC FAQ]]<br /> * [[:en:Caching]]<br /> <br /> ===Supporting backup and restore===<br /> * Supporting backup and restore requires creating several files in the 'backup/moodle2' directory.<br /> * Back requires a class to extend the backup_task of some sort. There may be a specific plugin task to extend.<br /> * Restore requires a class to extend the restore_task of some sort. There may be a specific plugin task to extend.<br /> * The restore steps lib defines the structure of the plugin to be restored.<br /> * The backup steps lib defines steps, settings, attributes, etc.<br /> <br /> links<br /> <br /> * [[Backup 2.0 for developers]] - provides an example of step-by-step implementation of backup support to your plugin<br /> * [[:en:Backup and restore FAQ]]<br /> <br /> ===Supporting automated testing===<br /> * Moodle has two types of automated testing: php unit tests, and behat tests.<br /> * Unit tests are for testing functions.<br /> * Behat tests runs through scenarios.<br /> ** Behat tests follows a script and navigates through moodle pages.<br /> * unit tests should be located in the &quot;tests&quot; directory.<br /> * behat tests should be located in the &quot;tests/behat&quot; directory.<br /> * Tests located in these directories will be run through when a full test run is initiated.<br /> * behat tests are actually feature files and end with the extension &quot;.feature&quot;.<br /> <br /> links<br /> <br /> * [[Writing PHPUnit tests]]<br /> * [[PHPUnit]]<br /> * [[Acceptance testing]]<br /> * [[Behat integration]]<br /> <br /> ==Publishing your plugin==<br /> ===Adding your plugin to moodle.org===<br /> * publish your plugins at https://moodle.org/plugins/<br /> * Publishing plugins on the moodle site leads you through a bunch of steps that need to be completed in order for the plugin to be approved and published.<br /> * Plugins will be run through a pre-checker to give suggestions about possible issues with the code.<br /> <br /> ===Supporting your plugin===<br /> <br /> <br /> =TODO=<br /> <br /> Finishing this tutorial:<br /> # About one or two screens for each section with a very generic overview for beginners, containing links to relevant docs WITH COMMENTS ABOUT QUALITY, USEFULNESS, CAVEATS etc.<br /> # Go through all the linked pages and make sure they are current and accurate.<br /> # Add a worked example to this page, so that each section has suggestions about things to add to the admin tool being built as an exercise. If the code is long, it could be placed on separate pages. A good reference for style is [[Moodle_Mobile_Developing_a_plugin_tutorial]] and [[Blocks]].<br /> <br /> ==See also==<br /> * See [https://moodle.org/mod/forum/discuss.php?d=352360 this forum thread] about Getting Started with Moodle Development.<br /> <br /> =See also these older tutorials =<br /> * [[Blocks|A Step-by-step Guide To Creating Blocks]] <br /> * [[NEWMODULE Tutorial]]<br /> * [http://dev.moodle.org Introduction to Moodle programming (based on Moodle 1.8)]<br /> * [[Moodle_Mobile_Developing_a_plugin_tutorial|Moodle Mobile plugin tutorial]]<br /> * [[Category:Tutorial|Other tutorials in these docs]]<br /> <br /> [[Category:Tutorial]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Developer_meeting_July_2015&diff=48304 2015-07-20T09:23:06Z

<p>Ankitfrenz: /* Agenda */</p> <hr /> <div>[[Developer meetings]] &gt; July 2015 meeting notes<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> | Time<br /> | [http://www.timeanddate.com/worldclock/fixedtime.html?year=2015&amp;month=7&amp;day=21&amp;hour=07&amp;min=0&amp;sec=0 07:00 UTC on Tuesday, 21 July 2015] [http://www.google.com/calendar/event?action=TEMPLATE&amp;text=Moodle+General+developer+meeting&amp;dates=20150721T070000Z/20150721T090000Z&amp;details=&amp;location= &lt;span class=&quot;btn btn-info&quot;&gt;Add to my calendar&lt;/span&gt;]<br /> |-<br /> | Meeting room<br /> | [https://www.youtube.com/watch?v=pgPBohzErr4 Live stream at YouTube]<br /> |-<br /> | Forum discussion<br /> | [https://moodle.org/mod/forum/discuss.php?d=316807 Thread in GDF at moodle.org]<br /> |-<br /> | Chat<br /> | [https://moodle.org/local/chatlogs/info.php Regular dev chat]<br /> |-<br /> | Twitter<br /> | [https://twitter.com/search?q=%23moodledev #moodledev]<br /> |-<br /> | Social event page<br /> | [https://plus.google.com/events/c63rl8n5jdjldr9slcd1tdcqmg0 Google+ page]<br /> |-<br /> | Meeting notes<br /> | [https://devpad.moodle.org/p/gdm150721 devpad]<br /> |}<br /> <br /> == Agenda ==<br /> <br /> * Moodle Mobile 2 - Juan Leyva<br /> * Summary report of the recent MoodleMoot Working groups and hackfests (Dublin, Melbourne) - David Mudrák, Andrew Nicols, Michael de Raadt<br /> * Moodle Association and how it is supposed to affect the Moodle development in the future - Martin Dougiamas<br /> * Moodle HQ's personal projects week products - HQ devs<br /> ** Improved East Asian support (ruby tags in Atto and in fullname()) - Jetha Chan<br /> ** mod_lesson improved lesson creation tool - Adrian Greeve<br /> ** Events Graphic Reports plugin - Simey Lameze<br /> ** Moodle - Ifttt integration - Ankit Agarwal<br /> * Work in progress on Learning plans and outcomes project for Moodle 3.0 - Damyon (to be confirmed)<br /> * ...<br /> <br /> Please feel encouraged to raise topics you would like to present / discuss during the meeting. Contact [https://moodle.org/user/profile.php?id=1601 David Mudrák] for details.</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Release_process&diff=48000 2015-06-09T02:24:22Z

<p>Ankitfrenz: /* 1 week after */</p> <hr /> <div>== 8 weeks prior ==<br /> {| class=&quot;table table-striped table-bordered&quot;<br /> |-<br /> ! style=&quot;width:20px&quot; | #<br /> ! style=&quot;width:20px&quot; | Major<br /> ! style=&quot;width:20px&quot; | Minor<br /> ! Task<br /> ! style=&quot;width:12%&quot; | Responsibility<br /> |-<br /> | 1.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Create an issue to review latest stable version of all third party libraries and add to sprint. The issue should refer to the list at [[Moodle libraries credits]]. The issue can be a clone of MDL-47147.<br /> | Development Manager<br /> |-<br /> | 2.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Ensure we are running latest/good behat version.<br /> | Testing Maintainer<br /> |-<br /> | 3.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Move [http://tiny.cc/gl8swx QA tests] for new features in old release with automated tests from MDLQA-1 to MDLQA-5249. <br /> | Testing Maintainer<br /> |}<br /> <br /> ==7 weeks prior==<br /> {| class=&quot;table table-striped table-bordered&quot;<br /> |-<br /> ! style=&quot;width:20px&quot; | #<br /> ! style=&quot;width:20px&quot; | Major<br /> ! style=&quot;width:20px&quot; | Minor<br /> ! Task<br /> ! style=&quot;width:12%&quot; | Responsibility<br /> |-<br /> | 1.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Full demo of new code and sign-off for internal HQ projects. Decide which projects will be completed by the code freeze.<br /> | Lead Developer<br /> |}<br /> <br /> ==6 weeks prior==<br /> {| class=&quot;table table-striped table-bordered&quot;<br /> |-<br /> ! style=&quot;width:20px&quot; | #<br /> ! style=&quot;width:20px&quot; | Major<br /> ! style=&quot;width:20px&quot; | Minor<br /> ! Task<br /> ! style=&quot;width:12%&quot; | Responsibility<br /> |-<br /> | 1.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Create the next &quot;X.Y+1&quot; (next dev) version in the Tracker (MDL and CONTRIB), so people can move delayed stuff to next major release if needed.<br /> | Integration Lead<br /> |-<br /> | 2.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Create a &quot;Must fix for X.Y&quot; version in the tracker.<br /> | Integration Lead<br /> |-<br /> | 3.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Warn external developers about the impending code freeze in a post to the [http://moodle.org/mod/forum/view.php?id=55 General developer forum]. ([https://moodle.org/mod/forum/discuss.php?d=225854 example])<br /> | Development Manager<br /> |-<br /> | 4.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Check [https://tracker.moodle.org/issues/?jql=labels%20%3D%20qa_test_required%20AND%20status%20%3D%20Closed closed qa_test_required-labelled issues] and create new QA tests as required. If features has automated tests then set priority to blocker and link the issue as &quot;is a QA written for&quot;<br /> | Community Manager<br /> |}<br /> <br /> ==5 weeks prior==<br /> {| class=&quot;table table-striped table-bordered&quot;<br /> |-<br /> ! style=&quot;width:20px&quot; | #<br /> ! style=&quot;width:20px&quot; | Major<br /> ! style=&quot;width:20px&quot; | Minor<br /> ! Task<br /> ! style=&quot;width:12%&quot; | Responsibility<br /> |-<br /> | 1.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Confirm the code freeze by replying to the previous warning in the [http://moodle.org/mod/forum/view.php?id=55 General developer forum].<br /> | Development manager<br /> |-<br /> | 2.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Once the integration server has ended with Monday's job [http://integration.moodle.org/view/tracker/job/Tracker%20-%20CI%20-%20Move%20awaiting%20issues%20to%20current%20integration Move awaiting issues to current integration] it will be disabled and, issues will be manually picked for integration until the post-release &quot;On Sync&quot; period ends (usually 3 weeks after release).<br /> | Integration Lead<br /> |-<br /> | 3.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Prepare a fresh installation of the [http://qa.moodle.net QA site] based on the beta code to make sure the site is not affected by incremental upgrade steps during the development cycle.<br /> | QA Master Site Maintainer<br /> |-<br /> | 4.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Write documentation on new features in the dev docs, adding a link to it from the tracker issue, together with the label ''docs_required''. The documentation will then be transferred to the new en version wiki when it is set up (3 weeks prior) and polished, with screenshots added.<br /> | <br /> |}<br /> <br /> ==4 weeks prior==<br /> {| class=&quot;table table-striped table-bordered&quot;<br /> |-<br /> ! style=&quot;width:20px&quot; | #<br /> ! style=&quot;width:20px&quot; | Major<br /> ! style=&quot;width:20px&quot; | Minor<br /> ! Task<br /> ! style=&quot;width:12%&quot; | Responsibility<br /> |-<br /> | 1.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Start working on the [[Releases|release notes]] ([[Release notes template|template]]) of the upcoming version.<br /> | Development Manager<br /> |-<br /> | 2.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Release normal weeklies but with these changes in the master branch:<br /> * version.php: Move to $maturity = MATURITY_BETA and $release = 'X.Ybeta (Build:xxxxxxxx)'<br /> * tag git repo with: &quot;vX.Y.0-beta&quot; (and MOODLE_XY_BETA as description and CVS tag)<br /> And make packages available under download.moodle.org (and windows). Promote master up in the download page and adjust info for it.<br /> | Integration Lead<br /> |-<br /> | 3.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | (Optionally) Announce Beta release in forums (ideally once packages are available).<br /> | Integration Lead<br /> |-<br /> | 4.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | During the QA weeks integration [[Integration Review#During continuous integration/Freeze/QA period|becomes continuous]]; roll (on demand, beta, rc...) happens often (Tuesday &amp; Friday are the usual days).<br /> | Integration Lead<br /> |-<br /> | 5.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | At some points produce release candidates (Z = 1, 2, 3..), which are normal builds with:<br /> * version.php: Move to $maturity = MATURITY_RC and $release = 'X.YrcZ (Build:xxxxxxxx)'<br /> * tag git repo with: &quot;vX.Y.0-rcZ&quot; (and MOODLE_XY_RCZ as description and CVS tag)<br /> * Make packages available under download.moodle.org (and Windows).<br /> | Integration Lead<br /> |-<br /> | 6.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Add a new version in the Plugins Directory with the version's name and the beta release version build number (https://moodle.org/plugins/admin/softwareversions.php).<br /> * Any standard plugins being retired from the release can transition to Add-on (that supports this release and/or any previous ones) now.<br /> * These plugins currently collect at https://moodle.org/plugins/browse.php?list=contributor&amp;id=1532512<br /> | Plugins Liaison<br /> |-<br /> | 7.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Tidy up current latest en version of Moodle Docs prior to copying it to create new version wiki as described in [[New docs version process]].<br /> | Community Manager<br /> |-<br /> | 8.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Create new QA test cycle and invite community volunteers to start [[QA testing]].<br /> | Community Manager<br /> |-<br /> | 9.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Monitor QA fails. Check each fail is real and if so ensure an MDL issue has been created and correctly linked and labelled.<br /> | Testing Maintainer<br /> |-<br /> | 10.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Monitor MDL issues created for QA fails. Add them to the &quot;Must fix for X.Y&quot; list and get a developer to work on the issue immediately.<br /> | Development Manager<br /> |}<br /> <br /> ==3 weeks prior==<br /> {| class=&quot;table table-striped table-bordered&quot;<br /> |-<br /> ! style=&quot;width:20px&quot; | #<br /> ! style=&quot;width:20px&quot; | Major<br /> ! style=&quot;width:20px&quot; | Minor<br /> ! Task<br /> ! style=&quot;width:12%&quot; | Responsibility<br /> |-<br /> | 1.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Prompt developers to begin QA tests marked ''test_server_required''.<br /> | Development Manager<br /> |-<br /> | 2.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Create new en and de Moodle Docs version wikis.<br /> | Moodle Docs Maintainer<br /> |-<br /> | 3.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Check [https://tracker.moodle.org/issues/?jql=labels%20%3D%20docs_required%20AND%20status%20%3D%20Closed docs_required-labelled issues] and write new documentation, removing the label and commenting in the issue when the work is done.<br /> | Community Manager<br /> |-<br /> | 4.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> |<br /> | Go through all points listed under 3 weeks prior in [[New docs version process]].<br /> | Community Manager<br /> |-<br /> | 5.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Review issues with labelled with [https://tracker.moodle.org/issues/?filter=11824&amp;jql=labels%20in%20%28dev_docs_required%29%20AND%20resolution%20%3D%20fixed%20ORDER%20BY%20assignee%20ASC%2C%20created%20ASC dev_docs_required], prompting assigned developers to create/update this documentation and remove this label when relevant docs are updated.<br /> | Development Manager<br /> |}<br /> <br /> ==2 weeks prior==<br /> {| class=&quot;table table-striped table-bordered&quot;<br /> |-<br /> ! style=&quot;width:20px&quot; | #<br /> ! style=&quot;width:20px&quot; | Major<br /> ! style=&quot;width:20px&quot; | Minor<br /> ! Task<br /> ! style=&quot;width:12%&quot; | Responsibility<br /> |-<br /> | 1.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> |<br /> * Prompt developers to complete remaining QA tests.<br /> * Ensure all QA tests are completed and passed by the end of the week.<br /> | Development Manager<br /> |-<br /> | 2.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> |<br /> Create MDLSITE issue to ensure all prototype.moodle.net sites which are no longer relevant (part of release) are removed from prototype.moodle.net<br /> | Development Manager<br /> |-<br /> | 3.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Merge fixes from en_fix pack and then integrate them.<br /> | AMOS Maintainer<br /> |}<br /> <br /> ==1 week prior==<br /> {| class=&quot;table table-striped table-bordered&quot;<br /> |-<br /> ! style=&quot;width:20px&quot; | #<br /> ! style=&quot;width:20px&quot; | Major<br /> ! style=&quot;width:20px&quot; | Minor<br /> ! Task<br /> ! style=&quot;width:12%&quot; | Responsibility<br /> |-<br /> | 1.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Clone as many filters as needed in the Tracker, modifying them to point to the new, upcoming, branch (keeping same perms, title...). <br /> | Integration Lead<br /> |-<br /> | 2.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Create new minor version X.Y.Z+1 in the Tracker (MDL and CONTRIB). Archive any version &gt; 6 months old.<br /> | Integration Lead<br /> |-<br /> | 3.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Clone MDL-50102 and bump all versions, requires and dependencies along all plugins in codebase to planned release dates.<br /> | Integration Lead<br /> |-<br /> | 4.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Post a &quot;Heads-up&quot; message on the [http://partners.moodle.com/mod/forum/view.php?id=2 Partners forum] and [http://moodle.org/mod/forum/view.php?id=55 General Developer forum].<br /> | Development Manager<br /> |-<br /> | 5.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Post a &quot;Heads-up&quot; message on Twitter and other outlets.<br /> | Marketing Officer<br /> |-<br /> | 6.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Identify security issues that need to be integrated using the [http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&amp;jqlQuery=labels+%3D+security_held security_held label].<br /> * Integrate from provided patches into supported branches (including branches supported only for security issues).<br /> * Ensure security issues are given priority in weekly integration and testing. <br /> | Integration Lead<br /> |-<br /> | 7.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Collect security issues into a clone of the [https://tracker.moodle.org/issues/?jql=component%20%3D%20%22Security%20Alert%22%20AND%20project%20%3D%20MDL%20AND%20level%20is%20not%20EMPTY%20AND%20summary%20~%20%22security%20advisories%22%20ORDER%20BY%20updated%20DESC last advisory in the list] to prepare for release of Security Advisories.<br /> * Determine which security issues will be integrated.<br /> * Request CVE Identifiers by emailing issue descriptions to [mailto:distros@vs.openwall.org distros@vs.openwall.org] with a message like... &lt;tt&gt; The following security issues have been discovered in Moodle. We request CVE Identifiers for these issues. We will be releasing the security announcements for these on moodle.org on XXX at 12noon AWST which is 04:00 UTC.&lt;/tt&gt; The email subject should include the characters &lt;tt&gt;[vs]&lt;/tt&gt;. The format needs to be plain text or encrypted. When granted CVE Identifiers, our issues should appear in the [http://cve.mitre.org/cve/cve.html CVE list]. More [http://oss-security.openwall.org/wiki/mailing-lists/distros instructions] are available.<br /> * Post security issues as a reply to the &quot;Heads-up&quot; message on the [http://partners.moodle.com/mod/forum/view.php?id=2 Partners forum].<br /> | Development Manager<br /> |-<br /> | 8.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Review and complete the [[Releases|release notes]] for the upcoming minor versions.<br /> * Ensure all issues labelled with &quot;ui_change&quot;, &quot;api_change&quot; and &quot;release_notes&quot; are listed as UI changes, functional changed and fixes/improvements respectively in the release notes.<br /> | Development Manager<br /> |-<br /> | 9.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Check on the &quot;Must fix for X.Y version&quot;. Filter out unrealistic issues.<br /> | Development Manager<br /> |-<br /> | 10.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Upgrade moodle.org to beta release<br /> |<br /> |-<br /> | 11.<br /> | <br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Upgrade moodle.org and all other Moodle community sites (next sites first, then production) - Friday before release if not before<br /> | <br /> |}<br /> <br /> ==Releasing==<br /> ===Packaging===<br /> This should happen immediately before the next integration cycle begins on Monday (i.e., some days after last weekly, 2 days prior to official release).<br /> {| class=&quot;table table-striped table-bordered&quot;<br /> |-<br /> ! style=&quot;width:20px&quot; | #<br /> ! style=&quot;width:20px&quot; | Major<br /> ! style=&quot;width:20px&quot; | Minor<br /> ! Task<br /> ! style=&quot;width:12%&quot; | Responsibility<br /> |-<br /> | 1.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Make sure there are no real blockers introduced in the last weekly (install / upgrade ...). Confirm that the latest [https://tracker.moodle.org/issues/?jql=summary%20~%20%22en_fix%22%20order%20by%20createdDate%20desc en_fix changes]have been generated and integrated.<br /> | Integration Lead<br /> |-<br /> | 2.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Verify all unit tests and integration tests have passed.<br /> | Integration Lead<br /> |-<br /> | 3.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Verify QA tests have passed.<br /> | Integration Lead<br /> |-<br /> | 4.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Follow the &quot;mdlrelease&quot; steps:<br /> * Run the '''prerelease.sh''' script to generate the target minor (--type minor) and major (--type major) releases and their corresponding tags. Follow the on-screen instructions. Triple verify all changes are correct!<br /> * Push changes to integration.git (but tags).<br /> For major releases only:<br /> * Configure &quot;mdlrelease&quot; (config.sh) to know about the new MOODLE_XY+1 stable branch.<br /> * Update the CI server(s) by cloning all the &quot;master&quot; jobs to a new &quot;MXY&quot; view. Adjust &quot;master&quot; compare DB jobs to check for upgrade from MOODLE_XY_STABLE. Don't forget to re-chain the jobs properly. Run them.<br /> '''Important note''': don't forget to disable memcached application store for unit tests in stable branches. ([https://tracker.moodle.org/browse/MDL-48192?focusedCommentId=322040&amp;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-322040 more info]).<br /> Continue with the &quot;mdlrelease&quot; steps:<br /> * Once CI servers have ended and all jobs have passed, push tags and run the '''release.sh''' script to apply the changes to moodle.git.<br /> * If needed configure &quot;mdlrelease&quot; (config.sh) to get rid of any unsupported version and adjust stable and security branches. Make a pull request with the changes.<br /> | Integration Lead<br /> |-<br /> | 5.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Post a &quot;git repos updated &amp; tagged&quot; message on the [http://partners.moodle.com/mod/forum/view.php?id=2 Partner forum]<br /> | Integration Lead<br /> |-<br /> | 6.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> |<br /> | Create a new MOODLE_XY+1_STABLE branch in https://github.com/moodlehq/moodle-performance-comparison and set the new release commit hash as $basecommit<br /> | Testing Maintainer<br /> |-<br /> | 7.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Wait for the automated moodle-package to finish building for all versions. Verify the process has ended successfully (email).<br /> For major releases only:<br /> * Use the '''prerelease.sh''' script (--type back-to-dev) to move master to next X.Y+1 development version/branch. And push changes to integration.git - note this will lead to the &quot;versions checker&quot; failing for master, no problem, it will be fixed by the 1st cloned issue at #12 below).<br /> * Once CIs have ended, use the &quot;release.sh&quot; script to send those master changes to moodle.git.<br /> | Integration Lead<br /> |-<br /> | 8.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> |<br /> |<br /> * Create new windows packager script (cloning the current master one and configuring it).<br /> * Create new windows_wpiXY dir by cloning the previous one (HEAD based), configuring build-latest-XY.sh.<br /> * Edit the stats.php script (in the moodle-local_downloadmoodleorg repository), adding the new branch to the versions. Deploy it.<br /> | Integration Lead<br /> |-<br /> | 9.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | In the Tracker...<br /> * Visit the versions page and make the release, bumping all remaining open bugs to the next point release. If there is not next (end of support), clean that version from all the issues having it as &quot;Fix for&quot;. This must be done both for the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10011 Moodle Project] and the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10033 Plugins project]. Archive any version &gt; 6 months old.<br /> * Remove from all screens the custom fields belonging to 100% unsupported branches.<br /> For major releases only:<br /> * Release and package the &quot;Must fix for X.Y&quot; versions, it must be empty to do so.<br /> | Integration Lead<br /> |-<br /> | 10.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Create the new &quot;Pull X.Y Branch&quot; and &quot;Pull X.Y Diff URL&quot; custom fields and spread them to all the screens needing them (copy from previous ones). Order them properly on each screen. Re-index Tracker.<br /> Also, in the CI servers ([http://integration.moodle.org/view/tracker/job/Tracker%20-%20CI%20-%20Bulk%20precheck%20issues/ 1], [http://ci.stronk7.com/view/tracker/job/Tracker%20-%20CI%20-%20Bulk%20precheck%20issues/ 2]), edit the &quot;Bulk precheck issues&quot; job to make it meet the new &quot;Pull X.Y Branch&quot; field created.<br /> | Integration Lead<br /> |-<br /> | 11.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | In the Tracker...<br /> * Verify how the &quot;X.Y regressions&quot; versions [https://tracker.moodle.org/issues/?jql=resolution%20%3D%20Unresolved%20AND%20affectedVersion%20in%20(%222.6%20regressions%22%2C%20%222.7%20regressions%22%2C%20%222.8%20regressions%22%2C%20%222.9%20regressions%22)%20AND%20project%20%3D%20MDL are going] and ping Development Managers about. Package and archive them once empty.<br /> For major releases only:<br /> * Create the new &quot;X.Y regressions&quot; version to be applied to every issue found to be a recent problem introduced by the major release. These issues should get priority after release. <br /> Adjust the filter [https://tracker.moodle.org/issues/?filter=17528 Latest regressions]<br /> | Integration Lead<br /> |-<br /> | 12.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Clone MDL-50184, MDL-50183 and MDL-50182, to be resolved ASAP.<br /> | Integration Lead<br /> |-<br /> | 13.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Add/update the release date, build number and link on the [[Releases|Releases page]] and date in new version pages.<br /> | Integration Lead<br /> |-<br /> | 14.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Create the new security-MOODLE_XY_STABLE and lastbased-MOODLE_XY_STABLE branches in the security report (branching from the just created MOODLE_XY_STABLE branch).<br /> | Integration Lead<br /> |}<br /> <br /> ===Release day===<br /> Usually on Monday<br /> {| class=&quot;table table-striped table-bordered&quot;<br /> |-<br /> ! style=&quot;width:20px&quot; | #<br /> ! style=&quot;width:20px&quot; | Major<br /> ! style=&quot;width:20px&quot; | Minor<br /> ! Task<br /> ! style=&quot;width:12%&quot; | Responsibility<br /> |-<br /> | 1.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | The execution of &quot;moodle-package-extract-and-postprocess X&quot; script may be needed if the releases *are not going to be published on Monday* but another weekday (X is the weekday, (1-7) starting in Monday). By default it happens automatically around 09:00 AM Perth/Australia time. <br /> | Integration Lead<br /> |-<br /> | 2.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Verify release status, download pages and windows packages.<br /> | Integration Lead<br /> |-<br /> | 3.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | If needed, modify the downloads cfg script (serverscripts) to decide about branches status, master visibility and windows availability. Push changes, will be autodeployed in a few minutes.<br /> | Integration Lead<br /> |-<br /> | 4.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Notify all registered sys admins, including security notes with CVE identifiers, using the [http://lists.moodle.org/ mailing list server].<br /> | Development Manager<br /> |-<br /> | 5.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Post about the Major release on the [http://moodle.org/news/ moodle.org News forum]<br /> | Lead Developer<br /> |-<br /> | 6.<br /> | <br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Post about minor releases on the [http://moodle.org/news/ moodle.org News forum]<br /> | Development Manager<br /> |-<br /> | 7.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Post about the release on Twitter and other outlets. Update no. of releases on moodle.com 'Fact Sheet' page: http://moodle.com/news/moodle-fact-sheet/<br /> | Digital Marketing Specialist<br /> |-<br /> | 8.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | New &quot;X.Y+1dev&quot; branch to be created in AMOS, to have master changes performed there. New install_XY_STABLE processing set up. These needs to be done anytime during the on-sync period.<br /> | AMOS Maintainer<br /> |-<br /> | 9.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Verify, 24h after tagging, that https://moodle.org/dev/ has been updated with new versions. If not, file an urgent mdlsite issue, crons must be running!<br /> | Integration Lead<br /> |-<br /> | 10.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | For en and de Moodle Docs, update default redirects and enable email notifications.<br /> | Moodle Docs Maintainer<br /> |-<br /> | 11.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Go through all points listed under Day of release in [[New docs version process]].<br /> | Community Manager<br /> |-<br /> | 12.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> |<br /> * Decide the &quot;Full demo&quot;, &quot;Code freeze&quot; and &quot;QA begins&quot; dates for the next X.(Y+1) major release and put them in the [https://www.google.com/calendar/ical/moodle.com_p4c2oe7hsb77ltaro5qtihb5d4%40group.calendar.google.com/public/basic.ics Moodle development calendar]. They will be -7w, -5w and -4w before release date respectively.<br /> * Update the &quot;Full demo&quot;, &quot;Code freeze&quot;, &quot;QA begins&quot; and Release dates on the [[Roadmap]] page.<br /> * Add events to the HQ calendar for next Major release 6-months cycle according to [[Process#Sprints|the cycle plan]]: ~4 weeks planning and regression fixing, 2 sprints, 1 personal project week, 2 sprints, 1 personal project week, 1 sprint (which should lead up to code freeze).<br /> * Notify the Community Manager of new dates to be added to the moodle.org calendar.<br /> | Development Manager<br /> |-<br /> | 13.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | <br /> | Add calendar events in the [https://moodle.org/calendar moodle.org calendar] for coming Major and Minor releases up to the next Major release.<br /> | Community Manager<br /> |-<br /> | 14.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | <br /> | Add $CFG-&gt;skiplangupgrade = 1; to master acceptance test on nightly (apache01 &amp; phantom01), as language pack is not available during on-sync for master.<br /> | Testing Maintainer<br /> |}<br /> <br /> ==1 week after==<br /> {| class=&quot;table table-striped table-bordered&quot;<br /> |-<br /> ! style=&quot;width:20px&quot; | #<br /> ! style=&quot;width:20px&quot; | Major<br /> ! style=&quot;width:20px&quot; | Minor<br /> ! Task<br /> ! style=&quot;width:12%&quot; | Responsibility<br /> |-<br /> | 1.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Publish the X.Y+ packages for download.moodle.org (should be automatic once weeklies are packaged).<br /> | Integration Lead<br /> |-<br /> | 2.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Update the version.php in git to be X.Y.Z+ during the next weekly integration process<br /> | Integration Lead<br /> |-<br /> | 3.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Create a new release notes page for the next minor versions (using the [[Release notes template|release notes template]].) Add note to top of relevant version page about security support.<br /> | Development Manager<br /> |-<br /> | 4.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Add all security advisories to [http://moodle.org/security Security news] and [[:Category:Release notes|release notes]] with links to security advisories<br /> || Development Manager<br /> |-<br /> | 5.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | Send a plain text email to the OSS mailing list: [mailto:oss-security@lists.openwall.com oss-security@lists.openwall.com]. An appropriate message when sending the issues is... <br /> :&lt;tt&gt;The following security notifications have now been made public. Thanks to OSS members for their cooperation.&lt;/tt&gt; <br /> ...followed by the security notes.<br /> | Development Manager<br /> |-<br /> | 6.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Upgrade moodle.org and all other Moodle community sites (next sites first, then production)<br /> |<br /> |-<br /> | 7.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Create nightly jobs for the XY branch (Refer doc [http://wiki.moodle.com/display/integration/How+to+create+VM+after+release+on+nightly?flashId=-515750122]) and disable it after running jobs for day or two, so as to conserve resources on nightly<br /> | Testing Maintainer<br /> |-<br /> | 7.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Clone this issue for next major release - MDL-48470<br /> | Integration Lead<br /> |}<br /> <br /> ==3 weeks after==<br /> {| class=&quot;table table-striped table-bordered&quot;<br /> |-<br /> ! style=&quot;width:20px&quot; | #<br /> ! style=&quot;width:20px&quot; | Major<br /> ! style=&quot;width:20px&quot; | Minor<br /> ! Task<br /> ! style=&quot;width:12%&quot; | Responsibility<br /> |-<br /> | 1.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Once the &quot;On Sync&quot; period ends:<br /> * The &quot;[https://tracker.moodle.org/issues/?filter=13669 integration_held]&quot; label will be removed from issues awaiting integration, so they will be, automatically (see next point), be moved to current integration. Send a &quot;rebase&quot; message to all those issues.<br /> * The &quot;[http://integration.moodle.org/view/tracker/job/Tracker%20-%20CI%20-%20Move%20awaiting%20issues%20to%20current%20integration/ Move awaiting issues to current integration]&quot; job will be re-enabled in the public CI server.<br /> | Integration Lead<br /> |-<br /> | 2.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | In https://github.com/moodlehq/moodle-behat-extension project:<br /> * For the new stable version:<br /> *# Create a MOODLE_XY_STABLE branch from master<br /> * For master:<br /> *# Add a 1.X(Y+1).0 tag for the new release in the master branch<br /> *# Clone MDL-39489, implement, and send it to integration.<br /> | Testing Maintainer<br /> |-<br /> | 3.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Ensure Language pack for master is available and remove $CFG-&gt;skiplangupgrade = 1; for master on nightly (apache01 and phantom01)<br /> | Testing Maintainer<br /> |-<br /> | 4.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Enable nightly jobs for the XY.<br /> | Testing Maintainer<br /> |}<br /> <br /> ==1 month after==<br /> {| class=&quot;table table-striped table-bordered&quot;<br /> |-<br /> ! style=&quot;width:20px&quot; | #<br /> ! style=&quot;width:20px&quot; | Major<br /> ! style=&quot;width:20px&quot; | Minor<br /> ! Task<br /> ! style=&quot;width:12%&quot; | Responsibility<br /> |-<br /> | 1.<br /> | style=&quot;text-align:center&quot; | &amp;#10003;<br /> | <br /> | Publish the X.(Y+1)dev packages for download.moodle.org<br /> | Integration Lead<br /> |}<br /> <br /> ==See also==<br /> <br /> * [[Deprecation|Deprecation process]]<br /> <br /> [[Category:Processes|Release process]]<br /> [[Category:Release notes|Release process]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=String_deprecation&diff=47917 2015-05-18T07:47:04Z

<p>Ankitfrenz: </p> <hr /> <div>{{Infobox Project<br /> |name = String deprecation<br /> |state = Implemented<br /> |tracker = MDL-46585<br /> |discussion =<br /> |assignee = Marina Glancy<br /> }}<br /> {{Moodle 2.8}}<br /> ==Removing strings which are no longer used==<br /> <br /> From Moodle 2.8 onwards, strings can be deprecated in a way very similar to how functions are deprecated. This feature allows us to safely remove strings once we are reasonably sure they are no longer used. The process should help to remove unnecessary strings from the language packs, so translators do not waste valuable time translating them, while protecting us from accidentally removing a string that is still being used somewhere.<br /> <br /> == How it works ==<br /> <br /> There is a file with the list of deprecated strings. When a deprecated string is used (typically via the &lt;code&gt;get_string()&lt;/code&gt; call), a warning message is displayed, such as:<br /> <br /> String [identifier,component] is deprecated. Either you should no longer be using that string, <br /> or the string has been incorrectly deprecated, in which case you should report this as a bug. <br /> Please refer to https://docs.moodle.org/dev/String_deprecation<br /> <br /> Note that this warning is displayed at the DEBUG_DEVELOPER level only (which is what Moodle developers should have selected). See below for info on what to do if you see this message.<br /> <br /> === Why and when should a string be deprecated? ===<br /> <br /> The most common case is that you realize that a string is not used any more in standard Moodle code. You will probably search the whole moodle.git for the string identifier and the only relevant place found is the string definition itself. Even if it seems that the given string is not used any more in the standard Moodle code, it's possible that some additional (contributed) plugins still rely on it. This is typical for semantically general strings provided by the moodle.php (core) component such as &quot;Yes&quot;, &quot;Continue&quot;, &quot;Hidden&quot; etc.<br /> <br /> Beware that searching for the string identifier only may sometimes lead to false negatives. Imagine you have a suspicion that a hypothetical string &quot;actionloginremote&quot; is no longer used any more as there is no code that would actually use this stringid. However, there can be places like this:<br /> <br /> &lt;code php&gt;<br /> $action = optional_param('action', 'loginremote', PARAM_ALPHA);<br /> print_string('action'.$action);<br /> &lt;/code&gt;<br /> <br /> that are harder to detect. So, instead of simply removing the string &quot;actionloginremote&quot; you would put it to the list of deprecated strings.<br /> <br /> Another scenario may be that a semantically identical string was defined twice or it was put into the wrong component. If you think there may be places that rely on the wrong location (component), you should deprecate it. Copy the string to a new location (do not forget to use CPY instruction for AMOS to replay the change in all existing translations) and deprecate the old one.<br /> <br /> Also, it may turn out that some strings are only vaguely defined and do not have a clear and unique context / semantics. Ideally, Moodle code should use context-sensitive strings rather than rely on one general string covering all cases. Things like [http://en.wikipedia.org/wiki/Grammatical_gender grammatical gender] play an important role in many languages. For example, in Czech, &quot;a role&quot; or &quot;a question&quot; are of feminine gender and the correct translation of &quot;hidden&quot; in this case is &quot;skrytá&quot;, while &quot;a badge&quot; is of masculine gender and the correct translation is &quot;skrytý&quot;. So it would be better to have separate strings like &quot;hiddenrole&quot;, &quot;hiddenquestion&quot; and &quot;hiddenbadge&quot; even if they all read just &quot;Hidden&quot; in the English language pack. When you are about to split existing string into a couple of specific ones, you may wish to deprecate the general one at the end too (also, do not forget to use the CPY again).<br /> <br /> === When should a string be removed? ===<br /> <br /> There are situations where deprecation does not make sense. For example when a whole functionality is being removed, or a very specific string (such as error message) is no longer used by the code. If it is very unlikely that the string is not used by any other code, it can simply be removed without the full deprecation process.<br /> <br /> The same logic applies to cases when a very specific string is to be moved or renamed. In this situation, it is valid to just move it (together with the matching MOV instruction in the AMOScript).<br /> <br /> == How to deprecate a string ==<br /> <br /> * Strings can be deprecated and removed on master branch only.<br /> * Locate or create a file deprecated.txt either in ''lang/en/'' or ''componentfullpath/lang/en/''<br /> * Add a line &quot;identifier,fullcomponentname&quot; to the end of this file<br /> * Move the string inside the existing language file to the end of the file under the comment &quot;// Deprecated since Moodle X.Y&quot; (this comment will help removing deprecated strings later).<br /> * For final deprecation (2 major versions later), delete the string from both deprecated.txt and respective lang file.<br /> <br /> ''Note: when deprecating core string from lang/en/xxxx.php the fullcomponentname should be &quot;core_xxxx&quot;, except for lang/en/moodle.php that has fullcomponentname &quot;core&quot;''<br /> <br /> == What to do if you get a debugging message ==<br /> <br /> There are two possibilities. Either the code that uses the deprecated string must be fixed, or the string should not have been deprecated and must be removed from the list.<br /> <br /> Use the git-blame tool on the corresponding lang/en/deprecated.txt and find the commit/issue that deprecated the string. It should give you enough information to decide on the most appropriate action.<br /> <br /> * If you think the string was deprecated by mistake, create a new issue in the tracker to remove it from the list (on all supported branches, not only on master).<br /> * If the string was renamed or moved, you will probably want to fix the caller to use the new name/location of the string.<br /> * You may as well copy the string to your own plugin scope and make it context-specific.<br /> <br /> [https://github.com/moodle/moodle/blame/master/lang/en/deprecated.txt &lt;nowiki&gt;git blame lang/en/deprecated.txt&lt;/nowiki&gt;]<br /> [https://github.com/moodle/moodle/blame/master/mod/quiz/lang/en/deprecated.txt &lt;nowiki&gt;git blame mod/quiz/lang/en/deprecated.txt&lt;/nowiki&gt;]<br /> <br /> [[Category:Language]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Inbound_message_API&diff=47797 2015-05-06T05:55:36Z

<p>Ankitfrenz: /* Handlers */</p> <hr /> <div>{{Infobox Project<br /> |name = Inbound Message API<br /> |state = Complete<br /> |tracker = MDL-46282<br /> |discussion = https://moodle.org/mod/forum/discuss.php?d=269424<br /> |assignee = Andrew Nicols<br /> }}<br /> {{Moodle 2.8}}<br /> == Summary ==<br /> <br /> By encoding pieces of data within an e-mail address, it is possible to route a message within Moodle and to<br /> handle it accordingly. With the encoding of appropriate data within the e-mail address, it is also possible to perform<br /> some level of sender verification, and to store additional data to enable further routing.<br /> <br /> To ensure that the solution remains practical, a single incoming e-mail account is used, making use of the e-mail<br /> Subaddress extension defined in RFC 5233 (Sieve Email Filtering: Subaddress Extension). This RFC specifies that a the '+'<br /> symbol can be used to separate the mailbox from any additional subaddress data. For example, in the e-mail address<br /> `bob+moodle@example.com, the e-mail would be delivered to `bob@example.com` but the recipient would be able to filter<br /> mail based on the +moodle extension. This extension is referred to as the subaddress.<br /> <br /> The maximum length of the localpart of an e-mail address (including subadress) as defined in RFC 5232, is 64<br /> characters. The current maximum length of the subaddress component is 48 characters, with a further character used for<br /> the subaddress separator. This leaves space for 15 characters in the address component.<br /> <br /> == Benefits ==<br /> <br /> The main benefits of this kind of handling are the addition of new ways of interacting with Moodle for certain content:<br /> <br /> * the ability for users to reply to content received from Moodle; and<br /> * the ability to e-mail new content in to Moodle.<br /> <br /> This has other potential knock-on benefits for users who cannot use the Moodle mobile application, or to unusual<br /> scenarios where Internet access may be unusually limited. It also allows users to respond in a natural, and familiar environment which mirrors that of other systems.<br /> <br /> == Components ==<br /> <br /> The Inbound Message Handling system is broken down into several main components:<br /> <br /> # Address Management<br /> # Message Handling<br /> # Handler Management<br /> # Message retrieval system<br /> <br /> In order to preserve user-verification, each address used in the process must be unique to that user. Additionally,<br /> the message must identify how the message should be handled within Moodle.<br /> <br /> A handler is only passed a message following successful verification of that message and may decide how it will handle<br /> the message from that point on.<br /> <br /> Handlers may define certain characteristics of the message handling system including:<br /> # the extent of the verification which takes place; and<br /> # the default validity period.<br /> <br /> === Address Manager ===<br /> <br /> An address and routing manager exists to:<br /> # generate unique addresses;<br /> # process received messages, and extract the data stored within them;<br /> # validate addresses; and<br /> # verify sender authenticity.<br /> <br /> Both an encode, and a decode stage exist.<br /> <br /> Note: It is up to the developer to use the generated address in the correct fashion. Typically this will be as a 'reply-to' address when sending new messages.<br /> <br /> ==== Creating an e-mail address (Encode stage) ====<br /> <br /> When creating a new e-mail address, the following information is required:<br /> # the '''handler''' - the system which will handle any e-mail received to the generated address;<br /> # the '''data value''' - a single integer data which the received message relates to; and<br /> # the '''user id''' - the id of the user that a message relates to.<br /> <br /> A '''data key''' is generated for the supplied data value.<br /> <br /> In the following example, an e-mail address is generated when sending a new forum post notification to a user. This<br /> address is used in the reply-to field when sending the message, thereby allowing a user to reply to a post by e-mail.<br /> <br /> A new handler has been written for the forum &lt;code php&gt;\mod\forum\message\inbound\reply_handler&lt;/code&gt; which is aware of how it should handle any<br /> received information.<br /> The forum post notification will be sent to the user described by $recipient with a unique user id of &lt;code php&gt;$recipient-&gt;id&lt;/code&gt;.<br /> The forum post notification describes a new post described by $post and with a unique post id of &lt;code php&gt;$post-&gt;id&lt;/code&gt;.<br /> <br /> <br /> &lt;code php&gt;<br /> // Create a new instance of the address manager.<br /> $generator = new \core\message\inbound\address_manager();<br /> <br /> // Specify the handler which will process any incoming messages for the generated address.<br /> $generator-&gt;set_handler('\mod\forum\message\inbound\reply_hander');<br /> <br /> // Specify the post that is being replied to.<br /> $generator-&gt;set_data($post-&gt;id);<br /> <br /> // Generate an e-mail address to use for the reply-to, unique to this recipient.<br /> $replyaddress = $generator-&gt;generate($recipient-&gt;id);<br /> <br /> $eventdata = new stdClass();<br /> $eventdata-&gt;component = 'mod_forum';<br /> $eventdata-&gt;name = 'posts';<br /> $eventdata-&gt;userfrom = $userfrom;<br /> $eventdata-&gt;userto = $userto;<br /> $eventdata-&gt;subject = $postsubject;<br /> $eventdata-&gt;fullmessage = $posttext;<br /> $eventdata-&gt;fullmessageformat = FORMAT_PLAIN;<br /> $eventdata-&gt;fullmessagehtml = $posthtml;<br /> $eventdata-&gt;notification = 1;<br /> $eventdata-&gt;replyto = $replyaddress;<br /> &lt;/code&gt;<br /> <br /> The e-mail address generated will be of the nature:<br /> &lt;pre&gt;<br /> incoming+AAAAFXrQKf8AA3QP92///wABUl2Ukn//uCbIXwoNLnXy94kV@example.com<br /> &lt;/pre&gt;<br /> <br /> ==== Parsing an e-mail address (Decode and validation stage) ====<br /> <br /> When an e-mail is received, the 'To' address field is parsed to determine the way in which the e-mail should be<br /> processed.<br /> <br /> The following example address can be parsed to determine the sender, the handler, and the item of data to which the<br /> message refers. Note that this has been implemented as core functionality and developers are not expected to need to implement this section themselves.<br /> &lt;pre&gt;<br /> incoming+AAAAFXrQKf8AA3QP92///wABUl2Ukn//uCbIXwoNLnXy94kV@example.com<br /> &lt;/pre&gt;<br /> <br /> &lt;pre&gt;<br /> // The message was sent by bob to the incoming mailbox:<br /> $recipient = 'incoming+AAAAFXrQKf8AA3QP92///wABUl2Ukn//uCbIXwoNLnXy94kV@example.com';<br /> $sender = 'bob@example.com';<br /> <br /> // Create a new instance of the address manager.<br /> $parser = new \core\message\inbound\address_manager();<br /> <br /> // First parse the envelope data.<br /> $result = $parser-&gt;process_envelope($recipient, $sender);<br /> <br /> // We can check that the data validation passed.<br /> if ($result !== \core\message\inbound\address::VALIDATION_SUCCESS) {<br /> echo &quot;Some part of the data could not be verified\n&quot;;<br /> } else {<br /> // We can retrieve the data stored in the message.<br /> $data = $result-&gt;get_data();<br /> <br /> // Get the instance of the handler - this will be the \mod_forum\message\inbound\reply_hander used to define the message originally.<br /> $data-&gt;get_handler();<br /> <br /> // The user key is the user record of the user who the original message was sent to.<br /> $data-&gt;user;<br /> <br /> // The datavalue is the integer value that was specified when the message was originally sent.<br /> $data-&gt;datavalue;<br /> }<br /> &lt;/pre&gt;<br /> <br /> === Handlers ===<br /> <br /> Once a message has been processed by the address manager, it is passed to the handler specified in the address data.<br /> <br /> Each Handler belongs to a specific component, and comprises of a class extending \core\message\inbound\handler, which specifies a<br /> function to handle any received e-mail messages.<br /> <br /> ==== Creating a new Handler ====<br /> <br /> To create a new handler, you must:<br /> # create a class extending the handler class; and<br /> # specify it's default values in that component's db/messageinbound_handlers.php file.<br /> <br /> Each new handler must have a unique class name within Moodle and must be loadable using the Moodle class autoloader.<br /> <br /> As an example, to create a forum post reply handler called reply_handler:<br /> <br /> {|<br /> ! scope=&quot;row&quot; | Component Name<br /> | mod_forum<br /> |-<br /> ! scope=&quot;row&quot; | Handler Name<br /> | reply_handler<br /> |-<br /> ! scope=&quot;row&quot; | Namespace<br /> | mod_forum\message\inbound<br /> |-<br /> ! scope=&quot;row&quot; | Class Name<br /> | mod_forum\message\inbound\reply_handler<br /> |}<br /> <br /> In mod/forum/db/messageinbound_handlers.php, define the available handlers.<br /> <br /> &lt;code php&gt;<br /> &lt;?php<br /> <br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> $handlers = array(<br /> array(<br /> 'classname' =&gt; '\mod_forum\message\inbound\reply_handler',<br /> 'enabled' =&gt; false,<br /> 'validateaddress' =&gt; true,<br /> ),<br /> );<br /> &lt;/code&gt;<br /> And define the handler itself in /mod/forum/classes/message/inbound/reply_handler.php:<br /> &lt;code php&gt;<br /> &lt;?php<br /> <br /> namespace mod_forum\message\inbound;<br /> <br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> class reply_handler extends \core\message\inbound\handler {<br /> // Place the content of the handler here.<br /> }<br /> &lt;/code&gt;<br /> <br /> A handler class must define three abstract functions:<br /> # get_name() - Typically a string returned by get_string() to display as a name in the admin interface;<br /> # get_description() - Typically a string returned by get_string() to display in the admin interface; and<br /> # process_message() - The function called after successful validation of a message, which takes information including the recipient, sender, headers, body, and a list of attachments.<br /> <br /> It may optionally define some additional functions:<br /> # allow_validateaddress_change() - To prevent an Moodle administrator from changing whether E-mail address validation is required. Typically this is used to '''force''' sender validation.<br /> # allow_enabled_change() - To prevent a Moodle administrator from enabling, or disabling the handler<br /> <br /> A new handler must also be defined within the component in lib/db/messageinbound_handlers.php. This array of handlers<br /> includes the default settings for the handler used at creation time.<br /> <br /> ==== Removing quoted text from email messages ====<br /> If you want the quoted text to be removed from email messages you can call the method remove_quoted_text from inside your handler as below:-<br /> &lt;code php&gt;<br /> list ($message, $format) = self::remove_quoted_text($messagedata);<br /> &lt;/code&gt;<br /> <br /> The method will make an educated guess and remove quoted text from the message and return the format and message contents. This method doesn't work perfectly at the moment and MDL-50058 is supposed to improve this.<br /> <br /> == Validation and Verification ==<br /> <br /> The Inbound Message system performs a step of both validation, and verification.<br /> <br /> Note: E-mail is never a secure method of communication, and it is easy to `spoof` the `sender` field when sending an<br /> e-mail very easily. As a result, administrators should be fully aware of the consequences when enabling any Inbound Message<br /> handler.<br /> <br /> When an address is generated, it will be composed of a base64-encoded binary set containing:<br /> [handlerid][userid][datavalue][verifiationstring]<br /> <br /> # the handlerid is the database ID of the handler used to process the message;<br /> # the userid is the database ID of the user associated with the message;<br /> # the datavalue is an integer value associated with the message; and<br /> # the verifiationstring is part of an md5 hash of a user key, and data key.<br /> <br /> A new key will be generated for each individual user. This is unique to the user.<br /> A new key will be generated for each piece of data for a handler. This is unique to the handler and datavalue combination.<br /> <br /> The keys generated for both the user, and for the handler-data pair are never exposed in the string and are always<br /> verified. The userid specified in the address must match the key stored for that user in Moodle; and similarly the<br /> datavalue specified in the address must match the key stored for the handler-pair in moodle.<br /> <br /> This combination of three pieces of plain-text information, with two pieces of hidden additional information should<br /> make it harder for any potential attacks.<br /> <br /> Additionally, an administrator can choose whether to compare the e-mail address of the sender against the e-mail address<br /> held against a user record. This is enabled by default, but can be disabled by an administrator.<br /> <br /> As a further protection, it is possible to specify an expiry timestamp for each handler-datavalue keypair.<br /> <br /> === Potential attack vectors ===<br /> <br /> Several potential attack vectors exist, and handler authors should determine the optimum solution required. At the very<br /> least, it is advisable to recommend sender address comparison, but this is not foolproof on it's own.<br /> <br /> As an additional prevention method, the handler could define a further e-mail based verification check whereby on<br /> reception of an inboune e-mail, the handler system would:<br /> # store the retrieved message (park it);<br /> # send a new e-mail to the user described in $user containing a link or a further reply message; and<br /> # await for approval from the e-mail.<br /> <br /> ==== Spoofed e-mail address ====<br /> <br /> As mentioned above, it is incredibly easy to spoof the Sender field in an e-mail. If the full address is captured<br /> by an attacker, then it would be possible to send e-mail as that user and the Inbound Message system would be unable to distinguish<br /> the message from a valid address.<br /> <br /> ==== Mitigations =====<br /> <br /> ===== Prevention =====<br /> <br /> # When creating keys, specify an appropriate expiry time for that key pair<br /> # When sending e-mail within Moodle, only use the Reply-To field as this is not typically exposed when a message is forwarded to a third-party<br /> # Provide information to users advising against forwarding of e-mail<br /> <br /> ===== Damage Control =====<br /> <br /> # Expire any affected keys<br /> <br /> ==== Brute force attack of e-mail accounts ====<br /> <br /> As with any system of this nature (including passwords), it is possible to apply a brute force attack. It would be<br /> possible to reverse engineer the e-mail address for a known user, and then recompile it with a range of combinations.<br /> <br /> With the proposed length of the verification has (24 characters), this provides for<br /> 79,228,162,514,264,337,593,543,950,336 combinations of hash.<br /> <br /> ===== Prevention =====<br /> <br /> # When creating data keys, specify an appropriate expiry time for that key pair<br /> <br /> ===== Damage Control =====<br /> <br /> # Expire any affected keys<br /> <br /> ===== Other notes =====<br /> <br /> It is difficult to increase the length of the verification hash. At present the hash is 24 characters which makes the<br /> maximum length of the subaddress 48 characters, leaving space for 15 characters in the mailbox part of the address.<br /> Although it would be possible to increase the length of an address, doing so would invalidate all previously used<br /> addresses.<br /> <br /> <br /> [[File:verp-prototype-screen-examples.png]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Message_API&diff=47789 2015-05-06T04:59:40Z

<p>Ankitfrenz: /* How to send a message */</p> <hr /> <div>==What is this document?==<br /> <br /> This document describes how to make use of the Moodle Messaging API to send messages to Moodle users.<br /> <br /> If you are after a general introduction on using the Moodle Messaging system go to [[:en:Messaging|messaging user documentation]].<br /> <br /> If you are looking for details of how the Messaging system's internal structure was implemented, go to [[Messaging 2.0]].<br /> <br /> If you are looking for instructions on the implementation of a custom message processor (a component that receives messages sent to a user), go to [[Messaging custom components]].<br /> <br /> If you are looking for instructions on sending messages programatically within Moodle then read on...<br /> <br /> ==Overview==<br /> <br /> Moodle components have the ability to send messages to users via the Moodle messaging system. Any type of component, for example a plugin or block, can register as a message producer then send messages to users.<br /> <br /> ==File locations==<br /> <br /> The Message API code is contained within lib/messagelib.php and is automatically included for you during page setup.<br /> <br /> ==Functions==<br /> <br /> message_send() is the primary point of contact for the message API. Call it to send a message to a user. You can find a full description of the arguments that must be supplied at (link to phpdocs). There is also an example below.<br /> <br /> ==Message popup==<br /> {{Moodle_2.9}}<br /> A Javascript popup can be displayed through a link to invite a user to message another. In order to use this feature, you need to require the Javascript libraries using ''message_messenger_requirejs()'' and create a link with the attributes returned by ''message_messenger_sendmessage_link_params()''. More in the examples.<br /> <br /> ==Examples==<br /> <br /> ===How to register as a message producer===<br /> <br /> The messages produced by a message provider is defined in the /db/messages.php file of a component. Below is code from the quiz module's messages.php file, shown as an example.<br /> &lt;code php&gt;<br /> defined('MOODLE_INTERNAL') || die();<br /> $messageproviders = array (<br /> // Notify teacher that a student has submitted a quiz attempt<br /> 'submission' =&gt; array (<br /> 'capability' =&gt; 'mod/quiz:emailnotifysubmission'<br /> ),<br /> // Confirm a student's quiz attempt<br /> 'confirmation' =&gt; array (<br /> 'capability' =&gt; 'mod/quiz:emailconfirmsubmission'<br /> )<br /> );<br /> &lt;/code&gt;<br /> <br /> The quiz can send two kinds of messages, quiz &quot;submission&quot; and &quot;confirmation&quot; notifications. Each message type is only available to users with the appropriate capability. Please note that the capability is checked at the system level context. Users who have this capability will have this message listed in their messaging preferences. You can omit the capability section if your message should be visible for all users. For example forum post notifications are available to all users.<br /> <br /> &lt;code php&gt;<br /> $messageproviders = array (<br /> // Ordinary single forum posts<br /> 'posts' =&gt; array (<br /> )<br /> );<br /> &lt;/code&gt;<br /> <br /> When displaying your message types in a user's messaging preferences it will use a string from your component's language file called &quot;messageprovider:messagename&quot;. For example here are the relevant strings from the quiz's language file.<br /> &lt;code php&gt;<br /> $string['messageprovider:confirmation'] = 'Confirmation of your own quiz submissions';<br /> $string['messageprovider:submission'] = 'Notification of quiz submissions';<br /> &lt;/code&gt;<br /> <br /> Once your messages.php is complete you need to increase the version number of your component in its version.php. That will cause Moodle to check messages.php looking for new or changed message definitions. Log in as an admin and go to /admin/index.php (the Notifications page) to start the upgrade process.<br /> <br /> ===How to send a message===<br /> {{Moodle_2.9}}<br /> Here is example code showing you how to actually send a message. The example shows the construction of a object with specific properties, which is then passed to the message_send() function that uses the information to send a message.<br /> &lt;code php&gt;<br /> $message = new \core\message\message();<br /> $message-&gt;component = 'moodle';<br /> $message-&gt;name = 'instantmessage';<br /> $message-&gt;userfrom = $USER;<br /> $message-&gt;userto = $user;<br /> $message-&gt;subject = 'message subject 1';<br /> $message-&gt;fullmessage = 'message body';<br /> $message-&gt;fullmessageformat = FORMAT_MARKDOWN;<br /> $message-&gt;fullmessagehtml = '&lt;p&gt;message body&lt;/p&gt;';<br /> $message-&gt;smallmessage = 'small message';<br /> $message-&gt;notification = '0';<br /> $message-&gt;contexturl = 'http://GalaxyFarFarAway.com';<br /> $message-&gt;contexturlname = 'Context name';<br /> $message-&gt;replyto = &quot;random@example.com&quot;;<br /> $content = array('*' =&gt; array('header' =&gt; ' test ', 'footer' =&gt; ' test ')); // Extra content for specific processor<br /> $message-&gt;set_additional_content('email', $content);<br /> <br /> // Create a file instance.<br /> $usercontext = context_user::instance($user-&gt;id);<br /> $file = new stdClass;<br /> $file-&gt;contextid = $usercontext-&gt;id;<br /> $file-&gt;component = 'user';<br /> $file-&gt;filearea = 'private';<br /> $file-&gt;itemid = 0;<br /> $file-&gt;filepath = '/';<br /> $file-&gt;filename = '1.txt';<br /> $file-&gt;source = 'test';<br /> <br /> $fs = get_file_storage();<br /> $file = $fs-&gt;create_file_from_string($file, 'file1 content');<br /> $message-&gt;attachment = $file;<br /> <br /> $messageid = message_send($message);<br /> &lt;/code&gt;<br /> <br /> Before 2.9 message data used to be a stdClass object as shown below:-<br /> <br /> &lt;code php&gt;<br /> $message = new stdClass();<br /> $message-&gt;component = 'mod_quiz'; //your component name<br /> $message-&gt;name = 'submission'; //this is the message name from messages.php<br /> $message-&gt;userfrom = $USER;<br /> $message-&gt;userto = $touser;<br /> $message-&gt;subject = $subject;<br /> $message-&gt;fullmessage = $message;<br /> $message-&gt;fullmessageformat = FORMAT_PLAIN;<br /> $message-&gt;fullmessagehtml = '';<br /> $message-&gt;smallmessage = '';<br /> $message-&gt;notification = 1; //this is only set to 0 for personal messages between users<br /> message_send($message);<br /> &lt;/code&gt;<br /> <br /> ===How to set-up the message popup===<br /> <br /> Here is example code showing you how to set-up the Javascript popup link.<br /> &lt;code php&gt;<br /> require_once('message/lib.php');<br /> $userid = 2;<br /> $userto = $DB-&gt;get_record('user', array('id' =&gt; $userid));<br /> <br /> message_messenger_requirejs();<br /> $url = new moodle_url('message/index.php', array('id' =&gt; $userto-&gt;id));<br /> $attributes = message_messenger_sendmessage_link_params($userto);<br /> echo html_writer::link($url, 'Send a message', $attributes);<br /> &lt;/code&gt;<br /> <br /> ==See also==<br /> * [[Core APIs]]<br /> <br /> [[Category:API]]<br /> [[Category:Tutorial]]<br /> [[Category:Plugins]]<br /> [[Category:Messaging]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Moodle_2.9_release_notes&diff=47576 2015-04-13T05:37:42Z

<p>Ankitfrenz: /* For developers */</p> <hr /> <div>&lt;p class=&quot;note&quot;&gt;'''Note:''' This page is a work-in-progress. Please use the [[{{TALKPAGENAME}}|page comments]] for suggested improvements.&lt;/p&gt;<br /> <br /> [[Releases]] &gt; {{FULLPAGENAME}}<br /> <br /> Release date: Not yet released, expected on Monday, 11th May 2015<br /> <br /> Here is [https://tracker.moodle.org/secure/IssueNavigator!executeAdvanced.jspa?jqlQuery=project+%3D+mdl+AND+resolution+%3D+fixed+AND+fixVersion+in+%28%222.9%22%29+ORDER+BY+priority+DESC&amp;runQuery=true&amp;clear=true the full list of fixed issues in 2.9].<br /> <br /> ==Server requirements==<br /> <br /> These are just the minimum supported versions. We recommend keeping all of your software up-to-date.<br /> <br /> * Moodle upgrade: Moodle 2.2 or later (if upgrading from earlier versions, you must upgrade to 2.2.11 as a first step)<br /> * Minimum PHP version: PHP 5.4.4 (always use latest PHP 5.4.x or 5.5.x on Windows - http://windows.php.net/download/)<br /> * Ghostscript should be installed for pdf annotation.<br /> <br /> === Database requirements ===<br /> <br /> Moodle supports the following database servers. Again, version numbers are just the minimum supported version. We recommend running the latest stable version of any software.<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Database<br /> ! Minimum version<br /> ! Recommended<br /> |-<br /> | [http://www.postgresql.org/ PostgreSQL]<br /> | 9.1<br /> | Latest<br /> |-<br /> | [http://www.mysql.com/ MySQL]<br /> | 5.5.31<br /> | Latest<br /> |-<br /> | [https://mariadb.org/ MariaDB]<br /> | 5.5.31<br /> | Latest<br /> |-<br /> | [http://www.microsoft.com/en-us/server-cloud/products/sql-server/ Microsoft SQL Server]<br /> | 2008<br /> | Latest<br /> |-<br /> | [http://www.oracle.com/us/products/database/overview/index.html Oracle Database]<br /> | 10.2<br /> | Latest<br /> |}<br /> <br /> ==Client requirements==<br /> <br /> === Browser support ===<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Browser<br /> ! Minimum version<br /> ! Recommended version<br /> ! Notes<br /> |-<br /> | [https://www.google.com/intl/en_au/chrome/browser/ Google Chrome]<br /> | 30.0<br /> | Latest<br /> |<br /> |-<br /> | [http://www.mozilla.org/en-US/ Mozilla Firefox]<br /> | 25.0<br /> | Latest<br /> |<br /> |-<br /> | [http://www.apple.com/safari/ Apple Safari]<br /> | 6<br /> | Latest<br /> |<br /> |-<br /> | [http://windows.microsoft.com/en-AU/internet-explorer/download-ie Microsoft Internet Explorer]<br /> | 9<br /> | Latest<br /> | Version 10 is required for drag-and-drop upload of content from outside the browser into Moodle<br /> |}<br /> <br /> ==Major features==<br /> <br /> ===Navigation improvements===<br /> <br /> One of the biggest project was improvements in Navigation and Users pages, see also MDL-45774. It includes:<br /> <br /> * My grades page listing all my courses, and all courses I am teaching in one place (linked from User Menu) MDL-45894, MDL-49634<br /> * My Home is now My Dashboard MDL-48936<br /> * Redesign “My profile”, make it pluggable MDL-48932, MDL-45898<br /> * New “My preferences” page (linked from User Menu) MDL-45895<br /> * Consistent header for user pages MDL-45896<br /> * Consistent header for user sub pages MDL-48931<br /> * Consistent bread crumbs for user pages MDL-48935<br /> * Remove redundant nodes from nav tree MDL-49635<br /> <br /> ===User interface improvements===<br /> <br /> * MDL-43996 - Drag and drop image into Atto editor inserts it as a file <br /> * MDL-19670 - Teacher can post the same forum question to all groups at once <br /> * MDL-47172 - “You have assignments that need attention” displays relevant information for teachers <br /> * MDL-48933 - Ajax interface for messaging a user <br /> * MDL-25721 - Sort by age when viewing question banks <br /> * MDL-23296 - Provide search function for Server Files area in File Picker<br /> * MDL-48937 - Don't show the category in the breadcrumb if there is only one category<br /> * MDL-49694 - Overview report shows the full course name<br /> * MDL-47527 - Allow access to overview report for users who can view all grades<br /> <br /> ===Course creation improvements===<br /> <br /> * MDL-10405 - Added button to quickly delete the whole course section <br /> * MDL-31500 - Allow backup and restore on the front page<br /> * MDL-5583 - Fields in database module can be set as required <br /> * MDL-28526 - Glossary can export/import embedded images and attached files <br /> * MDL-49006, MDL-49101 - Removed default requirement of activity description and substituted with a single setting<br /> * MDL-13831 - Grade to pass can be set by editing activity without going to gradebook <br /> * MDL-27074 - Display group name for group events in the calendar<br /> * MDL-48969 - New generic block: activity results<br /> * MDL-18177 - Add option to choose whether groups and/or groupings are includedin a back up<br /> * MDL-20053 - Database: create ##userpicture## tag to allow the user's profile picture to be displayed<br /> * MDL-49543 - Add a WYSIWYG field to Badges which is displayed on the Criteria page<br /> * MDL-46416 - Possible to change / remove picture from group<br /> * MDL-49687 - Adding a single person to multiple groups at the same time<br /> * MDL-21724 - The course edit page needs a way to redirect to some page other than the main course page after saving<br /> <br /> ===Administrator features===<br /> <br /> * MDL-15187 - Assign global roles using CSV upload<br /> * MDL-30937 - Backup report again links to the individual course backup summaries<br /> * MDL-32547 - Configure temporary file deletion, to avoid moodledata/temp/backup filling up the filesystem<br /> * MDL-49684 - Replace custom Moodle timezone stuff with standard PHP date/time code<br /> * MDL-25763 - CLI version of admin/replace.php<br /> * MDL-44874 - Per-request temp directories<br /> * MDL-46064 - Drop support for MyISAM<br /> * MDL-49298 - Make tgz backups standard<br /> * MDL-47834 - New option for restriction of concurrent logins<br /> * MDL-47800 - Logout user when somebody changes their password<br /> * MDL-47830 - Add password rotation restrictions<br /> * MDL-48559 - Web CRON should be disabled by default<br /> * MDL-48080 - Never send mail to domains ending in .invalid<br /> * MDL-48595 - Log exports no longer fails because of memory limit<br /> * MDL-28513 - Allow specification of admin user email in CLI installer<br /> * MDL-47803 - New page that shows all browser sessions of current user<br /> * MDL-34684 - New health check to detect incorrect category path order and/or missing parent categories<br /> * MDL-48493 - Automatically detect the plugin type when installing from ZIP<br /> * MDL-48894 - Registration page should state if site is registered<br /> <br /> ===Files and repositories===<br /> <br /> * MDL-42616 - Files: Support custom file types<br /> * MDL-43752 - S3 repository works for non-US repositories<br /> <br /> ===Authentication, enrolments and access===<br /> <br /> * Several improvements to meta enrolments, such as: populate groups from courses MDL-17929, sorting courses alphabetically MDL-35696, button to quickly add a new method MDL-49439<br /> * MDL-26017 - Keyholder capability in self-enrolment plugin<br /> * MDL-20365 - Salted Crypt passwords option for external database authentication<br /> * MDL-49380 - Chose &quot;Create new group&quot; when synchronising cohort enrolment with a group<br /> * MDL-49677 - Improvement of Custom welcome message in self-enrolment plugin<br /> * MDL-43415 - Custom profile fields should be syncable with external DB auth<br /> <br /> ===Quiz===<br /> <br /> * MDL-348 - Printer-friendly option for quizzes <br /> * MDL-40988 - Add section headings to quiz<br /> * MDL-40992 - Option for teachers to allow students to redo a finished question within a quiz attempt<br /> * MDL-35280 - quiz_reset_userdata does not have an option to remove user/group overrides<br /> * MDL-48898 - Quiz time period setting should use admin_setting_configduration<br /> * MDL-6340 - force unique/unseen questions in retakes<br /> * MDL-40990 - Teachers can require students to complete Question 1 before they can see Question 2<br /> <br /> ===Lesson===<br /> <br /> * MDL-48803 - support for groups <br /> * MDL-48715 - moving “time spent” from prerequisite to the proper completion rule <br /> * MDL-43387 - UI for grading essays <br /> * MDL-48244 - Lessons with no questions show completed after the first page is viewed<br /> * MDL-47587 - Make progress bar available on the very last page of a lesson.<br /> * MDL-49642 - Give time/date extensions to users and groups in lesson<br /> * MDL-40286 - non-editing teacher should see Grade analysis in Lesson<br /> * MDL-48473 - Lesson shortanswer question: add fill in the blank option<br /> * MDL-48984 - Lesson content page jump descriptions, numerical and shortanswer questions answers allow rich html but should be plain text<br /> * MDL-18553 - Removing grade info from lesson pages if lesson grade is 0<br /> * MDL-26689 - in order to prevent interactivity references from being broken move the &quot;Dependent on&quot; feature to the completion/availability subsystem<br /> <br /> ===Other things===<br /> <br /> * MDL-46728 - WOFF2 fonts are supported in themes.<br /> * MDL-48221 - Make forum subscription combinations less confusing with different combinations<br /> * MDL-47777 - Convert assignment maximum files per submission maximum to global setting<br /> * MDL-26226 - Moodle2 nav menu Topic Items should be links to Topic menu<br /> * MDL-47159 - atto_link should add 'http://' prefix when necessary<br /> * MDL-46763 - Save user images as JPEG if uploaded in that format.<br /> * MDL-47104 - Make 'calendar_lookahead' setting more flexible<br /> * MDL-48760 - Update mathjax to 2.5 when it's released<br /> * MDL-36009 - Gradebook table uses complex tables that are not accessible<br /> * MDL-48266 - Automated backup setting page needs additional validation<br /> * MDL-47562 - UI Fixes and improvements for Singleview<br /> * MDL-47232 - Course completion: &quot;activities to be completed&quot; improperly requires passing grade<br /> * MDL-48437 - Make Visible/All groups selector show own groups first<br /> * MDL-47501 - Add an indication that the grade letters was overridden<br /> * MDL-9443 - Run *.xhtml file through the text filters.<br /> * MDL-46662 - Accessibility improvements for gradereport course header and aggregation controls.<br /> * MDL-45848 - Cannot assign Marker on a marking guide or rubric assignment without giving a grade<br /> * MDL-48822 - Find last visual post in a discussion<br /> * MDL-48482 - Duration admin setting doesn't have a label associated to it<br /> * MDL-47915 - Two inconsistent layout files should be consistent, use id=page-content rather than content<br /> * MDL-47628 - Availability: Grouping confusing for sites which used groupmembersonly [2.8]<br /> * MDL-48212 - Forum reply by email puts reply instructions in messages for all handlers<br /> * MDL-48616 - Macrons for Atto character map<br /> * MDL-46755 - Allow teachers to configure the number of discussions displayed using the social course format<br /> * MDL-46665 - Add 'idnumber' field to user filter<br /> * MDL-49220 - Allow preview of Choice options before activity is opened for submission<br /> * MDL-40864 - Tidy up Bootstrapbase / Clean / More home links<br /> * MDL-38663 - Remove navbar and login info from forgot_password.php<br /> * MDL-34375 - Choice module lacks print_overview callback and does not appear on the MyMoodle Page<br /> * MDL-18183 - XMLRPC in MNET does not verify SSL peers by default<br /> * MDL-43770 - Exclude inactive users' responses from Choice report (with an option to include)<br /> * MDL-48499 - Show which users have not received messages in bulk messaging<br /> * MDL-32285 - Added &quot;Continue&quot; button under Error notification message (IMS CP)<br /> * MDL-46960 - Results returned from external tool activities don't update completion status<br /> * MDL-49333 - Return additional information in core_get_site_info<br /> * MDL-49262 - Delete the yui versions of the bootstrap plugins<br /> * MDL-49052 - Incorrect headings for upcoming events pages<br /> * MDL-49638 - reCAPTCHA should be moved below custom profile fields during self registration<br /> * MDL-49730 - Workshop: use full page width when displaying contents<br /> * MDL-48159 - Prevent submissions instead of using &quot;Default team&quot; in group assignments.<br /> * MDL-49563 - Allow glossary entry to be updated from glossary navigation<br /> * MDL-46238 - Add a simple way to go back from enrol/users.php page to the course<br /> * MDL-47434 - Section 'General' in navigation block<br /> * MDL-36874 - Text navigation for Books<br /> * MDL-49650 - Add a tool to browse templates in the current theme.<br /> * MDL-23178 - Allow indenting again for activities in the Main Menu block<br /> * MDL-49069 - Ability to specify default values for Forum RSS<br /> * MDL-48160 - Improve all block region layouts when coded for RTL<br /> <br /> ==Security issues==<br /> <br /> A number of security related issues were resolved. Details of these issues will be released after a period of approximately one week to allow system administrators to safely update to the latest version.<br /> <br /> ==For developers==<br /> <br /> * Support for Asynchronous Module Definition formatted javascript modules MDL-49046<br /> * Support for calling webservice functions directly from javascript MDL-49163<br /> * Support for implementing renderers as mustache templates (php and javascript) MDL-49152<br /> * Behat tests can run in parallel - MDL-39752 (backported)<br /> * A new per-request directory API has been added MDL-44874, and should be used instead of make_temp_directory wherever possible.<br /> * Support for in browser caching (localstorage) of strings and templates MDL-49604<br /> * Template Library - tool for displaying templates in the current theme MDL-49650<br /> * Use PHP native timezones support MDL-49684<br /> * New auth hook to intercept code before login page is shown. MDL-48887<br /> * MDL-49101 - Single setting for the activity description requirement<br /> * MDL-48177 - Allow plugin environment checks to work without defining explicit versions of Moodle<br /> * MDL-48887 - Add new auth pre_loginpage_hook() (save redirects, implement autologins...)<br /> * MDL-39752 - Behat tests runs in parallel<br /> * MDL-49163 - Unified Ajax script handler<br /> * MDL-49152 - Templates for renderers<br /> * MDL-27548 - The comments table contains the component<br /> * MDL-49269 - Add an AMD log module<br /> * MDL-49534 - Delete pear/HTTP/WebDav<br /> * MDL-48212 - Introduces a new class \core\message\message that should be used instead of \stdClass for creating messages.<br /> * MDL-37477 - html_table API supports caption tag<br /> * MDL-49643 - Deprecate inconsistent API to extend the navigation by local plugins<br /> * MDL-49361 - Ability to provide alternate strings manager<br /> * MDL-44642 - Implemented backend to keep session alive <br /> * MDL-45725 - User preferences for flexible tables can be set persistent across sessions<br /> <br /> [[Category:Release notes]]<br /> [[Category:Moodle 2.9]]<br /> <br /> [[fr:Notes de mise à jour de Moodle 2.9]]<br /> [[es:Notas de Moodle 2.9]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=SCORM_reports&diff=46601 2014-10-28T01:38:19Z

<p>Ankitfrenz: /* Naming Conventions */</p> <hr /> <div>{{Moodle 2.2}}<br /> == Introduction ==<br /> SCORM reports were converted to a pluggable architecture as of MOODLE 2.2. The original documentation of the project can be found at [https://docs.moodle.org/dev/SCORM_reporting_improvements SCORM Reporting Improvements]. Scorm Reports define a way for developer to develop reports of their own for the scorm module. The rest of this page deals with the details of how to develop such a report.<br /> == Template ==<br /> Here is a basic template for scorm report plugin on [https://github.com/ankitagarwal/scorm_report_template Github]<br /> == File structure ==<br /> Each plugin is allowed to have following files and folders:<br /> <br /> === Mandatory Files ===<br /> * classes/report.php<br /> * lang/xx/scormreport_pluginname.php<br /> <br /> === Other Optional Files ===<br /> * Version.php<br /> * db/install.php<br /> * db/install.xml<br /> * db/upgrade.php<br /> * db/access.php<br /> Please refer [[Upgrade API]] and [[Access API]] to understand the working of above files.<br /> <br /> As you might have noticed the file structure for scorm report plugin is similar to any other standard plugin in Moodle. The only differences are:-<br /> * There must be a file classes/report.php implementing class \scormreport_yourreport\report that must extend the default reporting class &quot;\mod_scorm\report&quot; and the extended class must implement the method &quot;display($scorm, $cm, $course, $download)&quot;, which should handle the core reporting feature.<br /> * The lang file is not optional. That is, each plugin must define the string &quot;pluginname&quot; in the lang files.<br /> <br /> == Naming Conventions ==<br /> Following Naming conventions should be kept in mind while writing a scorm report plugin:-<br /> * Folder name should be same as pluginname<br /> * Name of the extended class should be in format \scormreport_myreport\report<br /> * \scormreport_myreport\report must implement the function<br /> &lt;code php&gt;<br /> function display($scorm, $cm, $course, $download) {}<br /> &lt;/code&gt;<br /> * Each plugin must define the string &quot;pluginname&quot; in the language files.<br /> <br /> == See Also ==<br /> [https://docs.moodle.org/dev/SCORM_reporting_improvements SCORM Reporting Improvements] Original GSOC 2011 Project Documentation<br /> === User Docs ===<br /> [https://docs.moodle.org/en/Using_SCORM Using SCORM]<br /> <br /> [https://docs.moodle.org/en/SCORM_FAQ SCORM FAQ]<br /> <br /> [https://docs.moodle.org/en/SCORM_module SCORM Module]<br /> <br /> [[Category:Tutorial]]<br /> [[Category:Plugins]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=SCORM_reports&diff=46600 2014-10-28T01:37:08Z

<p>Ankitfrenz: /* Other Optional Files */</p> <hr /> <div>{{Moodle 2.2}}<br /> == Introduction ==<br /> SCORM reports were converted to a pluggable architecture as of MOODLE 2.2. The original documentation of the project can be found at [https://docs.moodle.org/dev/SCORM_reporting_improvements SCORM Reporting Improvements]. Scorm Reports define a way for developer to develop reports of their own for the scorm module. The rest of this page deals with the details of how to develop such a report.<br /> == Template ==<br /> Here is a basic template for scorm report plugin on [https://github.com/ankitagarwal/scorm_report_template Github]<br /> == File structure ==<br /> Each plugin is allowed to have following files and folders:<br /> <br /> === Mandatory Files ===<br /> * classes/report.php<br /> * lang/xx/scormreport_pluginname.php<br /> <br /> === Other Optional Files ===<br /> * Version.php<br /> * db/install.php<br /> * db/install.xml<br /> * db/upgrade.php<br /> * db/access.php<br /> Please refer [[Upgrade API]] and [[Access API]] to understand the working of above files.<br /> <br /> As you might have noticed the file structure for scorm report plugin is similar to any other standard plugin in Moodle. The only differences are:-<br /> * There must be a file classes/report.php implementing class \scormreport_yourreport\report that must extend the default reporting class &quot;\mod_scorm\report&quot; and the extended class must implement the method &quot;display($scorm, $cm, $course, $download)&quot;, which should handle the core reporting feature.<br /> * The lang file is not optional. That is, each plugin must define the string &quot;pluginname&quot; in the lang files.<br /> <br /> == Naming Conventions ==<br /> Following Naming conventions should be kept in mind while writing a scorm report plugin:-<br /> * Folder name should be same as pluginname<br /> * Name of the extended class should be scorm_pluginname_report<br /> * scorm_pluginname_report must implement the function<br /> &lt;code php&gt;<br /> function display($scorm, $cm, $course, $download) {}<br /> &lt;/code&gt;<br /> * Each plugin must define the string &quot;pluginname&quot; in the language files.<br /> == See Also ==<br /> [https://docs.moodle.org/dev/SCORM_reporting_improvements SCORM Reporting Improvements] Original GSOC 2011 Project Documentation<br /> === User Docs ===<br /> [https://docs.moodle.org/en/Using_SCORM Using SCORM]<br /> <br /> [https://docs.moodle.org/en/SCORM_FAQ SCORM FAQ]<br /> <br /> [https://docs.moodle.org/en/SCORM_module SCORM Module]<br /> <br /> [[Category:Tutorial]]<br /> [[Category:Plugins]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=SCORM_reports&diff=46599 2014-10-28T01:36:36Z

<p>Ankitfrenz: /* Other Optional Files */</p> <hr /> <div>{{Moodle 2.2}}<br /> == Introduction ==<br /> SCORM reports were converted to a pluggable architecture as of MOODLE 2.2. The original documentation of the project can be found at [https://docs.moodle.org/dev/SCORM_reporting_improvements SCORM Reporting Improvements]. Scorm Reports define a way for developer to develop reports of their own for the scorm module. The rest of this page deals with the details of how to develop such a report.<br /> == Template ==<br /> Here is a basic template for scorm report plugin on [https://github.com/ankitagarwal/scorm_report_template Github]<br /> == File structure ==<br /> Each plugin is allowed to have following files and folders:<br /> <br /> === Mandatory Files ===<br /> * classes/report.php<br /> * lang/xx/scormreport_pluginname.php<br /> <br /> === Other Optional Files ===<br /> * Version.php<br /> * db/install.php<br /> * db/install.xml<br /> * db/upgrade.php<br /> * db/access.php<br /> Please refer [[Upgrade API]] and [[Access API]] to understand the working of above files.<br /> <br /> As you might have noticed the file structure for scorm report plugin is similar to any other standard plugin in Moodle. The only differences are:-<br /> * There must a file classes/report.php implementing class \scormreport_yourreport\report that must extend the default reporting class &quot;\mod_scorm\report&quot; and the extended class must implement the method &quot;display($scorm, $cm, $course, $download)&quot;, which should handle the core reporting feature.<br /> * The lang file is not optional. That is, each plugin must define the string &quot;pluginname&quot; in the lang files.<br /> <br /> == Naming Conventions ==<br /> Following Naming conventions should be kept in mind while writing a scorm report plugin:-<br /> * Folder name should be same as pluginname<br /> * Name of the extended class should be scorm_pluginname_report<br /> * scorm_pluginname_report must implement the function<br /> &lt;code php&gt;<br /> function display($scorm, $cm, $course, $download) {}<br /> &lt;/code&gt;<br /> * Each plugin must define the string &quot;pluginname&quot; in the language files.<br /> == See Also ==<br /> [https://docs.moodle.org/dev/SCORM_reporting_improvements SCORM Reporting Improvements] Original GSOC 2011 Project Documentation<br /> === User Docs ===<br /> [https://docs.moodle.org/en/Using_SCORM Using SCORM]<br /> <br /> [https://docs.moodle.org/en/SCORM_FAQ SCORM FAQ]<br /> <br /> [https://docs.moodle.org/en/SCORM_module SCORM Module]<br /> <br /> [[Category:Tutorial]]<br /> [[Category:Plugins]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=SCORM_reports&diff=46598 2014-10-28T01:34:31Z

<p>Ankitfrenz: /* Mandatory Files */</p> <hr /> <div>{{Moodle 2.2}}<br /> == Introduction ==<br /> SCORM reports were converted to a pluggable architecture as of MOODLE 2.2. The original documentation of the project can be found at [https://docs.moodle.org/dev/SCORM_reporting_improvements SCORM Reporting Improvements]. Scorm Reports define a way for developer to develop reports of their own for the scorm module. The rest of this page deals with the details of how to develop such a report.<br /> == Template ==<br /> Here is a basic template for scorm report plugin on [https://github.com/ankitagarwal/scorm_report_template Github]<br /> == File structure ==<br /> Each plugin is allowed to have following files and folders:<br /> <br /> === Mandatory Files ===<br /> * classes/report.php<br /> * lang/xx/scormreport_pluginname.php<br /> <br /> === Other Optional Files ===<br /> * Version.php<br /> * db/install.php<br /> * db/install.xml<br /> * db/upgrade.php<br /> * db/access.php<br /> Please refer [[Upgrade API]] and [[Access API]] to understand the working of above files.<br /> <br /> As you might have noticed the file structure for scorm report plugin is similar to any other standard plugin in Moodle. The only differences are:-<br /> * There must a file report.php must extend the default reporting class &quot;scorm_default_report&quot; and the extended class must implement the method &quot;display($scorm, $cm, $course, $download)&quot;, which should handle the core reporting feature.<br /> * The lang file is not optional. That is each plugin must define the string &quot;pluginname&quot; in the lang files.<br /> == Naming Conventions ==<br /> Following Naming conventions should be kept in mind while writing a scorm report plugin:-<br /> * Folder name should be same as pluginname<br /> * Name of the extended class should be scorm_pluginname_report<br /> * scorm_pluginname_report must implement the function<br /> &lt;code php&gt;<br /> function display($scorm, $cm, $course, $download) {}<br /> &lt;/code&gt;<br /> * Each plugin must define the string &quot;pluginname&quot; in the language files.<br /> == See Also ==<br /> [https://docs.moodle.org/dev/SCORM_reporting_improvements SCORM Reporting Improvements] Original GSOC 2011 Project Documentation<br /> === User Docs ===<br /> [https://docs.moodle.org/en/Using_SCORM Using SCORM]<br /> <br /> [https://docs.moodle.org/en/SCORM_FAQ SCORM FAQ]<br /> <br /> [https://docs.moodle.org/en/SCORM_module SCORM Module]<br /> <br /> [[Category:Tutorial]]<br /> [[Category:Plugins]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Events_API&diff=46006 2014-07-29T02:57:28Z

<p>Ankitfrenz: /* Rules */</p> <hr /> <div>{{Infobox Project<br /> |name = Events 2<br /> |state = Completed<br /> |tracker = MDL-39797 , MDL-39952, MDL-39846<br /> |discussion = https://moodle.org/mod/forum/discuss.php?d=229425<br /> |assignee = Backend Team<br /> }}<br /> <br /> = What are events? =<br /> <br /> Events are atomic pieces of information describing something that happened in Moodle. Events are primarily the result of user actions, but could also be the result of the [[:en:Cron|cron]] process or administration actions [[:en:Administration via command line|undertaken via the command line]].<br /> <br /> When an action takes place, an event is created by a [[Core APIs|core API]] or [[Plugins|plugin]]. The Events system then disseminates this event information to observers registered for this event. In this way, the events system acts as a communication backbone throughout the Moodle system. Event observers can not modify event data or interrupt the dispatching of events, it is a one way communication channel.<br /> <br /> = Why was a new events system needed? =<br /> <br /> The need to improve the Events system was prompted by a need for a richer and more efficient logging system, however the benefits of this improvement are useful to other parts of Moodle that observe event information.<br /> <br /> * The events need to be more strictly defined for logging and other advanced use cases. They need to contain more information, organised in a standardised way (in addition to the fields from the legacy log table and log_actions table).<br /> * Complex data types were allowed in old events, which was causing major problems when serialising/storing/unserialising the data.<br /> * The logging tables and events contain similar information and were triggered at the same places; utilising events for logging would remove this code duplication. All events should be loggable and all current log entries should be triggered as events.<br /> * The logging system is an event observer, listening to all events and directing them to logging storage plugins in a controllable way.<br /> * It is possible to subscribe to '*' event, which would allow a system to potentially observe, and selectively deal with, all events. Previously, handlers did not receive event names which made this problematic.<br /> * Previously, event handlers could trigger exceptions during site upgrades, which would lead to fatal upgrade problems. The new design eliminates this.<br /> * Failure in previous handlers blocked dispatching of subsequent events. Problems in new observers would only be logged and execution would continue normally.<br /> * Previously, execution of external handlers during DB transactions blocked other handlers. This would be eliminated by in-memory buffer for external events.<br /> * Previously there was no observer priority.<br /> * Previously, nested events were not dispatched sequentially, which would change the order of events were received by lower priority handlers.<br /> <br /> = Performance =<br /> Some basic profiling was conducted.<br /> <br /> &lt;p class=&quot;note&quot;&gt;This next two paragraphs need to be replaced with results.&lt;/p&gt;<br /> There is a general plan to complete pre- and post-implementation testing as development happens. The new system will be implemented in parallel with the old one, which should help with comparison of new and old logging and event triggering performance on each page.<br /> <br /> Our aim is to capture more information about actions in Moodle by triggering more events and logging more information about each event. This is going to impact negatively on performance. We hope to offset that impact by improving log storage, simplifying event dispatching and adding other core performance improvements. The proposed class structure of the base event should allow some new advanced techniques, which may also improve performance in some scenarios.<br /> <br /> More details will be added to this section soon.<br /> <br /> = Events API =<br /> <br /> Each plugin defines the events that it can report (trigger) by extending an abstract base class, once for each possible event. This approach has several benefits.<br /> ; Events are active objects<br /> : When they are triggered and possibly after they are reinstantiated (say, when they are retrieved from a log), an event object is able to provide callback functions for various purposes (such as capability checks).<br /> ; Automatic inclusion<br /> : Event class definitions is automatically included when needed, without having to maintain lists of known event types. New event definitions can be added without the need to upgrade, only purging of the MUC cache is required after adding a new observer.<br /> ; Maintainability<br /> : It is relatively simple to add new events and migrate existing events. Code review is simplified because there is less duplication of code when triggering same events and all event related information/code is concentrated in one file in fixed locations.<br /> ; Self documenting<br /> : The behaviour of events is combined with the definition of events in one place (file). It is easy for event observer writers to know what events a plugin can trigger. This includes support for autocompletion and code inspection in modern IDEs. A list of all events is now available as a report to administrators and researchers.<br /> ; Quick, self-validating data structure<br /> : As events are instantiated objects, the PHP processor will validate the structure and type of event classes. This does not ensure data value validity, but does give some assurance of consistency and it also detects unintentional typos.<br /> <br /> == Backwards compatibility and migration ==<br /> <br /> Events:<br /> * All legacy events in the standard distribution have been replaced with the new events API and events_trigger() has been deprecated.<br /> * For events that already exist in Moodle 2.5, the additional legacy information has been added to the event data (in properties 'legacyeventname' and 'legacyeventdata')<br /> * The legacy events handling code is maintained separately and will continue being supported in Moodle 2.7.<br /> * All legacy events-handlers have been migrated to new observers in standard distribution.<br /> * In future, more subsystems may be migrated to events-observers, ex.: gradebook history, completion.<br /> <br /> Logging:<br /> * The function add_to_log() has been deprecated with a notice as of Moodle 2.7.<br /> * Existing add_to_log() parameters has been migrated inside new events method, in get_legacy_log_data(). Calls to core_event_base::trigger() will lead to entries being added to the legacy log table if the legacy log plugin is enabled.<br /> <br /> See https://docs.moodle.org/dev/Migrating_logging_calls_in_plugins<br /> <br /> == Event dispatching and observers ==<br /> <br /> The new event dispatching system is completely separate from the old events code. Original event handlers are now called observers with the description stored in the same db/events.php file, but as a new array with a different format.<br /> <br /> === Event observers ===<br /> <br /> Observers are described in db/events.php in the array $observers, the array is not indexed and contains a list of observers defined as an array with the following properties;<br /> * eventname – fully qualified event class name or &quot;*&quot; indicating all events, ex.: ''\plugintype_pluginname\event\something_happened''.<br /> * callback - PHP callable type.<br /> * includefile - optional. File to be included before calling the observer. Path relative to dirroot.<br /> * priority - optional. Defaults to 0. Observers with higher priority are notified first.<br /> * internal - optional. Defaults to true. Non-internal observers are not called during database transactions, but instead after a successful commit of the transaction.<br /> <br /> &lt;code php&gt;<br /> <br /> $observers = array(<br /> <br /> array(<br /> 'eventname' =&gt; '\core\event\sample_executed',<br /> 'callback' =&gt; 'core_event_sample_observer::observe_one',<br /> ),<br /> <br /> array(<br /> 'eventname' =&gt; '\core\event\sample_executed',<br /> 'callback' =&gt; 'core_event_sample_observer::external_observer',<br /> 'priority' =&gt; 200,<br /> 'internal' =&gt; false,<br /> ),<br /> <br /> array(<br /> 'eventname' =&gt; '*',<br /> 'callback' =&gt; 'core_event_sample_observer::observe_all',<br /> 'includefile' =&gt; null,<br /> 'internal' =&gt; true,<br /> 'priority' =&gt; 9999,<br /> ),<br /> <br /> );<br /> <br /> &lt;/code&gt;<br /> <br /> === Event dispatching ===<br /> <br /> A list of available observers is constructed on the fly directly from all available in 'events.php' files. Previously handlers were installed only during installation and upgrade. This has little risk of performance regression because the list is already cached in MUC. Observers get events before installation or any upgrade, however observers are not notified during the initial installation of Moodle core tables.<br /> <br /> Developers of observers must make sure that execution does not end with a fatal error under any condition (before install, before upgrade or normal operation). Exceptions are automatically captured, logged in the PHP error log, and notification of other observers continues. Current handlers must not throw any exceptions at any time.<br /> <br /> Observers are notified sequentially in the same order in which events were triggered. This means that events triggered in observers are queued in FIFO buffer and are processed after all observers are notified.<br /> <br /> === Differences from old event handling ===<br /> <br /> # New events contain a lot more structured information.<br /> # There is separate context cache that may be used when deleting data or for observer performance improvements.<br /> # No database access is allowed in new event dispatching code.<br /> # There is no support for cron execution. This eliminates performance problems, simplifies events dispatching and prevents abuse of cron events.<br /> # Events triggered in observers are processed in a different order.<br /> # External events are buffered when a transaction is in progress, instead of being sent to the cron queue.<br /> # It is possible to define multiple observers for one event in one events.php file.<br /> # It is possible to subscribe an observer to all events.<br /> # The new event manager is using frankenstyle autoloading, which leads to a smaller memory footprint when events are not used on the current page.<br /> <br /> == Triggering events ==<br /> <br /> * All event definitions are classes extending the \core\event\base class.<br /> * Events are triggered by creating a new instance of the class event and executing $event-&gt;trigger().<br /> * Each event class names are a unique identifier of the event.<br /> * Class names and namespace follow the identifier scheme \'''frankenstyle_component'''\event\'''some_object_action'''. Core events have prefix 'core_'.<br /> * Each event class is defined in a separate file. File name and location must match the class name for the use of auto loading, for example: '''plugindir'''/classes/event/'''something_happened'''.php<br /> * The event identifier suffix has the form ''some_object_action'' ('''something_happened''' in the example above) and should follow the standard naming convention. The last word after the underscore is automatically parsed as its action, the rest of word is its object.<br /> <br /> Decision:[[#Verb_list| Recommended verb list]]<br /> <br /> Examples: \core\event\course_completed, \mod_assign\event\submission_commented, \mod_forum\event\post_shared, \mod_forum\event\post_responded, etc.<br /> <br /> * Ideally, it should be possible to trigger an event without gathering additional information for the event. To reduce the cost of data gathering, specifically the cost of database reads, at least the minimal values needed to trigger an event should be already available in variables.<br /> <br /> An example of triggering an event:<br /> &lt;code php&gt;<br /> $event = \mod_myplugin\event\something_happened::create(array('context' =&gt; $context, 'objectid' =&gt; YYY, 'other' =&gt; ZZZ));<br /> // ... code that may add some record snapshots<br /> $event-&gt;trigger();<br /> &lt;/code&gt;<br /> <br /> <br /> === Use of PHP autoloading ===<br /> <br /> All new OOP APIs in Moodle 2.6 onwards are going to use class auto loading - see [[Automatic class loading]]. New events use PHP within strictly defined namespaces, which concentrate all event classes in the classes/event/ subdirectory.<br /> <br /> === Why separate classes? ===<br /> Pros<br /> * Maintainability - It is much easier to review, debug and integrate.<br /> * Self documenting, behaviour is combined with definition.<br /> * It is extremely flexible for plugin developers and core devs too.<br /> * Automatic lists events can be generated without being installed - PHPDocs as events documentation.<br /> * It is included only when needed using autoloading.<br /> * Self-validating data structure (by PHP).<br /> * Some developers will find it easier to copy whole class files as templates.<br /> Cons<br /> * Big learning curve for developers without OOP skills (all other new subsystems in Moodle already use OOP, you can not code without these skills any more).<br /> * Some developers may find it harder to copy-and-paste examples because they will need to create new class first and use it afterwards (this can be viewed as a benefit because it forces developers to think more about events).<br /> * This has increased the number lines of code in Moodle for events and logging.<br /> <br /> == Information contained in events ==<br /> <br /> Events have to contain as much information as they can, but this should not affect the performance. That's why part of the information is available in properties, and the rest via methods. This allows for delayed computation of data until the time it is really needed, if it ever is.<br /> <br /> === Properties ===<br /> <br /> The following is a list of properties that the developer has to pass to the event upon creation, or ones that can be automatically generated where possible and cost free. Some of these properties are not mandatory.<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Property name<br /> ! Title<br /> ! Type<br /> ! Required<br /> ! Comment<br /> |-<br /> | ''eventname''<br /> | Event name<br /> | ''static, automatic from class name''<br /> | -<br /> | Automatically computed by copying class name<br /> |-<br /> | ''component''<br /> | Component<br /> | ''static, automatic from top namespace''<br /> | -<br /> | Component declaring the event, automatically computed from class name.<br /> |-<br /> | ''action''<br /> | Action<br /> | ''static, automatic from last word in class name''<br /> | -<br /> | Can be automatically computed from class name.<br /> |-<br /> | ''target''<br /> | target of action<br /> | ''static, automatic from class name''<br /> | -<br /> | Target on which the action is taken, can be automatically computed from class name.<br /> |-<br /> | objecttable<br /> | Database table name<br /> | static<br /> | optional (Must be set if objetid present)<br /> | Database table name which represents the event object to the best. Never use a relationship table here.<br /> |-<br /> | objectid<br /> | Object ID<br /> | variable<br /> | Optional (Must be set if objettable present)<br /> | Id of the object record from objecttable.<br /> |-<br /> | '''''crud'''''<br /> | Transaction type<br /> | ''static''<br /> | optional<br /> | One of [crud] letters. Statically declared in the event class method init().<br /> |-<br /> | '''''level''''' / '''''edulevel'''''<br /> | Level<br /> | ''static''<br /> | optional<br /> | Level of educational value of the event. Statically declared in the event class method init(). Changed from '''''level''''' to '''''edulevel''''' in Moodle 2.7 (See below for more details)<br /> |-<br /> | contextid<br /> | Context ID<br /> | mandatory<br /> | -<br /> |-<br /> | contextlevel<br /> | Context level<br /> | automatic from context<br /> | -<br /> | This tells you if it was a course, activity, course category, etc.<br /> |-<br /> | contextinstanceid<br /> | Context instanceid<br /> | automatic from context<br /> | -<br /> | Based on context level this may be course id , course module id, course category, etc.<br /> |-<br /> | userid<br /> | User ID<br /> | defaults to current user<br /> | -<br /> | User ID, or 0 when not logged in, or -1 when other (System, CLI, Cron, ...)<br /> |-<br /> | courseid<br /> | Affected course<br /> | defaults to course context from context<br /> | -<br /> | This is used only for contexts at and bellow course level - this can be used to filter events by course (includes all course activities)<br /> |-<br /> | relateduserid<br /> | Affected user<br /> | variable<br /> | optional<br /> | Is this action related to some user? This could be used for some personal timeline view.<br /> |-<br /> | anonymous<br /> | Anonymous action<br /> | variable<br /> | optional (Defaults to 0)<br /> | Is this action anonymous? Reports should ignore events with anonymous set to 1.<br /> |-<br /> | other<br /> | All other data<br /> | variable array<br /> | optional<br /> | Any other fields needed for event description - scalars or arrays, must be serialisable using json_encode()<br /> |-<br /> | timecreated<br /> | Time of the event<br /> | automatic<br /> | -<br /> | Time when the event was triggered.<br /> |}<br /> <br /> * static: same for all event instances of this class<br /> * variable: might not be same for all instances of this event class<br /> * mandatory: required in order to trigger the event<br /> * optional: not necessarily required to trigger the event<br /> <br /> ==== Level property ====<br /> <br /> The edulevel property helps define the educational value of the event. It is intentional that the list is limited to only 3 different constants as having too many options would make it harder for developers to pick the right one(s). We also have to keep in mind that this is not supposed to answer all the questions about a particular event, other event properties like the courseid, the context, the component name can be used with the level to get more granular reports.<br /> <br /> Remember that this is event based. If the user that has triggered the event is not really &quot;participating&quot; because he is an admin, or a manager, then it is the job of the report to filter those. The event itself has a static educational level.<br /> <br /> '''Teaching''' (LEVEL_TEACHING: 1)<br /> <br /> Any event/action that is performed by someone (typically a teacher) and has a teaching value (anything that is effecting the learning experience/environment of the students). This should not be combined with &quot;Participating&quot; events.<br /> <br /> Valid events:<br /> <br /> * A teacher grading a student<br /> * A teacher modifying the course settings<br /> * A teacher adding a new section to the course page<br /> * A teacher modifying a module settings<br /> * A teacher adding a page to course<br /> * A teacher leaving a feedback<br /> <br /> INVALID events:<br /> <br /> * A teacher posting in a forum (it might affect the learning experience, but not necessarily, so the teacher is just participating)<br /> <br /> '''Participating''' (LEVEL_PARTICIPATING: 2)<br /> <br /> Any event/action that is performed by a user, that is related (or could be related) to his learning experience.<br /> <br /> Valid events:<br /> <br /> * A user posting to a forum<br /> * A user submitting an assignment<br /> * A user blogging<br /> * A user reading someone's blog<br /> * A user posting a comment<br /> * A user chatting on a chat activity<br /> * A user viewing the course page<br /> * A user deletes a blog post<br /> <br /> INVALID events:<br /> <br /> * A user updating his profile<br /> * A user visiting someone's profile<br /> * A user viewing his /my/ page<br /> * A user sending a message to another one<br /> <br /> '''Other''' (LEVEL_OTHER: 0)<br /> <br /> Any other action, whether they are related to the site administration, or are specific to user. They do not have any educational value.<br /> <br /> === Methods ===<br /> <br /> The computation of this data is not required by default, but can be accessed by any event observer if need be.<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Method<br /> ! Comment<br /> |-<br /> | get_name()<br /> | Returns localised name of the event, it is the same for all instances.<br /> |-<br /> | get_description()<br /> | Returns non-localised description of one particular event. There are plans to make this localised in future.<br /> <br /> It is recommended that the string begins with identifying the user who triggered the event by providing the user id in quotations. This applies to other variables used in the description as well. If an activity is also mentioned then the course module id should be used, not the id from the activity table. For example &quot;The user with the id '$this-&gt;userid' updated the activity 'youractivity' with the course module id '$this-&gt;contextinstanceid'.&quot;.<br /> |-<br /> | can_view($user)<br /> | This method is deprecated, please do not use this.<br /> |-<br /> | get_url()<br /> | Returns Moodle URL where the event can be observed afterwards. Can be null, if no valid location is present.<br /> |-<br /> | get_legacy_eventname()<br /> | Information necessary for event backward compatibility.<br /> |-<br /> | get_legacy_eventdata()<br /> | Information necessary for event backward compatibility.<br /> |-<br /> | get_legacy_logdata()<br /> | Information necessary for logging backward compatibility.<br /> |}<br /> <br /> ===Record caching===<br /> <br /> The standard event data may not contain all the information observers need. The built-in record snapshot support in events allows developers to attach more auxiliary information when triggering events, it may be for example course record, some record that was just deleted, etc. <br /> * Snapshots are expected to be an exact snapshot of the database table at the instance when the event was triggered.<br /> * Snapshot can be set and requested for any table. If not cached, it defaults to direct $DB-&gt;get_record calls.<br /> * Please be aware that the snapshots are not stored in the event, and cannot be restored.<br /> * Snapshot are supposed to be used only by observers. They should never be used by reports or by the event itself.<br /> * When using a snapshot in an observer, please make sure you are taking proper care of handling exceptions as the record you are requesting could have been deleted in the time, in between your observer is notified about the event and the trigger.<br /> * We recommend all delete event must add snapshot of the deleted record.<br /> <br /> &lt;code php&gt;<br /> $event = \core\event\role_assigned::create(<br /> array('context'=&gt;$context, 'objectid'=&gt;$ra-&gt;roleid, 'relateduserid'=&gt;$ra-&gt;userid,<br /> 'other'=&gt;array('id'=&gt;$ra-&gt;id, 'component'=&gt;$ra-&gt;component, 'itemid'=&gt;$ra-&gt;itemid)));<br /> $event-&gt;add_record_snapshot('role_assignments', $ra);<br /> $event-&gt;trigger();<br /> &lt;/code&gt;<br /> <br /> &lt;code php&gt;<br /> $event = \core\event\role_unassigned::create(<br /> array('context'=&gt;$context, 'objectid'=&gt;$ra-&gt;roleid, 'relateduserid'=&gt;$ra-&gt;userid,<br /> 'other'=&gt;array('id'=&gt;$ra-&gt;id, 'component'=&gt;$ra-&gt;component, 'itemid'=&gt;$ra-&gt;itemid)));<br /> $event-&gt;add_record_snapshot('role_assignments', $ra);<br /> $event-&gt;trigger();<br /> &lt;/code&gt;<br /> <br /> The related methods are:<br /> * public function add_record_snapshot($tablename, $record)<br /> * public function get_record_snapshot($tablename, $id)<br /> <br /> == Events naming convention ==<br /> <br /> Clear event names help developers when reading what events are triggered, and defining the events properties when defining the event class.<br /> <br /> Decision: \&lt;component&gt;\event\&lt;some_object&gt;_&lt;verb&gt;<br /> <br /> === Existing events ===<br /> <br /> List of existing events in Moodle code base, along with their 2.5 couterparts.<br /> <br /> This list is out of date. For a full list of events check out the [https://docs.moodle.org/en/Event_list_report Event list report] which is located in &quot;Site administration &gt; Reports &gt; Event list&quot; of your Moodle installation (2.7+).<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Fully qualified event name<br /> ! 2.5 name<br /> ! Component<br /> ! Object<br /> ! Action (Verb)<br /> ! Comment<br /> |-<br /> | '''assignsubmission_comments\event\comment_created'''<br /> | -<br /> | assignsubmission_comments<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''assignsubmission_comments\event\comment_deleted'''<br /> | -<br /> | assignsubmission_comments<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''assignsubmission_file\event\assessable_uploaded'''<br /> | assessable_file_uploaded<br /> | assignsubmission_file<br /> | assessable<br /> | uploaded<br /> | To be deprecated MDL-35197<br /> |- <br /> | '''assignsubmission_file\event\submission_created'''<br /> | -<br /> | assignsubmission_file<br /> | submission<br /> | created<br /> | <br /> |- <br /> | '''assignsubmission_file\event\submission_updated'''<br /> | -<br /> | assignsubmission_file<br /> | submission<br /> | updated<br /> | <br /> |- <br /> | '''assignsubmission_onlinetext\event\assessable_uploaded'''<br /> | assessable_content_uploaded<br /> | assignsubmission_onlinetext<br /> | assessable<br /> | uploaded<br /> | <br /> |- <br /> | '''assignsubmission_onlinetext\event\submission_created'''<br /> | -<br /> | assignsubmission_onlinetext<br /> | submission<br /> | created<br /> | <br /> |- <br /> | '''assignsubmission_onlinetext\event\submission_updated'''<br /> | -<br /> | assignsubmission_onlinetext<br /> | submission<br /> | updated<br /> | <br /> |- <br /> | '''block_comments\event\comment_created'''<br /> | -<br /> | block_comments<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''block_comments\event\comment_deleted'''<br /> | -<br /> | block_comments<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''booktool_exportimscp\event\book_exported'''<br /> | -<br /> | booktool_exportimscp<br /> | book<br /> | exported<br /> | <br /> |- <br /> | '''booktool_print\event\book_printed'''<br /> | -<br /> | booktool_print<br /> | book<br /> | printed<br /> | <br /> |- <br /> | '''booktool_print\event\chapter_printed'''<br /> | -<br /> | booktool_print<br /> | chapter<br /> | printed<br /> | <br /> |- <br /> | '''core\event\assessable_submitted'''<br /> | -<br /> | core<br /> | assessable<br /> | submitted<br /> | Abstract class <br /> |- <br /> | '''core\event\assessable_uploaded'''<br /> | -<br /> | core<br /> | assessable<br /> | uploaded<br /> | Abstract class <br /> |- <br /> | '''core\event\base'''<br /> | -<br /> | core<br /> | base<br /> | -<br /> | Abstract class <br /> |- <br /> | '''core\event\blog_association_created'''<br /> | -<br /> | core<br /> | blog_association<br /> | created<br /> | <br /> |- <br /> | '''core\event\blog_comment_created'''<br /> | -<br /> | core<br /> | blog_comment<br /> | created<br /> | <br /> |- <br /> | '''core\event\blog_comment_deleted'''<br /> | -<br /> | core<br /> | blog_comment<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\blog_entries_viewed'''<br /> | -<br /> | core<br /> | blog_entries<br /> | viewed<br /> | <br /> |- <br /> | '''core\event\blog_entry_created'''<br /> | blog_entry_added<br /> | core<br /> | blog_entry<br /> | created<br /> | <br /> |- <br /> | '''core\event\blog_entry_deleted'''<br /> | blog_entry_deleted<br /> | core<br /> | blog_entry<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\blog_entry_updated'''<br /> | blog_entry_edited<br /> | core<br /> | blog_entry<br /> | updated<br /> | <br /> |- <br /> | '''core\event\cohort_created'''<br /> | cohort_added<br /> | core<br /> | cohort<br /> | created<br /> | <br /> |- <br /> | '''core\event\cohort_deleted'''<br /> | cohort_deleted<br /> | core<br /> | cohort<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\cohort_member_added'''<br /> | cohort_member_added<br /> | core<br /> | cohort_member<br /> | added<br /> | <br /> |- <br /> | '''core\event\cohort_member_removed'''<br /> | cohort_member_removed<br /> | core<br /> | cohort_member<br /> | removed<br /> | <br /> |- <br /> | '''core\event\cohort_updated'''<br /> | cohort_updated<br /> | core<br /> | cohort<br /> | updated<br /> | <br /> |- <br /> | '''core\event\comment_created'''<br /> | -<br /> | core<br /> | comment<br /> | created<br /> | Abstract class <br /> |- <br /> | '''core\event\comment_deleted'''<br /> | -<br /> | core<br /> | comment<br /> | deleted<br /> | Abstract class <br /> |- <br /> | '''core\event\comments_viewed'''<br /> | -<br /> | core<br /> | comments<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\content_viewed'''<br /> | -<br /> | core<br /> | content<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\course_category_created'''<br /> | -<br /> | core<br /> | course_category<br /> | created<br /> | <br /> |- <br /> | '''core\event\course_category_deleted'''<br /> | course_category_deleted<br /> | core<br /> | course_category<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\course_category_updated'''<br /> | -<br /> | core<br /> | course_category<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_completed'''<br /> | course_completed<br /> | core<br /> | course<br /> | completed<br /> | <br /> |- <br /> | '''core\event\course_completion_updated'''<br /> | -<br /> | core<br /> | course_completion<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_content_deleted'''<br /> | course_content_removed<br /> | core<br /> | course_content<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\course_created'''<br /> | course_created<br /> | core<br /> | course<br /> | created<br /> | <br /> |- <br /> | '''core\event\course_deleted'''<br /> | course_deleted<br /> | core<br /> | course<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\course_module_completion_updated'''<br /> | activity_completion_changed<br /> | core<br /> | course_module_completion<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_module_created'''<br /> | mod_created<br /> | core<br /> | course_module<br /> | created<br /> | <br /> |- <br /> | '''core\event\course_module_deleted'''<br /> | mod_deleted<br /> | core<br /> | course_module<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\course_module_instance_list_viewed'''<br /> | -<br /> | core<br /> | course_module_instance_list<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\course_module_instances_list_viewed'''<br /> | -<br /> | core<br /> | course_module_instances_list<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\course_module_updated'''<br /> | mod_updated<br /> | core<br /> | course_module<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_module_viewed'''<br /> | -<br /> | core<br /> | course_module<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\course_reset_ended'''<br /> | -<br /> | core<br /> | course_reset<br /> | ended<br /> | <br /> |- <br /> | '''core\event\course_reset_started'''<br /> | -<br /> | core<br /> | course_reset<br /> | started<br /> | <br /> |- <br /> | '''core\event\course_restored'''<br /> | course_restored<br /> | core<br /> | course<br /> | restored<br /> | <br /> |- <br /> | '''core\event\course_section_updated'''<br /> | -<br /> | core<br /> | course_section<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_updated'''<br /> | course_updated<br /> | core<br /> | course<br /> | updated<br /> | <br /> |- <br /> | '''core\event\email_failed'''<br /> | -<br /> | core<br /> | email<br /> | failed<br /> | <br /> |- <br /> | '''core\event\group_created'''<br /> | groups_group_created<br /> | core<br /> | group<br /> | created<br /> | <br /> |- <br /> | '''core\event\group_deleted'''<br /> | groups_group_deleted<br /> | core<br /> | group<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\group_member_added'''<br /> | groups_member_added<br /> | core<br /> | group_member<br /> | added<br /> | <br /> |- <br /> | '''core\event\group_member_removed'''<br /> | groups_member_removed<br /> | core<br /> | group_member<br /> | removed<br /> | <br /> |- <br /> | '''core\event\group_updated'''<br /> | groups_group_updated<br /> | core<br /> | group<br /> | updated<br /> | <br /> |- <br /> | '''core\event\grouping_created'''<br /> | groups_grouping_created<br /> | core<br /> | grouping<br /> | created<br /> | <br /> |- <br /> | '''core\event\grouping_deleted'''<br /> | groups_grouping_deleted<br /> | core<br /> | grouping<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\grouping_updated'''<br /> | groups_grouping_updated<br /> | core<br /> | grouping<br /> | updated<br /> | <br /> |- <br /> | '''core\event\manager'''<br /> | -<br /> | core<br /> | manager<br /> | anager<br /> | <br /> |- <br /> | '''core\event\mnet_access_control_created'''<br /> | -<br /> | core<br /> | mnet_access_control<br /> | created<br /> | <br /> |- <br /> | '''core\event\mnet_access_control_updated'''<br /> | -<br /> | core<br /> | mnet_access_control<br /> | updated<br /> | <br /> |- <br /> | '''core\event\note_created'''<br /> | -<br /> | core<br /> | note<br /> | created<br /> | <br /> |- <br /> | '''core\event\note_deleted'''<br /> | -<br /> | core<br /> | note<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\note_updated'''<br /> | -<br /> | core<br /> | note<br /> | updated<br /> | <br /> |- <br /> | '''core\event\notes_viewed'''<br /> | -<br /> | core<br /> | notes<br /> | viewed<br /> | <br /> |- <br /> | '''core\event\role_allow_assign_updated'''<br /> | -<br /> | core<br /> | role_allow_assign<br /> | updated<br /> | <br /> |- <br /> | '''core\event\role_allow_override_updated'''<br /> | -<br /> | core<br /> | role_allow_override<br /> | updated<br /> | <br /> |- <br /> | '''core\event\role_allow_switch_updated'''<br /> | -<br /> | core<br /> | role_allow_switch<br /> | updated<br /> | <br /> |- <br /> | '''core\event\role_assigned'''<br /> | role_assigned<br /> | core<br /> | role<br /> | assigned<br /> | <br /> |- <br /> | '''core\event\role_capabilities_updated'''<br /> | -<br /> | core<br /> | role_capabilities<br /> | updated<br /> | <br /> |- <br /> | '''core\event\role_deleted'''<br /> | -<br /> | core<br /> | role<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\role_unassigned'''<br /> | role_unassigned<br /> | core<br /> | role<br /> | unassigned<br /> | <br /> |- <br /> | '''core\event\user_created'''<br /> | user_created<br /> | core<br /> | user<br /> | created<br /> | <br /> |- <br /> | '''core\event\user_deleted'''<br /> | user_deleted<br /> | core<br /> | user<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\user_enrolment_created'''<br /> | user_enrolled<br /> | core<br /> | user_enrolment<br /> | created<br /> | <br /> |- <br /> | '''core\event\user_enrolment_deleted'''<br /> | user_unenrolled<br /> | core<br /> | user_enrolment<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\user_enrolment_updated'''<br /> | user_enrol_modified<br /> | core<br /> | user_enrolment<br /> | updated<br /> | <br /> |- <br /> | '''core\event\user_list_viewed'''<br /> | -<br /> | core<br /> | user_list<br /> | viewed<br /> | <br /> |- <br /> | '''core\event\user_loggedin'''<br /> | -<br /> | core<br /> | user<br /> | loggedin<br /> | <br /> |- <br /> | '''core\event\user_loggedinas'''<br /> | -<br /> | core<br /> | user<br /> | loggedinas<br /> | <br /> |- <br /> | '''core\event\user_loggedout'''<br /> | user_logout<br /> | core<br /> | user<br /> | loggedout<br /> | <br /> |- <br /> | '''core\event\user_login_failed'''<br /> | -<br /> | core<br /> | user_login<br /> | failed<br /> | <br /> |- <br /> | '''core\event\user_profile_viewed'''<br /> | -<br /> | core<br /> | user_profile<br /> | viewed<br /> | <br /> |- <br /> | '''core\event\user_updated'''<br /> | user_updated<br /> | core<br /> | user<br /> | updated<br /> | <br /> |- <br /> | '''core\event\webservice_function_called'''<br /> | -<br /> | core<br /> | webservice_function<br /> | called<br /> | <br /> |- <br /> | '''core\event\webservice_login_failed'''<br /> | -<br /> | core<br /> | webservice_login<br /> | failed<br /> | <br /> |- <br /> | '''core\event\webservice_service_created'''<br /> | -<br /> | core<br /> | webservice_service<br /> | created<br /> | <br /> |- <br /> | '''core\event\webservice_service_deleted'''<br /> | -<br /> | core<br /> | webservice_service<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\webservice_service_updated'''<br /> | -<br /> | core<br /> | webservice_service<br /> | updated<br /> | <br /> |- <br /> | '''core\event\webservice_service_user_added'''<br /> | -<br /> | core<br /> | webservice_service_user<br /> | added<br /> | <br /> |- <br /> | '''core\event\webservice_service_user_removed'''<br /> | -<br /> | core<br /> | webservice_service_user<br /> | removed<br /> | <br /> |- <br /> | '''core\event\webservice_token_created'''<br /> | -<br /> | core<br /> | webservice_token<br /> | created<br /> | <br /> |- <br /> | '''core\event\webservice_token_sent'''<br /> | -<br /> | core<br /> | webservice_token<br /> | sent<br /> | <br /> |- <br /> | '''logstore_legacy\event\legacy_logged'''<br /> | -<br /> | logstore_legacy<br /> | legacy<br /> | logged<br /> | <br /> |- <br /> | '''mod_assign\event\all_submissions_downloaded'''<br /> | -<br /> | mod_assign<br /> | all_submissions<br /> | downloaded<br /> | <br /> |- <br /> | '''mod_assign\event\assessable_submitted'''<br /> | assessable_submitted<br /> | mod_assign<br /> | assessable<br /> | submitted<br /> | <br /> |- <br /> | '''mod_assign\event\extension_granted'''<br /> | -<br /> | mod_assign<br /> | extension<br /> | granted<br /> | <br /> |- <br /> | '''mod_assign\event\identities_revealed'''<br /> | -<br /> | mod_assign<br /> | identities<br /> | revealed<br /> | <br /> |- <br /> | '''mod_assign\event\marker_updated'''<br /> | -<br /> | mod_assign<br /> | marker<br /> | updated<br /> | <br /> |- <br /> | '''mod_assign\event\statement_accepted'''<br /> | -<br /> | mod_assign<br /> | statement<br /> | accepted<br /> | <br /> |- <br /> | '''mod_assign\event\submission_created'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | created<br /> | Abstract class <br /> |- <br /> | '''mod_assign\event\submission_duplicated'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | duplicated<br /> | <br /> |- <br /> | '''mod_assign\event\submission_graded'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | graded<br /> | <br /> |- <br /> | '''mod_assign\event\submission_locked'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | locked<br /> | <br /> |- <br /> | '''mod_assign\event\submission_status_updated'''<br /> | -<br /> | mod_assign<br /> | submission_status<br /> | updated<br /> | <br /> |- <br /> | '''mod_assign\event\submission_unlocked'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | unlocked<br /> | <br /> |- <br /> | '''mod_assign\event\submission_updated'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | updated<br /> | Abstract class <br /> |- <br /> | '''mod_assign\event\workflow_state_updated'''<br /> | -<br /> | mod_assign<br /> | workflow_state<br /> | updated<br /> | <br /> |- <br /> | '''mod_book\event\chapter_created'''<br /> | -<br /> | mod_book<br /> | chapter<br /> | created<br /> | <br /> |- <br /> | '''mod_book\event\chapter_deleted'''<br /> | -<br /> | mod_book<br /> | chapter<br /> | deleted<br /> | <br /> |- <br /> | '''mod_book\event\chapter_updated'''<br /> | -<br /> | mod_book<br /> | chapter<br /> | updated<br /> | <br /> |- <br /> | '''mod_book\event\chapter_viewed'''<br /> | -<br /> | mod_book<br /> | chapter<br /> | viewed<br /> | <br /> |- <br /> | '''mod_book\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_book<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_book\event\course_module_viewed'''<br /> | -<br /> | mod_book<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_chat\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_chat<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_chat\event\message_sent'''<br /> | -<br /> | mod_chat<br /> | message<br /> | sent<br /> | <br /> |- <br /> | '''mod_chat\event\sessions_viewed'''<br /> | -<br /> | mod_chat<br /> | sessions<br /> | viewed<br /> | <br /> |- <br /> | '''mod_choice\event\answer_submitted'''<br /> | -<br /> | mod_choice<br /> | answer<br /> | submitted<br /> | <br /> |- <br /> | '''mod_choice\event\answer_updated'''<br /> | -<br /> | mod_choice<br /> | answer<br /> | updated<br /> | <br /> |- <br /> | '''mod_choice\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_choice<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_choice\event\course_module_viewed'''<br /> | -<br /> | mod_choice<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_choice\event\report_viewed'''<br /> | -<br /> | mod_choice<br /> | report<br /> | viewed<br /> | <br /> |- <br /> | '''mod_data\event\comment_created'''<br /> | -<br /> | mod_data<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''mod_data\event\comment_deleted'''<br /> | -<br /> | mod_data<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''mod_data\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_data<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_data\event\course_module_viewed'''<br /> | -<br /> | mod_data<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_data\event\field_created'''<br /> | -<br /> | mod_data<br /> | field<br /> | created<br /> | <br /> |- <br /> | '''mod_data\event\field_deleted'''<br /> | -<br /> | mod_data<br /> | field<br /> | deleted<br /> | <br /> |- <br /> | '''mod_data\event\field_updated'''<br /> | -<br /> | mod_data<br /> | field<br /> | updated<br /> | <br /> |- <br /> | '''mod_data\event\record_created'''<br /> | -<br /> | mod_data<br /> | record<br /> | created<br /> | <br /> |- <br /> | '''mod_data\event\record_deleted'''<br /> | -<br /> | mod_data<br /> | record<br /> | deleted<br /> | <br /> |- <br /> | '''mod_data\event\record_updated'''<br /> | -<br /> | mod_data<br /> | record<br /> | updated<br /> | <br /> |- <br /> | '''mod_data\event\template_updated'''<br /> | -<br /> | mod_data<br /> | template<br /> | updated<br /> | <br /> |- <br /> | '''mod_data\event\template_viewed'''<br /> | -<br /> | mod_data<br /> | template<br /> | viewed<br /> | <br /> |- <br /> | '''mod_feedback\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_feedback<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_feedback\event\course_module_viewed'''<br /> | -<br /> | mod_feedback<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_feedback\event\response_deleted'''<br /> | -<br /> | mod_feedback<br /> | response<br /> | deleted<br /> | <br /> |- <br /> | '''mod_feedback\event\response_submitted'''<br /> | -<br /> | mod_feedback<br /> | response<br /> | submitted<br /> | <br /> |- <br /> | '''mod_folder\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_folder<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_folder\event\course_module_viewed'''<br /> | -<br /> | mod_folder<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_folder\event\folder_updated'''<br /> | -<br /> | mod_folder<br /> | folder<br /> | updated<br /> | <br /> |- <br /> | '''mod_forum\event\assessable_uploaded'''<br /> | assessable_content_uploaded<br /> | mod_forum<br /> | assessable<br /> | uploaded<br /> | <br /> |- <br /> | '''mod_forum\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_forum<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_forum\event\course_searched'''<br /> | -<br /> | mod_forum<br /> | course<br /> | searched<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_created'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | created<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_deleted'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | deleted<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_moved'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | moved<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_updated'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | updated<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_viewed'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | viewed<br /> | <br /> |- <br /> | '''mod_forum\event\forum_viewed'''<br /> | -<br /> | mod_forum<br /> | forum<br /> | viewed<br /> | <br /> |- <br /> | '''mod_forum\event\post_created'''<br /> | -<br /> | mod_forum<br /> | post<br /> | created<br /> | <br /> |- <br /> | '''mod_forum\event\post_deleted'''<br /> | -<br /> | mod_forum<br /> | post<br /> | deleted<br /> | <br /> |- <br /> | '''mod_forum\event\post_updated'''<br /> | -<br /> | mod_forum<br /> | post<br /> | updated<br /> | <br /> |- <br /> | '''mod_forum\event\readtracking_disabled'''<br /> | -<br /> | mod_forum<br /> | readtracking<br /> | disabled<br /> | <br /> |- <br /> | '''mod_forum\event\readtracking_enabled'''<br /> | -<br /> | mod_forum<br /> | readtracking<br /> | enabled<br /> | <br /> |- <br /> | '''mod_forum\event\subscribers_viewed'''<br /> | -<br /> | mod_forum<br /> | subscribers<br /> | viewed<br /> | <br /> |- <br /> | '''mod_forum\event\subscription_created'''<br /> | -<br /> | mod_forum<br /> | subscription<br /> | created<br /> | <br /> |- <br /> | '''mod_forum\event\subscription_deleted'''<br /> | -<br /> | mod_forum<br /> | subscription<br /> | deleted<br /> | <br /> |- <br /> | '''mod_forum\event\userreport_viewed'''<br /> | -<br /> | mod_forum<br /> | userreport<br /> | viewed<br /> | <br /> |- <br /> | '''mod_glossary\event\comment_created'''<br /> | -<br /> | mod_glossary<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''mod_glossary\event\comment_deleted'''<br /> | -<br /> | mod_glossary<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''mod_lesson\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_lesson<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lesson\event\course_module_viewed'''<br /> | -<br /> | mod_lesson<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lesson\event\essay_assessed'''<br /> | -<br /> | mod_lesson<br /> | essay<br /> | assessed<br /> | <br /> |- <br /> | '''mod_lesson\event\essay_attempt_viewed'''<br /> | -<br /> | mod_lesson<br /> | essay_attempt<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lesson\event\highscore_added'''<br /> | -<br /> | mod_lesson<br /> | highscore<br /> | added<br /> | <br /> |- <br /> | '''mod_lesson\event\highscores_viewed'''<br /> | -<br /> | mod_lesson<br /> | highscores<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lesson\event\lesson_ended'''<br /> | -<br /> | mod_lesson<br /> | lesson<br /> | ended<br /> | <br /> |- <br /> | '''mod_lesson\event\lesson_started'''<br /> | -<br /> | mod_lesson<br /> | lesson<br /> | started<br /> | <br /> |- <br /> | '''mod_lti\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_lti<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lti\event\course_module_viewed'''<br /> | -<br /> | mod_lti<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lti\event\unknown_service_api_called'''<br /> | lti_unknown_service_api_call<br /> | mod_lti<br /> | unknown_service_api<br /> | called<br /> | <br /> |- <br /> | '''mod_page\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_page<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_page\event\course_module_viewed'''<br /> | -<br /> | mod_page<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_quiz\event\attempt_abandoned'''<br /> | quiz_attempt_abandoned<br /> | mod_quiz<br /> | attempt<br /> | abandoned<br /> | <br /> |- <br /> | '''mod_quiz\event\attempt_becameoverdue'''<br /> | quiz_attempt_overdue<br /> | mod_quiz<br /> | attempt<br /> | becameoverdue<br /> | <br /> |- <br /> | '''mod_quiz\event\attempt_started'''<br /> | quiz_attempt_started<br /> | mod_quiz<br /> | attempt<br /> | started<br /> | <br /> |- <br /> | '''mod_quiz\event\attempt_submitted'''<br /> | quiz_attempt_submitted<br /> | mod_quiz<br /> | attempt<br /> | submitted<br /> | <br /> |- <br /> | '''mod_resource\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_resource<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_resource\event\course_module_viewed'''<br /> | -<br /> | mod_resource<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\attempt_deleted'''<br /> | -<br /> | mod_scorm<br /> | attempt<br /> | deleted<br /> | <br /> |- <br /> | '''mod_scorm\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_scorm<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\course_module_viewed'''<br /> | -<br /> | mod_scorm<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\interactions_viewed'''<br /> | -<br /> | mod_scorm<br /> | interactions<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\report_viewed'''<br /> | -<br /> | mod_scorm<br /> | report<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\sco_launched'''<br /> | -<br /> | mod_scorm<br /> | sco<br /> | launched<br /> | <br /> |- <br /> | '''mod_scorm\event\tracks_viewed'''<br /> | -<br /> | mod_scorm<br /> | tracks<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\user_report_viewed'''<br /> | -<br /> | mod_scorm<br /> | user_report<br /> | viewed<br /> | <br /> |- <br /> | '''mod_url\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_url<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_url\event\course_module_viewed'''<br /> | -<br /> | mod_url<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\comment_created'''<br /> | -<br /> | mod_wiki<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''mod_wiki\event\comment_deleted'''<br /> | -<br /> | mod_wiki<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''mod_wiki\event\comments_viewed'''<br /> | -<br /> | mod_wiki<br /> | comments<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_wiki<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\course_module_viewed'''<br /> | -<br /> | mod_wiki<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_created'''<br /> | -<br /> | mod_wiki<br /> | page<br /> | created<br /> | <br /> |- <br /> | '''mod_wiki\event\page_deleted'''<br /> | -<br /> | mod_wiki<br /> | page<br /> | deleted<br /> | <br /> |- <br /> | '''mod_wiki\event\page_diff_viewed'''<br /> | -<br /> | mod_wiki<br /> | page_diff<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_history_viewed'''<br /> | -<br /> | mod_wiki<br /> | page_history<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_locks_deleted'''<br /> | -<br /> | mod_wiki<br /> | page_locks<br /> | deleted<br /> | <br /> |- <br /> | '''mod_wiki\event\page_map_viewed'''<br /> | -<br /> | mod_wiki<br /> | page_map<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_updated'''<br /> | -<br /> | mod_wiki<br /> | page<br /> | updated<br /> | <br /> |- <br /> | '''mod_wiki\event\page_version_deleted'''<br /> | -<br /> | mod_wiki<br /> | page_version<br /> | deleted<br /> | <br /> |- <br /> | '''mod_wiki\event\page_version_restored'''<br /> | -<br /> | mod_wiki<br /> | page_version<br /> | restored<br /> | <br /> |- <br /> | '''mod_wiki\event\page_version_viewed'''<br /> | -<br /> | mod_wiki<br /> | page_version<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_viewed'''<br /> | -<br /> | mod_wiki<br /> | page<br /> | viewed<br /> | <br /> |- <br /> | '''mod_workshop\event\assessable_uploaded'''<br /> | assessable_content_uploaded<br /> | mod_workshop<br /> | assessable<br /> | uploaded<br /> | <br /> |- <br /> | '''mod_workshop\event\assessment_evaluated'''<br /> | -<br /> | mod_workshop<br /> | assessment<br /> | evaluated<br /> | <br /> |- <br /> | '''mod_workshop\event\assessment_evaluations_reset'''<br /> | -<br /> | mod_workshop<br /> | assessment_evaluations<br /> | reset<br /> | <br /> |- <br /> | '''mod_workshop\event\assessment_reevaluated'''<br /> | -<br /> | mod_workshop<br /> | assessment<br /> | reevaluated<br /> | <br /> |- <br /> | '''mod_workshop\event\course_module_viewed'''<br /> | workshop_viewed<br /> | mod_workshop<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_workshop\event\instances_list_viewed'''<br /> | -<br /> | mod_workshop<br /> | instances_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_workshop\event\phase_switched'''<br /> | -<br /> | mod_workshop<br /> | phase<br /> | switched<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_assessed'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | assessed<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_created'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | created<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_reassessed'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | reassessed<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_updated'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | updated<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_viewed'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | viewed<br /> | <br /> |- <br /> | '''report_log\event\content_viewed'''<br /> | -<br /> | report_log<br /> | content<br /> | viewed<br /> | <br /> |- <br /> | '''report_loglive\event\content_viewed'''<br /> | -<br /> | report_loglive<br /> | content<br /> | viewed<br /> | <br /> |- <br /> | '''report_outline\event\content_viewed'''<br /> | -<br /> | report_outline<br /> | content<br /> | viewed<br /> | <br /> |- <br /> | '''report_participation\event\content_viewed'''<br /> | -<br /> | report_participation<br /> | content<br /> | viewed<br /> | <br /> |- <br /> | '''report_stats\event\content_viewed'''<br /> | -<br /> | report_stats<br /> | content<br /> | viewed<br /> | <br /> |- <br /> |}<br /> <br /> === Verb list ===<br /> All events must use a verb from this list. New verbs can be added to this list if required, but additions should only be made if there is no valid alternative (we want to keep this list as small as possible).<br /> {| class=&quot;nicetable&quot;<br /> |-<br /> !verb<br /> !Explanation<br /> !Source<br /> |-<br /> |abandoned<br /> |When a attempt is abandoned by user (Quiz attempt)<br /> |Moodle<br /> |-<br /> |accepted<br /> |Example: Accepting a statement when submitting an assignment.<br /> |Moodle<br /> |-<br /> |added<br /> | Used to represent &quot;something that already exists is now part of/bound to another entity&quot;. Examples: &quot;Admin added role to user X&quot;, &quot;Admin added user X to group A&quot;. Wrong example: &quot;User added course in category&quot; because it is a 'move' action, except if a course can be part of multiple categories. The good examples work because: A user can have multiple roles, a user can be in multiple groups.<br /> |Moodle<br /> |-<br /> |answered<br /> | Indicates the actor responded to a Question<br /> |Tincan<br /> |-<br /> |assessed<br /> | Some submitted material has been assessed<br /> |Moodle<br /> |-<br /> |assigned<br /> | Assign some privilege or role to user.<br /> |Moodle<br /> |-<br /> |attempted<br /> | Trying to do an activity. Example: attempting a Math class.<br /> |Tincan<br /> |-<br /> |awarded<br /> | ex:-teacher awarded student a badge.<br /> |Moodle<br /> |-<br /> |backedup<br /> | When a backup has been performed.<br /> |Moodle <br /> |-<br /> |becomeoverdue<br /> | When an activity is overdue Example: Quiz attempt is overdue<br /> |Moodle <br /> |-<br /> |called<br /> | When a call to something is made like an API @see unknown_service_api_called.php<br /> |Moodle<br /> |-<br /> |commented<br /> |Offered an opinion or written experience of the activity. Can be used with the learner as the actor or a system as an actor. Comments can be sent from either party with the idea that the other will read and react to the content.<br /> |Tincan<br /> |-<br /> |completed<br /> |To experience the activity in its entirety. Used to affirm the completion of content. This can be simply experiencing all the content, be tied to objectives or interactions, or determined in any other way. Any content that has been initialized, but not yet completed, should be considered incomplete. There is no verb to 'incomplete' an activity, one would void the statement which completes the activity.&quot;<br /> |Tincan<br /> |-<br /> |created<br /> |Used to represent &quot;something new has been created&quot;.<br /> |Moodle<br /> |-<br /> |deleted<br /> |Used to indicate the object in context was deleted.<br /> |Moodle<br /> |-<br /> |disabled<br /> |When an activity is disabled. Example: forum read tracking disabled.<br /> |Moodle<br /> |-<br /> |downloaded<br /> |When a user download file from user. Example submission/report downloaded.<br /> |Moodle<br /> |-<br /> |duplicated<br /> |For something that has been copied.<br /> |Moodle<br /> |-<br /> |enabled<br /> |When some setting is enabled. Example: forum read tracking enabled.<br /> |Moodle<br /> |-<br /> |ended<br /> |When a process ends. Example: Lesson ended or course reset ended.<br /> |Moodle<br /> |-<br /> |evaluated<br /> |Material has been evaluated.<br /> |Moodle<br /> |-<br /> |exported<br /> |When a report is exported in certain format.<br /> |Moodle<br /> |-<br /> |failed<br /> |Learner did not perform the activity to a level of pre-determined satisfaction. Used to affirm the lack of success a learner experienced within the learning content in relation to a threshold. If the user performed below the minimum to the level of this threshold, the content is 'failed'. The opposite of 'passed'. This is also used in case when message sending is failed.<br /> |Tincan<br /> |-<br /> |graded<br /> |Used to represent an activity was graded.<br /> |Moodle<br /> |-<br /> |granted<br /> |User is granted some extension or capability. Example: extension granted for submission.<br /> |Moodle<br /> |-<br /> |imported<br /> |The act of moving an object into another location or system.<br /> |Tincan<br /> |-<br /> |launched<br /> |When an external object is launched. Try consider started if there is related stopped event.<br /> |Moodle<br /> |-<br /> |locked<br /> |When an activity is locked. Should have a related unlocked event.<br /> |Moodle<br /> |-<br /> |loggedin/loggedout<br /> | For login and logout.<br /> |Moodle<br /> |-<br /> |loggedinas<br /> | If user is logged in as different user. This is used by only one event (user_loggedinas). Adding this verb makes event name more clear, then using loggedin verb.<br /> |Moodle<br /> |-<br /> |locked<br /> |<br /> |Moodle<br /> |-<br /> |moved<br /> | Used to indicate the object in context was moved.<br /> |Moodle<br /> |-<br /> |passed<br /> |Used to affirm the success a learner experienced within the learning content in relation to a threshold. If the user performed at a minimum to the level of this threshold, the content is 'passed'. The opposite of 'failed'.<br /> |Tincan<br /> |-<br /> |printed<br /> |Something is printed.<br /> |Moodle<br /> |-<br /> |reassessed<br /> |Submitted material has been assessed again.<br /> |Moodle<br /> |-<br /> |reevaluated<br /> |Material has been evaluated again.<br /> |Moodle<br /> |-<br /> |removed<br /> |By opposition to &quot;Added&quot;. This does not mean that the object has been deleted, but removed from the entity, or not bound to it any more.<br /> |Moodle<br /> |-<br /> |reset<br /> |Sets one or more properties back to the default value.<br /> |Moodle<br /> |-<br /> |restored<br /> |When restoring a backup. Rolling back to a previous state.<br /> |Moodle<br /> |-<br /> |revealed<br /> |Some identity is revealed. Example: Identities revealed after blind marking.<br /> |Moodle<br /> |-<br /> |searched<br /> |Something is searched. Example: searched in course.<br /> |Moodle<br /> |-<br /> |sent<br /> |Message sent.<br /> |Moodle<br /> |-<br /> |started<br /> |Some activity started<br /> |Moodle<br /> |-<br /> |submitted<br /> |This is very close to &quot;Attempted&quot;. Depends on context which one should be used. For example:- &quot;Admin submitted a form. Student attempted a quiz.&quot; is correct, however some cases might not be as clear as the previous example. We can say both &quot;Student submitted an assignment&quot; or &quot;student attempted an assignment&quot;. We need to make the difference clear.<br /> |Moodle<br /> |-<br /> |suspended<br /> | Suspend something. (example a user)<br /> | Tincan (However the context is different)<br /> |-<br /> |switched<br /> |Something has been switched. For example:- The workshop phase has been switched to assessment&quot;<br /> |Moodle<br /> |-<br /> |unassigned<br /> |As opposed to assigned. When some role is unassigned.<br /> |Moodle<br /> |-<br /> |unlocked<br /> |<br /> |Moodle<br /> |-<br /> |upgraded<br /> |Something was upgraded, some module probably<br /> |Moodle<br /> |-<br /> |updated<br /> |Used to indicate the object in context was updated. Simple example is &quot;Admin updated course xyz&quot;.<br /> |Moodle<br /> |-<br /> |uploaded<br /> |When an assignment is uploaded.<br /> |Moodle<br /> |-<br /> |viewed<br /> |Something has been viewed. For example:- &quot;Student viewed chapter 1 of book 1.&quot;<br /> |Moodle<br /> |-<br /> |}<br /> <br /> === Rules ===<br /> <br /> ==== Use singular ====<br /> <br /> Plurals must be used on objects when it's a ''One to Many'' relationship. Ex: bulk import, mass deletion, ... In any other case, use the singular.<br /> <br /> ==== Ends with a verb ====<br /> <br /> The last word (after the last underscore) must be a verb.<br /> <br /> ==== Consistency among child events ====<br /> <br /> If an event is extending a parent class, it should have the same exact name as the parent event.<br /> <br /> === Deprecated events ===<br /> Following are the events that were supported in 2.5, but deprecated in 2.6 or later<br /> <br /> groups_groupings_deleted (see MDL-41312)<br /> <br /> groups_groupings_groups_removed (see MDL-41312)<br /> <br /> groups_groups_deleted (see MDL-41312)<br /> <br /> groups_members_removed (see MDL-41312)<br /> <br /> == Shared events ==<br /> <br /> Decision: Not supported at this stage.<br /> <br /> In Moodle 2.5 we have a good example of a shared event: 'assessable_content_uploaded' which is triggered in ''forum'', 'assignment'' and ''workshop''.<br /> <br /> The problem with shared events is that we cannot easily track what component triggered them. Of course we could add a new property to the event to keep track of that, but we would soon need more information and more properties. Also, in the case of a logger, the event received would be unique, where in fact it should be considered different depending on the component firing it.<br /> <br /> In our first implementation, we will create one specific event per module. This flexibility does not prevent any observer from capturing them, but still makes sure that the consistency and specificity of each event is maintained.<br /> <br /> It could happen that some events are defined in core and shared, but this should not really happen as low-level APIs should trigger the event, and a module should call that low API instead of doing the job itself.<br /> <br /> == One to many ==<br /> <br /> Decision: Each event should have a one to one relationship. We can reconsider this at a later stage, if the performance hit is extremely high.<br /> <br /> In 2.5, some events are triggered when an action happens on multiple objects. We have to decide whether we want to keep supporting ''One to Many'' events or not.<br /> <br /> Keeping a list of all changes for multiple actions may be problematic because you would have to keep them all in memory until all things are processed. This might also result in the order of events being incorrect. The only correct solution seems to be to trigger each item individually and then many things at the end. Performance needs to be improved elsewhere...<br /> <br /> === Accuracy ===<br /> <br /> When uploading a bunch of users using the CSV upload feature, if only one event is triggered, it means that the observers of ''user_created'' won't be triggered. And so some functionality can be lost as, as a plugin developer, I expect this ''user_created'' to be triggered regardless of the way they have been uploaded. Of course, the developer could observe the event ''bulk_user_imported'', but that means that he could miss some relevant observers.<br /> <br /> This applies to existing events.<br /> <br /> === Performance ===<br /> <br /> Triggering one event is cheaper then repeating the same events x number of times...<br /> <br /> === Information tracking ===<br /> <br /> A ''bulk'' event, might not be verbose enough to allow for proper logging afterwards. Though this is the responsibility of the logger, we probably want to make it easy to store relevant information.<br /> <br /> === Double event ===<br /> <br /> In the case of a bulk user import, if we were to trigger an event per user created, we probably want to trigger one event 'user_bulk_upload_started' when the action starts.<br /> <br /> == Unit Testing ==<br /> <br /> With unit testing for this system we want to assert the following:<br /> <br /> * That event strict validation and custom validation works.<br /> * Missing event data is auto filled with accurate data.<br /> * Typos in properties passed to ::create() are captured (if we decide to validate).<br /> * The legacy methods return the expected values (use assertEventLegacyData() and assertEventLegacyData())<br /> * The class properties are correctly overridden (crud, level, action, object, ...).<br /> * The properties automatically generated (component, name, ...) are correct.<br /> * Events are dispatched to the corresponding observers.<br /> * Events are dispatched to the corresponding legacy handlers.<br /> * Events are dispatched to the * observers.<br /> * Events perform an add_to_log() if it has legacy log data.<br /> * 'Events restore' restored the whole event data, and does not miss any information.<br /> * 'Events restore' does not generate any extra information.<br /> * Event methods should check context object or avoid using it, as context might not be valid at time of event restore (use assertEventContextNotUsed())<br /> <br /> = PHP docs =<br /> * All events php docs must include @since parameter, indicating when the event was first included in standard Moodle distribution.<br /> * All events must declare the $other properties using mark down in the php docs. This later might be converted to a self documenting structure. (See MDL-45108)<br /> <br /> &lt;code php&gt;<br /> /**<br /> * blog_association_created<br /> *<br /> * Class for event to be triggered when a new blog entry is associated with a context.<br /> *<br /> * @property-read array $other {<br /> * Extra information about event.<br /> *<br /> * - string associatetype: type of blog association, course/coursemodule.<br /> * - int blogid: id of blog.<br /> * - int associateid: id of associate.<br /> * - string subject: blog subject.<br /> * }<br /> *<br /> * @package core<br /> * @since Moodle 2.7<br /> * @copyright 2013 onwards Ankit Agarwal<br /> * @license http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later<br /> */<br /> &lt;/code&gt;<br /> <br /> = Example events =<br /> <br /> == Assignment ==<br /> <br /> Assumption: Course contains groups with students in each group.<br /> <br /> '''1.''' Teacher creates an assignment with group mode set to 'Separate groups' and Feedback type set to comments and files.<br /> *Event: User 'Teacher' has created assignment 'B' in course 'C101'.<br /> '''2.''' A student views the assignment.<br /> *Event: User 'Student' has viewed assignment 'B' in course 'C101'.<br /> '''3.''' A member from one of the groups submits an assignment<br /> *Event: User 'Student' has added a submission for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: Email sent to the teacher and all students in that group.<br /> '''4.''' User 'Adrian' adds some changes to the assignment and updates it.<br /> *Event: User 'Adrian' has updated the submission for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: Email sent to the teacher and all students in that group.<br /> '''5.''' Teacher views the assignment.<br /> *Event: User 'Teacher' has viewed assignment 'B' in course 'C101'.<br /> '''6.''' Teacher clicks on 'View/grade all submissions'<br /> *Event: User 'Teacher' has viewed the assignment 'B' grade area in course 'C101'.<br /> '''7.''' Teacher clicks to grade the student's submission.<br /> *Event: User 'Teacher' has viewed the submission for user 'student' for assignment 'B' in course 'C101'.<br /> '''8.''' Teacher marks the assignment with the setting 'Apply grades and feedback to entire group' set to 'Yes' leaving a comment and a file.<br /> *Event: User 'Teacher' has marked assignment 'B' for group 'C' in course 'C101'.<br /> *Event: User 'Teacher' has left a comment for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: User 'Teacher' has uploaded a feedback file for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: User 'Teacher' has uploaded a file to the course 'C101'.<br /> *Event: Email sent to user 'Student' notifying them their submission for assignment 'B' has been marked. - This is done for all users in the group.<br /> '''9.''' User 'Adrian' views the feedback.<br /> *Event: User 'Adrian' has viewed assignment 'B' in course 'C101'.<br /> '''10.''' User 'Adrian' opens the feedback file.<br /> *Event: User 'Adrian' has viewed the file 'A' for assignment 'B' in course 'C101'.<br /> '''11.''' User 'Adrian' adds some changes to the assignment insulting the teachers marking and updates it.<br /> *Event: User 'Adrian' has updated the submission for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: Email sent to user 'Teacher' notifying them that user 'Adrian' has updated the submission for assignment 'B'.<br /> *Event: Email sent to user 'Student' notifying them their submission for assignment 'B' has been updated. - This is done for all users in the group.<br /> '''12.''' The teacher clicks directly on the link in the email to be taken to the grading page.<br /> *Event: User 'Teacher' has viewed the submission for user 'student' for assignment 'B' in course 'C101'.<br /> '''13.''' The teacher is upset due to the harsh comments and decides to mark Adrian down, but not the rest of the group by setting 'Apply grades and feedback to entire group' set to 'No'.<br /> *Event: User 'Teacher' has marked assignment 'B' for user 'Adrian' in course 'C101'.<br /> *Event: User 'Teacher' has left a comment for assignment 'B' for user 'Adrian' in course 'C101'.<br /> *Event: User 'Teacher' has uploaded a feedback file for assignment 'B' for user 'Adrian' in course 'C101'.<br /> *Event: Email sent to user 'Adrian' notifying them their submission for assignment 'B' has been marked.<br /> <br /> = FAQs =<br /> <br /> ; Why not create events in core subsystems? : Because we could not see all core events in one place, it would create problems when naming event classes and finally subsystems are incomplete, we would have to add more now because we could not move the events in the future.<br /> <br /> = Possible future work = <br /> * MDL-45108 &quot;Other&quot; parameters should be defined in a method similar to webservices<br /> * MDL-45217 Create traits for refactoring event triggers<br /> * MDL-42897 Converting completion to use events<br /> * MDL-42898 Develop a timeline page/block<br /> <br /> = See Also =<br /> [[Logging 2]] <br /> <br /> [[Tin Can]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Event_Monitor_specification&diff=45612 2014-07-01T05:45:58Z

<p>Ankitfrenz: /* Future work */</p> <hr /> <div>{{Infobox Project<br /> |name = Event Monitor<br /> |state = Implementation<br /> |tracker = MDL-45758<br /> |discussion = https://moodle.org/mod/forum/discuss.php?d=261660<br /> |assignee = Ankit, Simey<br /> }}<br /> {{Work in progress|forumurl=https://moodle.org/mod/forum/discuss.php?d=261660}}<br /> The Event Monitor report will allow users to select events and receive notifications in real time* when the chosen event happens.<br /> <br /> This report will be built on top of the new [[Event 2]] infrastructure. <br /> <br /> == How it works ==<br /> <br /> * The user or site admin creates a specific set of “rules” that can be subscribed to.<br /> * Each rule defines an event and frequency parameters.<br /> * The users select the rules they are interested in and then subscribe to it at course level for a specific module or all modules.<br /> * Whenever the event occurs in the system , in the frequency specified in the rule, a message is sent out to all the subscribers.<br /> * Since we are using Moodle messaging system to send out these notifications, it can be delivered in any format supported by Moodle (Mobile notification, popup, email etc)<br /> * There would be some default rules that would be shipped with the report, that users can subscribe to straight away.<br /> <br /> === User interface mock-ups ===<br /> <br /> ==== Subscribe to a rule ====<br /> <br /> This is the main page of the Event Monitor report where users can see a list of rules and their current subscriptions. This also lets users to subscribe to new rules or delete their current subscriptions.<br /> <br /> [[File:subscriptions.png]]<br /> <br /> ==== Manage rules ====<br /> <br /> This page lets you manage the rules if you have appropriate permissions (create/edit/delete/copy)<br /> <br /> This is roughly how the page will look like:-<br /> <br /> [[File:listrules.png]]<br /> <br /> ==== Add/Edit a rule ====<br /> <br /> This is the form where users can create a new rule, customise the filters (frequency and time) and personalise the notification message.<br /> <br /> [[File:addrule.png]]<br /> <br /> === A specific example ===<br /> <br /> One scenario may be that you wish to be notified when discussions are becoming active in the forums.<br /> <br /> The figure above shows the creation of a new rule called 'My Student Discussions', which is set to monitor 'Post Created event' on 'Forum Module'. <br /> <br /> In this case, any user subscribed to this rule will receive notifications whenever '30 posts are created in 60 minutes' on the forum they are subscribed to. <br /> <br /> The notification will contain the customised message as configured in the rule.<br /> <br /> == Benefits ==<br /> <br /> * Real time monitoring of events happening in Moodle. <br /> * Admin can be notified when there is heavy activity on the site or they can monitor specific actions that interests them (ex:- course delete).<br /> * A notification can be sent straight to a user's mobile if there is a situation that needs immediate attention.<br /> * The report will be designed to trigger an event when a given subscription criteria are met. This will allow developers to build really powerful scripts on top of the report. For example, a block displaying “Hot forums”, or something more complex like load balancing when there is lot of activity in the forums or quiz.<br /> <br /> == Usage scenarios ==<br /> <br /> * Send notification when more than X posts in any forum are made in a given course in Y minutes.<br /> * Send notification when new chapters are created in a book.<br /> * Send notification (to admin) when a course is deleted.<br /> * Send notification (to students) that a particular activity has been updated.<br /> * Send notification (to admin) when potential security risk might happen due to change in system setting.<br /> <br /> == Future work ==<br /> <br /> * Allow events to be subscribed by only certain roles<br /> * Forced subscriptions for students for certain rules<br /> * An activity stream for messages<br /> * An facebook style notification system for notifying logged in users<br /> <br /> == See also ==<br /> <br /> * [[Event 2]]<br /> * Moodlerooms developed a &quot;[http://kb.moodlerooms.com/article/81/administrator Personalized Learning Designer]&quot; that has some of these features (mostly for individual students only).<br /> * Real time means “as soon as possible” - this depends on the cron configuration of the site. (For further information refer to [[https://docs.moodle.org/dev/Task_API#Adhoc_task_usage Adhoc tasks]])</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Event_Monitor_specification&diff=45509 2014-06-26T03:40:45Z

<p>Ankitfrenz: </p> <hr /> <div>{{Infobox Project<br /> |name = Event Monitor<br /> |state = Implementation<br /> |tracker = MDL-45758<br /> |discussion = https://moodle.org/mod/forum/discuss.php?d=261660<br /> |assignee = Ankit, Simey<br /> }}<br /> {{Work in progress|forumurl=https://moodle.org/mod/forum/discuss.php?d=261660}}<br /> The Event Monitor report will allow users to select events and receive notifications in real time* when the chosen event happens.<br /> <br /> This report will be built on top of the new [[Event 2]] infrastructure. <br /> <br /> == How it works ==<br /> <br /> * The user or site admin creates a specific set of “rules” that can be subscribed to.<br /> * Each rule defines an event and frequency parameters.<br /> * The users select the rules they are interested in and then subscribe to it at course level for a specific module or all modules.<br /> * Whenever the event occurs in the system , in the frequency specified in the rule, a message is sent out to all the subscribers.<br /> * Since we are using Moodle messaging system to send out these notifications, it can be delivered in any format supported by Moodle (Mobile notification, popup, email etc)<br /> * There would be some default rules that would be shipped with the report, that users can subscribe to straight away.<br /> <br /> === User interface mock-ups ===<br /> <br /> ==== Subscribe to a rule ====<br /> <br /> This is the main page of the Event Monitor report where users can see a list of rules and their current subscriptions. This also lets users to subscribe to new rules or delete their current subscriptions.<br /> <br /> [[File:subscriptions.png]]<br /> <br /> ==== Manage rules ====<br /> <br /> This page lets you manage the rules if you have appropriate permissions (create/edit/delete/copy)<br /> <br /> This is roughly how the page will look like:-<br /> <br /> [[File:listrules.png]]<br /> <br /> ==== Add/Edit a rule ====<br /> <br /> This is the form where users can create a new rule, customise the filters (frequency and time) and personalise the notification message.<br /> <br /> [[File:addrule.png]]<br /> <br /> === A specific example ===<br /> <br /> One scenario may be that you wish to be notified when discussions are becoming active in the forums.<br /> <br /> The figure above shows the creation of a new rule called 'My Student Discussions', which is set to monitor 'Post Created event' on 'Forum Module'. <br /> <br /> In this case, any user subscribed to this rule will receive notifications whenever '30 posts are created in 60 minutes' on the forum they are subscribed to. <br /> <br /> The notification will contain the customised message as configured in the rule.<br /> <br /> == Benefits ==<br /> <br /> * Real time monitoring of events happening in Moodle. <br /> * Admin can be notified when there is heavy activity on the site or they can monitor specific actions that interests them (ex:- course delete).<br /> * A notification can be sent straight to a user's mobile if there is a situation that needs immediate attention.<br /> * The report will be designed to trigger an event when a given subscription criteria are met. This will allow developers to build really powerful scripts on top of the report. For example, a block displaying “Hot forums”, or something more complex like load balancing when there is lot of activity in the forums or quiz.<br /> <br /> == Usage scenarios ==<br /> <br /> * Send notification when more than X posts in any forum are made in a given course in Y minutes.<br /> * Send notification when new chapters are created in a book.<br /> * Send notification (to admin) when a course is deleted.<br /> * Send notification (to students) that a particular activity has been updated.<br /> * Send notification (to admin) when potential security risk might happen due to change in system setting.<br /> <br /> == Future work ==<br /> <br /> * Allow events to be subscribed by only certain roles<br /> * Forced subscriptions for students for certain rules<br /> <br /> == See also ==<br /> <br /> * [[Event 2]]<br /> * Moodlerooms developed a &quot;[http://kb.moodlerooms.com/article/81/administrator Personalized Learning Designer]&quot; that has some of these features (mostly for individual students only).<br /> * Real time means “as soon as possible” - this depends on the cron configuration of the site. (For further information refer to [[https://docs.moodle.org/dev/Task_API#Adhoc_task_usage Adhoc tasks]])</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Event_Monitor_specification&diff=45189 2014-06-06T10:23:05Z

<p>Ankitfrenz: </p> <hr /> <div>{{Work in progress}}<br /> {{Infobox Project<br /> |name = Event Monitor<br /> |state = Specification/Prototyping<br /> |tracker = MDL-45758<br /> |discussion = https://moodle.org/mod/forum/discuss.php?d=261660<br /> |assignee = Ankit, Simey<br /> }}<br /> The Event Monitor report will allow users to select events and receive notifications in real time* when the chosen event happens.<br /> <br /> This report will be built on top of the new [[Event 2]] infrastructure. <br /> <br /> == How it works ==<br /> <br /> * The user or site admin creates a specific set of “rules” that can be subscribed to.<br /> * Each rule defines an event and frequency parameters.<br /> * The users select the rules they are interested in and then subscribe to it at course level for a specific module or all modules.<br /> * Whenever the event occurs in the system , in the frequency specified in the rule, a message is sent out to all the subscribers.<br /> * Since we are using Moodle messaging system to send out these notifications, it can be delivered in any format supported by Moodle (Mobile notification, popup, email etc)<br /> * There would be some default rules that would be shipped with the report, that users can subscribe to straight away.<br /> <br /> === User interface mock-ups ===<br /> <br /> ==== Subscribe to a rule ====<br /> <br /> This is the main page of the Event Monitor report where users can see a list of rules and their current subscriptions. This also lets users to subscribe to new rules or delete their current subscriptions.<br /> <br /> [[File:subscriptions.png]]<br /> <br /> ==== Manage rules ====<br /> <br /> This page lets you manage the rules if you have appropriate permissions (create/edit/delete/copy)<br /> <br /> This is roughly how the page will look like:-<br /> <br /> [[File:listrules.png]]<br /> <br /> ==== Add/Edit a rule ====<br /> <br /> This is the form where users can create a new rule, customise the filters (frequency and time) and personalise the notification message.<br /> <br /> [[File:addrule.png]]<br /> <br /> === A specific example ===<br /> <br /> One scenario may be that you wish to be notified when discussions are becoming active in the forums.<br /> <br /> The figure above shows the creation of a new rule called 'My Student Discussions', which is set to monitor 'Post Created event' on 'Forum Module'. <br /> <br /> In this case, any user subscribed to this rule will receive notifications whenever '30 posts are created in 60 minutes' on the forum they are subscribed to. <br /> <br /> The notification will contain the customised message as configured in the rule.<br /> <br /> == Benefits ==<br /> <br /> * Real time monitoring of events happening in Moodle. <br /> * Admin can be notified when there is heavy activity on the site or they can monitor specific actions that interests them (ex:- course delete).<br /> * A notification can be sent straight to a user's mobile if there is a situation that needs immediate attention.<br /> * The report will be designed to trigger an event when a given subscription criteria are met. This will allow developers to build really powerful scripts on top of the report. For example, a block displaying “Hot forums”, or something more complex like load balancing when there is lot of activity in the forums or quiz.<br /> <br /> == Usage scenarios ==<br /> <br /> * Send notification when more than X posts in any forum are made in a given course in Y minutes.<br /> * Send notification when new chapters are created in a book.<br /> * Send notification (to admin) when a course is deleted.<br /> * Send notification (to students) that a particular activity has been updated.<br /> * Send notification (to admin) when potential security risk might happen due to change in system setting.<br /> <br /> == See also ==<br /> <br /> * [[Event 2]]<br /> * Moodlerooms developed a &quot;[http://kb.moodlerooms.com/article/81/administrator Personalized Learning Designer]&quot; that has some of these features (mostly for individual students only).<br /> * Real time means “as soon as possible” - this depends on the cron configuration of the site. (For further information refer to [[https://docs.moodle.org/dev/Task_API#Adhoc_task_usage Adhoc tasks]])</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Event_Monitor_specification&diff=45175 2014-06-06T07:35:44Z

<p>Ankitfrenz: /* Usage scenarios */</p> <hr /> <div>{{Work in progress}}<br /> {{Infobox Project<br /> |name = Event Monitor<br /> |state = Specification/Prototyping<br /> |tracker = MDL-45758<br /> |discussion = To be created<br /> |assignee = Ankit, Simey<br /> }}<br /> The Event Monitor report will allow users to select events and receive notifications in real time* when the chosen event happens.<br /> <br /> This report will be built on top of the new [[Event 2]] infrastructure. <br /> <br /> == How it works ==<br /> <br /> * The user or site admin creates a specific set of “rules” that can be subscribed to.<br /> * Each rule defines an event and frequency parameters.<br /> * The users select the rules they are interested in and then subscribe to it at course level for a specific module or all modules.<br /> * Whenever the event occurs in the system , in the frequency specified in the rule, a message is sent out to all the subscribers.<br /> * Since we are using Moodle messaging system to send out these notifications, it can be delivered in any format supported by Moodle (Mobile notification, popup, email etc)<br /> * There would be some default rules that would be shipped with the report, that users can subscribe to straight away.<br /> <br /> === User interface mock-ups ===<br /> <br /> ==== List rules ====<br /> <br /> This is the main page of the Event Monitor report where users can see a list of rules. This page lets you subscribe/un-subscribe to the rules, and also lets you manage the rules if you have appropriate permissions (create/edit/delete/copy)<br /> <br /> This is roughly how the page will look like:-<br /> <br /> [[File:listrules.png]]<br /> <br /> ==== Add/Edit a rule ====<br /> <br /> This is the form where users can create a new rule, customise the filters (frequency and time) and personalise the notification message.<br /> <br /> [[File:addrule.png]]<br /> <br /> === A specific example ===<br /> <br /> One scenario may be that you wish to be notified when discussions are becoming active in the forums.<br /> <br /> The figure above shows the creation of a new rule called 'My Student Discussions', which is set to monitor 'Post Created event' on 'Forum Module'. <br /> <br /> In this case, any user subscribed to this rule will receive notifications whenever '30 posts are created in 60 minutes' on the forum they are subscribed to. <br /> <br /> The notification will contain the customised message as configured in the rule.<br /> <br /> == Benefits ==<br /> <br /> * Real time monitoring of events happening in Moodle. <br /> * Admin can be notified when there is heavy activity on the site or they can monitor specific actions that interests them (ex:- course delete).<br /> * A notification can be sent straight to a user's mobile if there is a situation that needs immediate attention.<br /> * The report will be designed to trigger an event when a given subscription criteria are met. This will allow developers to build really powerful scripts on top of the report. For example, a block displaying “Hot forums”, or something more complex like load balancing when there is lot of activity in the forums or quiz.<br /> <br /> == Usage scenarios ==<br /> <br /> * Send notification when more than X posts in any forum are made in a given course in Y minutes.<br /> * Send notification when new chapters are created in a book.<br /> * Send notification (to admin) when a course is deleted.<br /> * Send notification (to students) that a particular activity has been updated.<br /> * Send notification (to admin) when potential security risk might happen due to change in system setting.<br /> <br /> == See also ==<br /> <br /> * [[Event 2]]<br /> * Moodlerooms developed a &quot;[http://kb.moodlerooms.com/article/81/administrator Personalized Learning Designer]&quot; that has some of these features (mostly for individual students only).<br /> * Real time means “as soon as possible” - this depends on the cron configuration of the site. (For further information refer to [[https://docs.moodle.org/dev/Task_API#Adhoc_task_usage Adhoc tasks]])</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Event_Monitor_specification&diff=45101 2014-06-03T09:36:42Z

<p>Ankitfrenz: </p> <hr /> <div>{{Infobox Project<br /> |name = Event Monitor<br /> |state = Specification/Prototyping<br /> |tracker = MDL-45758<br /> |discussion = To be created<br /> |assignee = Ankit, Simey<br /> }}<br /> <br /> {{Work in progress}}<br /> <br /> The Event Monitor report will allow users to select events and receive notifications in real time* when the chosen event happens.<br /> <br /> This report will be built on top of the new [[Event 2]] infrastructure. <br /> <br /> == How it works ==<br /> <br /> * The user or site admin creates a specific set of “rules” that can be subscribed to.<br /> * Each rule defines an event and frequency parameters.<br /> * The users select the rules they are interested in and then subscribe to it at course level for a specific module or all modules.<br /> * Whenever the event occurs in the system , in the frequency specified in the rule, a message is sent out to all the subscribers.<br /> * Since we are using Moodle messaging system to send out these notifications, it can be delivered in any format supported by Moodle (Mobile notification, popup, email etc)<br /> * There would be some default rules that would be shipped with the report, that users can subscribe to straight away.<br /> <br /> === User interface mock-ups ===<br /> <br /> ==== List rules ====<br /> <br /> This is the main page of the Event Monitor report where users can see a list of rules. This page lets you subscribe/un-subscribe to the rules, and also lets you manage the rules if you have appropriate permissions (create/edit/delete/copy)<br /> <br /> This is roughly how the page will look like:-<br /> <br /> [[File:listrules.png]]<br /> <br /> ==== Add/Edit a rule ====<br /> <br /> This is the form where users can create a new rule, customise the filters (frequency and time) and personalise the notification message.<br /> <br /> [[File:addrule.png]]<br /> <br /> === A specific example ===<br /> <br /> One scenario may be that you wish to be notified when discussions are becoming active in the forums.<br /> <br /> The figure above shows the creation of a new rule called 'My Student Discussions', which is set to monitor 'Post Created event' on 'Forum Module'. <br /> <br /> In this case, any user subscribed to this rule will receive notifications whenever '30 posts are created in 60 minutes' on the forum they are subscribed to. <br /> <br /> The notification will contain the customised message as configured in the rule.<br /> <br /> == Benefits ==<br /> <br /> * Real time monitoring of events happening in Moodle. <br /> * Admin can be notified when there is heavy activity on the site or they can monitor specific actions that interests them (ex:- course delete).<br /> * A notification can be sent straight to a user's mobile if there is a situation that needs immediate attention.<br /> * The report will be designed to trigger an event when a given subscription criteria are met. This will allow developers to build really powerful scripts on top of the report. For example, a block displaying “Hot forums”, or something more complex like load balancing when there is lot of activity in the forums or quiz.<br /> <br /> == Usage scenarios ==<br /> <br /> * Send notification when more than X posts in any forum are made in a given course in Y minutes.<br /> * Send notification when assignment is submitted in their course.<br /> * Send notification (to admin) when a course is deleted.<br /> * Send notification (to students) that a particular activity has been updated.<br /> <br /> == See also ==<br /> <br /> * [[Event 2]]<br /> * Moodlerooms developed a &quot;[http://kb.moodlerooms.com/article/81/administrator Personalized Learning Designer]&quot; that has some of these features (mostly for individual students only).<br /> * Real time means “as soon as possible” - this depends on the cron configuration of the site. (For further information refer to [[https://docs.moodle.org/dev/Task_API#Adhoc_task_usage Adhoc tasks]])</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Event_Monitor_specification&diff=45098 2014-06-03T09:15:25Z

<p>Ankitfrenz: Add more info and some cleanup</p> <hr /> <div>{{Infobox Project<br /> |name = Event Monitor<br /> |state = Specification/Prototyping<br /> |tracker = MDL-45758<br /> |discussion = https://moodle.org/mod/forum/discuss.php<br /> |assignee = Ankit, Simey<br /> }}<br /> <br /> {{Work in progress}}<br /> <br /> The Event Monitor report will allow users to select events and receive notifications in real time* when the chosen event happens. <br /> This report will be built on top of the new [[Events_2]] infrastructure. <br /> <br /> == How it works ==<br /> * The user or site admin creates a specific set of “rules” that can be subscribed to.<br /> * Each rule defines a event and frequency parameters.<br /> * The users select the rules they are interested in and then subscribe to it at course level for a specific module or all modules.<br /> * Whenever the event occurs in the system , in the frequency specified in the rule, a message is sent out to all the subscribers.<br /> * Since we would be using Moodle messaging system to send out these notifications, it can be delivered in any format supported by Moodle (Mobile notification, popup, email etc)<br /> * There would be some default rules that would be shipped with the report, that users can subscribe to straight away.<br /> <br /> === User interface mock-ups ===<br /> <br /> ==== List rules ====<br /> <br /> This is the main page of Event Monitor where users can see list of rules. This page lets you subscribe/un-subscribe to the rules. And this also lets you manage the rules if you have appropriate permissions (create/edit/delete/copy)<br /> <br /> This is roughly how the page would look like:-<br /> [[File:listrules.png]]<br /> <br /> ==== Add/Edit a rule ====<br /> <br /> This is the form where users can create a new rule, customise the filters (frequency and time) and personalise the notification message.<br /> <br /> [[File:addrule.png]]<br /> <br /> === A specific example ===<br /> Consider the case when you want to be notified when active discussions are going on in the forums.<br /> <br /> The figure above show the creation of a new rule called 'My Student Discussions', which is set to monitor 'Post Created event' on 'Forum Module'. <br /> <br /> In this case, any user subscribed to this rule will receive notifications whenever '30 posts are created in 60 minutes' on the forum they are subscribed to. <br /> <br /> The notification will contain the customised message as configured in the rule.<br /> <br /> == Benefits ==<br /> <br /> * Real time monitoring of events happening in Moodle. <br /> * Admin can be notified when there is heavy activity on the site or they can monitor specific actions that interests them (ex:- course delete).<br /> * Notification can be sent straight to users' mobile if needed to inform them of situation that needs their immediate attention.<br /> * The report would be designed to trigger an event when a given subscription criteria are met. This will allow developers to build really powerful scripts on top of the report. For example, say a block displaying “Hot forums”, or something more complex like load balancing when there is lot of activity in the forum or quiz.<br /> <br /> == Usage scenarios ==<br /> <br /> * Send notification when more than X posts in any forum are made in a given course in Y minutes.<br /> * Send notification when assignment is submitted in their course.<br /> * Send notification (to admin) when a course is deleted.<br /> * Send notification (to students) that a particular activity has been updated.<br /> <br /> == See also ==<br /> <br /> * [[Event 2]]<br /> * Moodlerooms developed a &quot;[http://kb.moodlerooms.com/article/81/administrator Personalized Learning Designer]&quot; that has some of these features (mostly for individual students only).<br /> * Real time means “as soon as possible” - this depends on the cron configuration of the site.</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Task_API&diff=44936 2014-05-26T03:26:58Z

<p>Ankitfrenz: /* Caches */</p> <hr /> <div>{{Moodle 2.7}}<br /> <br /> {{Infobox Project<br /> |name = Task<br /> |state = Integrated<br /> |tracker = MDL-25505<br /> |discussion = https://moodle.org/mod/forum/discuss.php?d=229139<br /> |assignee = Damyon<br /> }}<br /> <br /> = Tasks =<br /> <br /> A task is a unit of work that needs to be done later. Good uses for tasks:<br /> <br /> * Run a slow operation in the background<br /> * Run a maintenance task on a regular schedule<br /> <br /> In general any operation that takes more than a few seconds should be a candidate for a task.<br /> <br /> = Benefits =<br /> <br /> * Better user experience (give them feedback immediately, that their task has been queued)<br /> * Prevent browser timeouts<br /> * Better performance for clusters (tasks can be run on separate, non-webserving cluster node, tasks can run in parallel)<br /> * Failed tasks will be retried<br /> * A better user interface will prevent users queuing multiple tasks, because they thought it had &quot;got stuck&quot;.<br /> <br /> = Types of task =<br /> <br /> == Scheduled tasks ==<br /> Scheduled tasks are tasks that will run on a regular schedule. A default schedule can be set, but admins have the ability to change the default schedule if required. Note: Tasks will only run as often as cron is run in Moodle. In 2.7 it is recommended to run cron once per minute to get the benefit from the new task scheduling (don't worry - it will do much less work each time it runs).<br /> <br /> == Adhoc tasks ==<br /> Adhoc tasks are for when you need to queue something to run in the background immediately. Adhoc tasks can contain custom data, specific to this specific instance of the task.<br /> <br /> = Usage =<br /> <br /> == Scheduled task usage ==<br /> <br /> Scheduled tasks are created by subclassing \core\task\scheduled_task. They also require an entry in &quot;db/tasks.php&quot; for your plugin.<br /> <br /> 1. Create a subclass of \core\task\scheduled_task that contains your code to run in a schedule.<br /> <br /> &lt;pre&gt;<br /> class cut_my_toe_nails extends \core\task\scheduled_task { <br /> public function get_name() {<br /> // Shown in admin screens<br /> return get_string('cutmytoenails', 'mod_hygene');<br /> }<br /> <br /> public function execute() { <br /> // apply fungus cream<br /> // apply chainsaw<br /> // apply olive oil<br /> } <br /> } <br /> &lt;/pre&gt;<br /> 2. Create entry in db/tasks.php for your plugin:<br /> &lt;pre&gt;<br /> $tasks = array( <br /> array( <br /> 'classname' =&gt; 'mod_hygene\task\cut_my_toe_nails', <br /> 'blocking' =&gt; 0, <br /> 'minute' =&gt; '*', <br /> 'hour' =&gt; '*', <br /> 'day' =&gt; '*', <br /> 'dayofweek' =&gt; '*', <br /> 'month' =&gt; '1,6' <br /> )<br /> );<br /> &lt;/pre&gt;<br /> The field required in the db/tasks.php file are:<br /> * classname - the fully namespaced classname of your task. This needs to comply with the autoloading rules. <br /> * blocking - if this is set to 1, no other scheduled task will run at the same time as this task. Do not set this to 1 unless you really need it as it will impact the performance of the task queue.<br /> * minute, hour, day, dayofweek, month - This is the default schedule for running the task. The syntax matches the syntax of unix cron. <br /> === Cron syntax examples ===<br /> * day - Day of month field for task schedule. <br /> ** &quot;*&quot; - Every day<br /> ** &quot;*/2&quot; - Every 2nd day<br /> ** &quot;1&quot; - The first of every month<br /> ** &quot;1,15&quot; - The first and fifteenth of every month<br /> * dayofweek - Day of week field for task schedule.<br /> ** &quot;*&quot; - Every day<br /> ** &quot;0&quot; - Every Sunday<br /> ** &quot;6&quot; - Every Saturday<br /> ** &quot;1,5&quot; - Every Monday and Friday<br /> * hour - Hour field for task schedule.<br /> ** &quot;*&quot; - Every hour<br /> ** &quot;*/2&quot; - Every 2 hours<br /> ** &quot;2-10&quot; - Every hour from 2am until 10am (inclusive)<br /> ** &quot;2,6,9&quot; - 2am, 6am and 9am<br /> * minute - Minute field for task schedule.<br /> ** &quot;*&quot; - Every minute<br /> ** &quot;*/5&quot; - Every 5 minutes<br /> ** &quot;2-10&quot; - Every minute between 2 and 10 minutes past the hour (inclusive)<br /> ** &quot;2,6,9&quot; - 2, 6 and 9 minutes past the hour<br /> * month - Month field for task schedule.<br /> ** &quot;*&quot; - Every month<br /> ** &quot;*/2&quot; - Every second month<br /> ** &quot;1&quot; - Every January<br /> ** &quot;1,5&quot; - Every January and May<br /> <br /> == Adhoc task usage ==<br /> <br /> This is even easier than scheduled tasks. <br /> <br /> 1. Create a subclass of \core\task\adhoc_task that contains your code to run in the background.<br /> &lt;pre&gt;<br /> <br /> class take_over_the_world extends \core\task\adhoc_task { <br /> public function execute() { <br /> // gain 100,000,000 friends on facebook.<br /> // crash the stock market.<br /> // run for president.<br /> } <br /> } <br /> <br /> &lt;/pre&gt;<br /> <br /> 2. Create an instance of the task and queue it (adding custom data if required).<br /> <br /> &lt;pre&gt;<br /> // create the instance<br /> $domination = new take_over_the_world();<br /> // set blocking if required (it probably isn't)<br /> // $domination-&gt;set_blocking(true);<br /> // add custom data<br /> $domination-&gt;set_custom_data(array(<br /> 'plansfortomorrownight' =&gt; 'The same thing we do every night, Pinky!'<br /> ));<br /> <br /> // queue it<br /> \core\task\manager::queue_adhoc_task($domination);<br /> <br /> // profit<br /> &lt;/pre&gt;<br /> <br /> 3. There is no 3.<br /> <br /> == Failures ==<br /> A task, either scheduled or adhoc can sometimes fail. An example would be updating an RSS field when the network is temporarily down. This is handled by the task system automatically - all the failing task needs to do is throw an exception. The task will be retried after 1 minute. If the task keeps failing, the retry algorithm will add more time between each successive attempts up to a max of 24 hours.<br /> <br /> == Caches ==<br /> There is one special case that needs to be considered with this new system. If a particular scheduled or adhoc task runs for a long time and updates many DB records - particularly something related to enrolment - the next task in the queue may suffer because various API's in moodle use static caching to speed up requests, but assume that the data will not change much between the start and end of the request. In this case, you can force the cron to exit after running a task that has done many DB updates. The next cron will be run in the next minute, and will have all static caches cleared because it's a new process. To do this call \core\task\manager::clear_static_caches();<br /> <br /> == Security ==<br /> When scheduling a task to run in the background - or creating a scheduled task, the task will run in the context of the cron user (see &quot;cron_setup_user()&quot;). If you need to perform access checks in your background task, you should pass the userid/context in custom_data and then pass that userid to the access check functions (&quot;require_capability('moodle/course:update', $context, $userid)&quot;).<br /> <br /> == Legacy cron ==<br /> The older syntax of cron.php or modname_cron() is still supported - but is not as good as this new API. This is because:<br /> * the legacy cron functions run serially - a long running cron in one plugin will hold up the other plugins crons<br /> * the legacy cron functions are fragile - a failure in one cron in one plugin will prevent the cron in other functions from running at all<br /> * the scheduling cannot be changed by admins<br /> <br /> = For Admins =<br /> Admins have a new screen where they can adjust the schedules for any scheduled task. They can also reset any scheduled task to it's default schedule.<br /> [[File:task_admin_screenshot.png|Screenshot of admin page]]<br /> <br /> = Specification =<br /> The specification for this feature is here: https://docs.moodle.org/dev/Scheduled_Tasks_Proposal</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Writing_log_managers&diff=44774 2014-05-12T06:17:17Z

<p>Ankitfrenz: Created page with &quot;{{Moodle 2.7}} &lt;p class=&quot;note&quot;&gt; This is an advanced developer documenation.&lt;/p&gt; For majority of sites the log manager provided with Moodle standard distribution should be suff...&quot;</p> <hr /> <div>{{Moodle 2.7}}<br /> &lt;p class=&quot;note&quot;&gt; This is an advanced developer documenation.&lt;/p&gt;<br /> For majority of sites the log manager provided with Moodle standard distribution should be sufficient, and you would rarely need to implement a new log manager. Think really hard before you decide to go for a new logmanager, You would need it only if you want to radically change the behaviour of how logs work with Moodle.<br /> <br /> So you decided to go for a new logmanager. Now let us get started with implementing it:-<br /> <br /> = You shall not pass =<br /> Writing a logmanager needs advanced understanding of how certain things work in Moodle. Please make sure you are fully familiar with following concepts and their implementation in Moodle, before moving forward:-<br /> * [[Automatic class loading]]<br /> * Namespaces<br /> * [[Event 2|Events API]]<br /> * [[Logging 2]]<br /> * [[Migrating logging calls in plugins]]<br /> * [[Migrating reports accessing logs]]<br /> <br /> = Steps to write a log manager = <br /> Although it is not required, but the best way to add a logmanager is by creating a new admin tool. Let us call this as 'mylog' admin tool.<br /> <br /> == Let us get started ==<br /> The first thing needed is a manager class that implements the interface \core\log\manager . Let us call our class as tool_mylog\log\manager which would be located in admin/tool/mylog/classes/log/manager.php<br /> &lt;code php&gt;<br /> <br /> namespace tool_mylog\log;<br /> <br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> class manager implements \core\log\manager {<br /> <br /> /**<br /> * Return list of available log readers.<br /> *<br /> * @param string $interface All returned readers must implement this interface.<br /> *<br /> * @return \core\log\reader[]<br /> */<br /> public function get_readers($interface = null) {<br /> // code for fetching instances of readers installed in the site.<br /> }<br /> <br /> /**<br /> * Dispose all initialised stores.<br /> * @return void<br /> */<br /> public function dispose() {<br /> // Dispose off all instances of stores.<br /> }<br /> <br /> /**<br /> * For a given report, returns a list of log stores that are supported.<br /> *<br /> * @param string $component component.<br /> *<br /> * @return false|array list of logstores that support the given report. It returns false if the given $component doesn't<br /> * require logstores.<br /> */<br /> public function get_supported_logstores($component) {<br /> // You can use the callback report_x_supports_logstore() here<br /> }<br /> }<br /> &lt;/code&gt;<br /> Besides those methods you might also want apis to manage writers and potentially a process to write logs using those writers. There are no core limitation on how to implement that.<br /> <br /> == I am watching you ==<br /> So we got our manager class up, but it is useless unless it monitors events. We need to setup an observer for monitoring the events we are interesed in. For this we first create a class \tool_log\mylog\observer located in admin/tool/mylog/classes/log/observer.php<br /> &lt;code php&gt;<br /> namespace tool_log\log;<br /> <br /> defined('MOODLE_INTERNAL') || die();<br /> <br /> class observer {<br /> /**<br /> * Redirect all events to this log manager, but only if this<br /> * log manager is actually used.<br /> *<br /> * @param \core\event\base $event<br /> */<br /> public static function store(\core\event\base $event) {<br /> $logmanager = get_log_manager();<br /> // Process the event.<br /> }<br /> }<br /> &lt;/code&gt;<br /> Once we got the observer in place, now we need to tell Moodle about it. We do this by adding an entry in admin/tool/mylog/db/events.php<br /> &lt;code php&gt;<br /> $observers = array(<br /> array(<br /> 'eventname' =&gt; '*',<br /> 'callback' =&gt; '\tool_mylog\log\observer::store',<br /> 'internal' =&gt; false, // This means that we get events only after transaction commit.<br /> 'priority' =&gt; 1000,<br /> ),<br /> );<br /> &lt;/code&gt; <br /> <br /> == Do you know me? == <br /> Now we need to tell Moodle about our logmanager, so it doesn't go looking for the standard manager. We do this by adding the following line to the config.php<br /> <br /> &lt;code php&gt;<br /> define('LOG_MANAGER_CLASS', '\tool_mylog\log\manager');<br /> &lt;/code&gt;</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Moodle_2.7_release_notes&diff=44566 2014-04-29T08:53:26Z

<p>Ankitfrenz: /* Interface */</p> <hr /> <div>[[Releases]] &gt; {{FULLPAGENAME}}<br /> <br /> Release date: Expected in May 2014<br /> <br /> ==Server requirements==<br /> <br /> These are just minimums. We recommend keeping all your software updated. <br /> <br /> * Moodle upgrade: Moodle 2.2 or later (if upgrading from earlier versions, you must upgrade to 2.2.11 as a first step)<br /> * Minimum Database versions: <br /> ** PostgreSQL 9.1<br /> ** MySQL 5.5.31<br /> ** MariaDB 5.5.31<br /> ** MSSQL 2008, or <br /> ** Oracle 10.2<br /> * Minimum PHP version: PHP 5.4.4 (always use latest PHP 5.4.x or 5.5.x on Windows - http://windows.php.net/download/)<br /> *Ghostscript should be installed for pdf annotation.<br /> <br /> ==Browser requirements==<br /> <br /> * Recent Google Chrome, recent Mozilla Firefox, Safari 6 or later, Internet Explorer 9 or later (IE 10 required for drag and drop of files from outside the browser into Moodle)<br /> <br /> ==Before you upgrade==<br /> <br /> Questions: In Moodle 2.1 there was a major upgrade to questions. As explained in [https://docs.moodle.org/21/en/Upgrading_to_Moodle_2.1#Planning_the_question_engine_upgrade the upgrade documentation for that version], it was possible to delay parts of the database upgrade to be run later. Before you upgrade to Moodle 2.7, this upgrade must be completed. You can check for this by looking at the bottom of the the [[:en:Environment]] check page in your site.<br /> <br /> Themes: <br /> Several core themes have been removed from Moodle 2.7 (see MDL-43784). If you wish to continue using one of these themes then it's best to reinstall it explicitly *BEFORE* running the upgrade.<br /> <br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;After burner&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_afterburner plugins db] [https://github.com/moodlehq/moodle-theme_afterburner github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Anomaly&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_anomaly plugins db] [https://github.com/moodlehq/moodle-theme_anomaly github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Arialist&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_arialist plugins db] [https://github.com/moodlehq/moodle-theme_arialist github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Binarius&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_binarius plugins db] [https://github.com/moodlehq/moodle-theme_binarius github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Boxxie&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_boxxie plugins db] [https://github.com/moodlehq/moodle-theme_boxxie github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Brick&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_brick plugins db] [https://github.com/moodlehq/moodle-theme_brick github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Formal_white&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_formal_white plugins db] [https://github.com/andreabix/moodle-theme_formal_white github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Form factor&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_formfactor plugins db] [https://github.com/moodlehq/moodle-theme_formfactor github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Fusion&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_fusion plugins db] [https://github.com/moodlehq/moodle-theme_fusion github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Leatherbound&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_leatherbound plugins db] [https://github.com/moodlehq/moodle-theme_leatherbound github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Magazine&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_magazine plugins db] [https://github.com/moodlehq/moodle-theme_magazine github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Nimble&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_nimble plugins db] [https://github.com/moodlehq/moodle-theme_nimble github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Nonzero&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_nonzero plugins db] [https://github.com/moodlehq/moodle-theme_nonzero github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Overlay&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_overlay plugins db] [https://github.com/moodlehq/moodle-theme_overlay github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Serenity&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_serenity plugins db] [https://github.com/moodlehq/moodle-theme_serenity github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Sky high&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_sky_high plugins db] [https://github.com/moodlehq/moodle-theme_sky_high github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Splash&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_splash plugins db] [https://github.com/moodlehq/moodle-theme_splash github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Standard&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_standard plugins db] [https://github.com/moodlehq/moodle-theme_standard github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Standard old&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_standardold plugins db] [https://github.com/moodlehq/moodle-theme_standardold github]<br /> <br /> ==Headline core features==<br /> <br /> ===Interface===<br /> * Atto - our new Moodle editor, tightly integrated in Moodle and focussing on usability and accessibility (TinyMCE still available as an option)<br /> * Themes clean-up - Moodle is focussed on Bootstrap and improved responsive design. Clean is now the default theme and most other old themes have been removed from core (still available from Plugins database). Many small improvements have been made all through the interface.<br /> * More - a completely new theme called More that provides easy configuration though the UI while retaining the power of LESS and Bootstrap.<br /> * Improved conditional activities - complex boolean combinations now supported, plus plugin conditions and a better interface. And faster!<br /> * Reports - User interface for loglive and log reports has been imporved with more information and filtering support (MDL-43682 and MDL-43681).<br /> <br /> ===Platform===<br /> * Logging - a new logging subsystem with plugins allowing Moodle logs to be very detailed and external. Many new events have been added which developers can take advantage of. MDL-37658 These advancements will support better analytics as well as things like TinCan.<br /> * Performance - many improvements that improve overall performance in most cases<br /> * Tasks - an improved scheduling system (like Unix cron) that allows precise scheduling of tasks even on complex clustered servers<br /> <br /> ===Long-term support (LTS) until June 2017===<br /> <br /> Most of our releases receive 1 year of backported general bug fixes and 1.5 years of security and dataloss fixes from Moodle HQ. Due to popular demand, we are committing to giving Moodle 2.7 extended support of ''''3 years security and data loss fixes'''' (that's an extra 1.5 years support).<br /> <br /> If you are stuck on an old version then this might be the perfect time to upgrade!<br /> <br /> ==Details==<br /> <br /> ===Quiz &amp; Question bank===<br /> <br /> * Quiz reports improved. MDL-41727<br /> ** Responses from all tries are available for analysis when using or &quot;Adaptive&quot;, &quot;Interactive with multiple tries&quot; or similar behaviours.<br /> ** Break-down by question variant, for question types like Calculated, STACK and Variable-numeric, which one question can have different random variants.<br /> ** Progress bar during long calculations to prevent time-outs.<br /> ** Low-level calculation code moved into the question component, where it could potentially be reused by other activities.<br /> ** Much more automated testing of this complex area of code.<br /> * Some minor improvements to the usability of the question bank - Some of MDL-40987<br /> ** To duplicate a question, you now start by clicking the x2 icon, like for activities. MDL-33653<br /> ** The various different ways to move questions in the question bank have been rationalised. MDL-33839<br /> ** There is now a 'Save changes and continue editing' button when editing questions. Useful when you are working on a complex question with the preview open in another window. MDL-33653<br /> * New plugin point, so that plugins can add columns to the question bank, or new search conditions. MDL-40313 &amp; MDL-40457<br /> * Essay questions can now require an attachment, with the text optional, rather than the other way around. MDL-39756<br /> * Random short-answer matching question type brought back from the dead. (This was in stable branches, but worth mentioning again.) MDL-27414<br /> <br /> ===Assignment===<br /> <br /> The old Assignment (2.2) module has been removed from core (MDL-33952). It has been replaced by a stub to support transparently remapping urls and restoring course backups from the old module to the new one. <br /> <br /> If you are still using the old assignment module - all instances of the old assignment module will be hidden after upgrading to Moodle 2.7. Once the upgrade tool is run on those assignments they will become visible again. <br /> <br /> It is recommended to upgrade, and then convert any remaining assignments because logic has been added to the assignment upgrade code for Moodle 2.7 to transparently map urls from the old assignment module to the new one.<br /> <br /> If you really, really need to keep using the old module, you should update the code to Moodle 2.7, and then replace the &quot;mod/assignment&quot; folder with the one from the plugins database before completing the upgrade.<br /> <br /> A new capability ''mod/assign:editothersubmission'' can be given to teachers to allow them to edit or delete student submissions.<br /> <br /> A checkbox 'Notify students' is available to control when to send feedback during the grading process.<br /> <br /> Teachers can comment directly on student's work on online text assignments MDL-34432<br /> <br /> ===Cron===<br /> <br /> Cron has received a major update and now has support for both scheduled and adhoc tasks - MDL-25499.<br /> The benefits of these changes are:<br /> * The schedule for every task can be configured by the admin<br /> * Tasks can run in parallel<br /> * Cron processes use locking to prevent the same task running at the same time by different processes<br /> <br /> A result of this is that cron can be run much more often, which means (for example) forum posts can be sent out sooner. Admins can keep cron running at the same schedule as before, but it is strongly recommended that they increase the frequency of running cron to at least once per minute.<br /> <br /> <br /> == Developer Notes ==<br /> <br /> === API changes ===<br /> * Reports: Reports that use log table, should be updated to use the new logging frame work. Old reports will continue to work as before as long as legacy logging is enabled in the site. See [[Migrating log access in reports]] for details.<br /> <br /> [[Category:Release notes]]<br /> [[Category:Moodle 2.7]]<br /> <br /> [[fr:Notes de mise à jour de Moodle 2.7]]<br /> [[es:Notas de Moodle 2.7]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Moodle_2.7_release_notes&diff=44565 2014-04-29T08:49:06Z

<p>Ankitfrenz: /* API changes */</p> <hr /> <div>[[Releases]] &gt; {{FULLPAGENAME}}<br /> <br /> Release date: Expected in May 2014<br /> <br /> ==Server requirements==<br /> <br /> These are just minimums. We recommend keeping all your software updated. <br /> <br /> * Moodle upgrade: Moodle 2.2 or later (if upgrading from earlier versions, you must upgrade to 2.2.11 as a first step)<br /> * Minimum Database versions: <br /> ** PostgreSQL 9.1<br /> ** MySQL 5.5.31<br /> ** MariaDB 5.5.31<br /> ** MSSQL 2008, or <br /> ** Oracle 10.2<br /> * Minimum PHP version: PHP 5.4.4 (always use latest PHP 5.4.x or 5.5.x on Windows - http://windows.php.net/download/)<br /> *Ghostscript should be installed for pdf annotation.<br /> <br /> ==Browser requirements==<br /> <br /> * Recent Google Chrome, recent Mozilla Firefox, Safari 6 or later, Internet Explorer 9 or later (IE 10 required for drag and drop of files from outside the browser into Moodle)<br /> <br /> ==Before you upgrade==<br /> <br /> Questions: In Moodle 2.1 there was a major upgrade to questions. As explained in [https://docs.moodle.org/21/en/Upgrading_to_Moodle_2.1#Planning_the_question_engine_upgrade the upgrade documentation for that version], it was possible to delay parts of the database upgrade to be run later. Before you upgrade to Moodle 2.7, this upgrade must be completed. You can check for this by looking at the bottom of the the [[:en:Environment]] check page in your site.<br /> <br /> Themes: <br /> Several core themes have been removed from Moodle 2.7 (see MDL-43784). If you wish to continue using one of these themes then it's best to reinstall it explicitly *BEFORE* running the upgrade.<br /> <br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;After burner&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_afterburner plugins db] [https://github.com/moodlehq/moodle-theme_afterburner github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Anomaly&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_anomaly plugins db] [https://github.com/moodlehq/moodle-theme_anomaly github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Arialist&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_arialist plugins db] [https://github.com/moodlehq/moodle-theme_arialist github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Binarius&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_binarius plugins db] [https://github.com/moodlehq/moodle-theme_binarius github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Boxxie&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_boxxie plugins db] [https://github.com/moodlehq/moodle-theme_boxxie github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Brick&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_brick plugins db] [https://github.com/moodlehq/moodle-theme_brick github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Formal_white&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_formal_white plugins db] [https://github.com/andreabix/moodle-theme_formal_white github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Form factor&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_formfactor plugins db] [https://github.com/moodlehq/moodle-theme_formfactor github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Fusion&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_fusion plugins db] [https://github.com/moodlehq/moodle-theme_fusion github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Leatherbound&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_leatherbound plugins db] [https://github.com/moodlehq/moodle-theme_leatherbound github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Magazine&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_magazine plugins db] [https://github.com/moodlehq/moodle-theme_magazine github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Nimble&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_nimble plugins db] [https://github.com/moodlehq/moodle-theme_nimble github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Nonzero&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_nonzero plugins db] [https://github.com/moodlehq/moodle-theme_nonzero github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Overlay&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_overlay plugins db] [https://github.com/moodlehq/moodle-theme_overlay github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Serenity&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_serenity plugins db] [https://github.com/moodlehq/moodle-theme_serenity github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Sky high&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_sky_high plugins db] [https://github.com/moodlehq/moodle-theme_sky_high github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Splash&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_splash plugins db] [https://github.com/moodlehq/moodle-theme_splash github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Standard&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_standard plugins db] [https://github.com/moodlehq/moodle-theme_standard github]<br /> * &lt;b style=&quot;display:inline-block; min-width: 200px;&quot;&gt;Standard old&lt;/b&gt; [https://moodle.org/plugins/view.php?plugin=theme_standardold plugins db] [https://github.com/moodlehq/moodle-theme_standardold github]<br /> <br /> ==Headline core features==<br /> <br /> ===Interface===<br /> * Atto - our new Moodle editor, tightly integrated in Moodle and focussing on usability and accessibility (TinyMCE still available as an option)<br /> * Themes clean-up - Moodle is focussed on Bootstrap and improved responsive design. Clean is now the default theme and most other old themes have been removed from core (still available from Plugins database). Many small improvements have been made all through the interface.<br /> * More - a completely new theme called More that provides easy configuration though the UI while retaining the power of LESS and Bootstrap.<br /> * Improved conditional activities - complex boolean combinations now supported, plus plugin conditions and a better interface. And faster!<br /> <br /> ===Platform===<br /> * Logging - a new logging subsystem with plugins allowing Moodle logs to be very detailed and external. Many new events have been added which developers can take advantage of. MDL-37658 These advancements will support better analytics as well as things like TinCan.<br /> * Performance - many improvements that improve overall performance in most cases<br /> * Tasks - an improved scheduling system (like Unix cron) that allows precise scheduling of tasks even on complex clustered servers<br /> <br /> ===Long-term support (LTS) until June 2017===<br /> <br /> Most of our releases receive 1 year of backported general bug fixes and 1.5 years of security and dataloss fixes from Moodle HQ. Due to popular demand, we are committing to giving Moodle 2.7 extended support of ''''3 years security and data loss fixes'''' (that's an extra 1.5 years support).<br /> <br /> If you are stuck on an old version then this might be the perfect time to upgrade!<br /> <br /> ==Details==<br /> <br /> ===Quiz &amp; Question bank===<br /> <br /> * Quiz reports improved. MDL-41727<br /> ** Responses from all tries are available for analysis when using or &quot;Adaptive&quot;, &quot;Interactive with multiple tries&quot; or similar behaviours.<br /> ** Break-down by question variant, for question types like Calculated, STACK and Variable-numeric, which one question can have different random variants.<br /> ** Progress bar during long calculations to prevent time-outs.<br /> ** Low-level calculation code moved into the question component, where it could potentially be reused by other activities.<br /> ** Much more automated testing of this complex area of code.<br /> * Some minor improvements to the usability of the question bank - Some of MDL-40987<br /> ** To duplicate a question, you now start by clicking the x2 icon, like for activities. MDL-33653<br /> ** The various different ways to move questions in the question bank have been rationalised. MDL-33839<br /> ** There is now a 'Save changes and continue editing' button when editing questions. Useful when you are working on a complex question with the preview open in another window. MDL-33653<br /> * New plugin point, so that plugins can add columns to the question bank, or new search conditions. MDL-40313 &amp; MDL-40457<br /> * Essay questions can now require an attachment, with the text optional, rather than the other way around. MDL-39756<br /> * Random short-answer matching question type brought back from the dead. (This was in stable branches, but worth mentioning again.) MDL-27414<br /> <br /> ===Assignment===<br /> <br /> The old Assignment (2.2) module has been removed from core (MDL-33952). It has been replaced by a stub to support transparently remapping urls and restoring course backups from the old module to the new one. <br /> <br /> If you are still using the old assignment module - all instances of the old assignment module will be hidden after upgrading to Moodle 2.7. Once the upgrade tool is run on those assignments they will become visible again. <br /> <br /> It is recommended to upgrade, and then convert any remaining assignments because logic has been added to the assignment upgrade code for Moodle 2.7 to transparently map urls from the old assignment module to the new one.<br /> <br /> If you really, really need to keep using the old module, you should update the code to Moodle 2.7, and then replace the &quot;mod/assignment&quot; folder with the one from the plugins database before completing the upgrade.<br /> <br /> A new capability ''mod/assign:editothersubmission'' can be given to teachers to allow them to edit or delete student submissions.<br /> <br /> A checkbox 'Notify students' is available to control when to send feedback during the grading process.<br /> <br /> Teachers can comment directly on student's work on online text assignments MDL-34432<br /> <br /> ===Cron===<br /> <br /> Cron has received a major update and now has support for both scheduled and adhoc tasks - MDL-25499.<br /> The benefits of these changes are:<br /> * The schedule for every task can be configured by the admin<br /> * Tasks can run in parallel<br /> * Cron processes use locking to prevent the same task running at the same time by different processes<br /> <br /> A result of this is that cron can be run much more often, which means (for example) forum posts can be sent out sooner. Admins can keep cron running at the same schedule as before, but it is strongly recommended that they increase the frequency of running cron to at least once per minute.<br /> <br /> <br /> == Developer Notes ==<br /> <br /> === API changes ===<br /> * Reports: Reports that use log table, should be updated to use the new logging frame work. Old reports will continue to work as before as long as legacy logging is enabled in the site. See [[Migrating log access in reports]] for details.<br /> <br /> [[Category:Release notes]]<br /> [[Category:Moodle 2.7]]<br /> <br /> [[fr:Notes de mise à jour de Moodle 2.7]]<br /> [[es:Notas de Moodle 2.7]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Logging_2&diff=44550 2014-04-29T02:08:29Z

<p>Ankitfrenz: /* Mockups */</p> <hr /> <div>{{Infobox Project<br /> |name = Logging stage 2<br /> |state = Completed<br /> |tracker = MDL-37658<br /> |discussion = https://moodle.org/mod/forum/discuss.php?d=235318<br /> |assignee = moodle.com BACKEND team<br /> }}<br /> <br /> = Benefits of the new logging system =<br /> A few benefits of the new logging system are :-<br /> * allows for capturing of richer information from plugins/core about actions;<br /> * provides control over how much information is logged;<br /> * abstracts log writing and reading so logging can be scaled;<br /> * lets you write/read logs from any external system by the use of logstore plugins;<br /> * control how much logging history is kept; and<br /> * support research, reporting and analytics.<br /> <br /> == Why is Logging an important topic? ==<br /> <br /> Logging is fundamental to research, reporting and analytics. <br /> <br /> Not much of new Moodle development is based on measured data. We need to be able to:<br /> * prove there is a problem and<br /> * prove that a given change is an improvement.<br /> <br /> Logging data can be used by different Moodle users.<br /> *Better data would allow researchers to study what happens in online teaching.<br /> *Better data would give admins more feedback on how to run their site - both technically and process (please note this issue is not about profiling).<br /> *Better data would give teachers better feedback to improve their teaching process.<br /> *Better data would give students better feedback to improve their learning.<br /> <br /> We can't predict all forms of analysis that might happen in future.<br /> * The logging system needs to be flexible in order to accommodate applications by these different users.<br /> * The logging API needs to be constructed in a way that is possible to improve in future.<br /> <br /> == Problems with old logging ==<br /> <br /> The old logging infrastructure had a number of issues that were resolved by this project. A few of these are:-<br /> <br /> * Logging was added ad-hoc by developers and has spotty coverage.<br /> * Some logged actions did not contain important information needed later.<br /> * There were performance and scalability problems, such as:<br /> ** log tables were joined in many popular queries and were slow;<br /> ** all logs used to go to one standard moodle database table, which was not scalable;<br /> ** it was not possible to configure level of logging ; and<br /> ** it was not possible to disable logging completely.<br /> <br /> = Logging =<br /> <br /> The new [[Event 2|Events API]] introduced in Moodle 2.6 provides a notification mechanism and single collection point for actions within Moodle. The Events system also defines information about events that can be extended with additional information and functionality by core code and plugins, as needed.<br /> <br /> In order to capture events a logging API was specified, consisting of a number of plugin types.<br /> <br /> To transition from the old logging system to the new, work was required in a number of areas.<br /> <br /> * In places where we previously added information to 'the' log table, we must instead generate a new event.<br /> * The standard Moodle distribution now includes 2 simple DB logging storage plugin that will store events in new format (internal and external database)<br /> * The original logging code and DB tables are available for full backwards compatibility for users of customised reports. It is possible to enable logging to the old {log} table if required.<br /> * All standard reports have been upgraded to use the new logging system and uses logging retrieval plugin to access log information.<br /> * Custom report plugins (add-ons) will be able to query the {log} table, but should ideally shift to the new logging system over time, so that sites are not forced to continue double logging.<br /> <br /> == Old log usage analysis ==<br /> <br /> See [[Logging_usage|this analysis]] to see log usage in Moodle 2.5 core code.<br /> <br /> == Example scenario ==<br /> <br /> '''Writing to the log'''<br /> <br /> # A student submits an assignment.<br /> # An event is triggered by the Assignment module.<br /> # The log manager plugin observes the event and determines if it is log-worthy depending on some admin settings.<br /> # The log manager sends the event to all enabled log storage subplugins implementing \tool_log\log\writer. Storage plugins may decide to filter out some events based on their admin settings.<br /> # The log store plugin(s) stores the event data optionally including extra information such as remote IP or original logged-in-as user id.<br /> <br /> '''Reading from the log'''<br /> <br /> # A teacher opens activity report.<br /> # Activity reports queries available log readers from the current log manager (implementing \core\log\manager).<br /> # If there is more than one log reader (implementing \core\log\sql_select_reader) available they can select the source of data for the report.<br /> # A teacher requests report of student assignment submissions.<br /> # The report requests events from the log reader and displays them.<br /> <br /> == From event to report ==<br /> <br /> There are four steps of how event is captured, logged and potentially presented in a report. These steps are summarised in [[#Figure1|Figure 1]] below and can be described as follows.<br /> <br /> # Handling of events and filtering what needs to be logged. See interface \core\log\manager below.<br /> # Storing the events data in the log storage (DB, filesystem, etc.). See interface \tool_log\log\writer below.<br /> # Retrieving the data from log storage - each plugin implements some methods to query and extract logs back to Moodle. See interfaces \core\log\reader and \core\log\sql_reader below.<br /> # Displaying the data in the report.<br /> <br /> One plugin may cover multiple steps. For example we expect that most of log writer plugins will also implement log reader. It is also possible to create a report that has built-in event handling, log writing and reading and report presentation (all four steps). Also external logging systems may not wish to allow log data they capture to be reported within Moodle, handling it through an external system, so they may not implement steps 3 and 4 at all.<br /> <br /> &lt;div id=&quot;Figure1&quot; style=&quot;text-align:center&quot;&gt;<br /> [[File:logging_plugins_relation.png]]<br /> '''Figure 1. Logging plugins relationship diagram'''&lt;/div&gt;<br /> <br /> The [[#Figure2|Figure 2]] below shows how the requests are made between user actions, plugins and core when:<br /> <br /> * configuring logging - which log writer plugins are enabled<br /> * event occurs<br /> * report - selecting log store<br /> * viewing report<br /> <br /> &lt;div id=&quot;Figure2&quot; style=&quot;text-align:center&quot;&gt;<br /> [[Image:logging_sequence.png|logging_sequence.png]]<br /> '''Figure 2. Logging plugins sequence diagram'''&lt;/div&gt;<br /> <br /> == Public API ==<br /> <br /> This section describes all interfaces that need to be implemented by log manager and each log storage class.<br /> <br /> === Reading API ===<br /> * '''function \get_log_manager()''' - returns the current log manager if configured or some dummy instance otherwise, it uses the signleton pattern.<br /> * '''interface \core\log\manager''' - log manager interface, in standard distribution implemented by \tool_log\log\manager and \core\log\dummy_manager<br /> ** public function get_readers($interface = null) returns the active storages implementing reader interface, returns array(classname =&gt; storage instance, ...)<br /> * '''interface \core\log\reader''' - general event reader<br /> ** public function get_name() - returns name of the log storage, this will be used when selection data source in reports.<br /> ** public function get_description() - some help for admins.<br /> ** public function is_logging() - is latest data available?<br /> * '''interface \core\log\sql_select_reader''' extends \core\log\reader - general log storage that supports sql selects (or emulates them)<br /> ** public function get_events_select($selectwhere, array $params, $order, $limitfrom, $limitnum) - returns event object instances matching given parameters.<br /> ** public function get_events_select_count($selectwhere, array $params) - returns number of events that would be returned from get_events() with the same parameters.<br /> *** $selectwhere is supposed to be a limited sql predicate.<br /> *** The set of operators allowed in $selectwhere are :- =, &lt;&gt;, &gt;, &gt;=, &lt;, &lt;=<br /> *** The set of keywords allowed in $selectwhere are :- IN, BETWEEN, LIKE, IS NULL, IS NOT NULL<br /> *** Logical operators OR, AND<br /> *** NOT operator<br /> *** ( and ) brackets<br /> *** ? and :named parameter placeholders <br /> *** Use of anything besides the mentioned keywords/operators is strictly forbidden.<br /> * '''interface \core\log\sql_internal_reader''' extends \core\log\reader - log storage that can expose data as read-only database view or table.<br /> ** public function get_internal_log_table_name() - returns database table or view; structure is described in phpdocs, it will include all columns defined by log_sql<br /> <br /> Reports are expected to use only the reading API. Please note that all non-sql readers need to somehow translate the $selectwhere SQL query syntax.<br /> <br /> When reports are searching for log readers they use the get_log_manager()-&gt;get_readers($interface = null) where $interface is the name of reader interface that the report supports.<br /> If there are multiple readers returned by the log manager, then the report is responsible for letting the user choose which storage to create the report on.<br /> <br /> === Writing API ===<br /> * '''interface \tool_log\log\store''' - must be implemented by each store subplugin.<br /> ** public function __construct(\tool_log\log\manager $manager) - no parameters, configuration is taken from admin settings.<br /> ** public function dispose() - called when reading/writing finished.<br /> * '''interface \tool_log\log\writer''' extends \tool_log\log\store - interface indicating the log store may be used for writing.<br /> ** public function write(\core\event\base $event) - called from event observer defined in log manager.<br /> <br /> The writing API is defined in tool_log plugin, the log stores are defined as new subplugin of this plugin.<br /> <br /> Each log store plugin will be responsible for filtering of events, it may use standardised admin settings and filtering or decide to implement custom filtering.<br /> <br /> == Standard logging plugins ==<br /> <br /> Standard Moodle distribution will include four plugins.<br /> <br /> === Logging management plugin (tool_log) ===<br /> <br /> Defines:<br /> <br /> class \tool_log\log\manager implements \core\log\manager;<br /> <br /> The log manager is responsible for step 1 from [[#Figure1|Figure 1]] above. It allows admins to configure which log store subplugin is enabled and in which order they appear. The log store plugins are implemented as tool_log subplugins with class &quot;store&quot; in their namespace (\logstore_xxxx\log\store).<br /> <br /> The log manager registers a '*' event observer, this observer is external - it means that events are received only when database transactions are not in progress.<br /> <br /> === Standard log storage plugin (logstore_standard) ===<br /> <br /> Defines:<br /> <br /> class \logstore_standard\log\store implements \core\log\sql_internal_reader, \tool_log\log\writer;<br /> <br /> The name logstore_standard does not seem to be optimal - ''logstore_db'' is not allowed because it collides with standard /db/ subdirectory in plugins and ''logstore_database'' should be probably reserved for external database logging (to prevent any confusion).<br /> <br /> This log storage plugin is responsible for steps 2 and 3 from [[#Figure1|Figure 1]] above. It is the primary replacement for the former {log} table. The performance will be similar to former log table, but for smaller sites, this simple default will suffice.<br /> <br /> Each plugin decides how much data is kept, when it is deleted, etc.<br /> <br /> ==== Storage settings ====<br /> <br /> Each storage plugin with writer interface is responsible for backlisting or filtering of events. Some of the examples of filtering that can done is as below:-<br /> * Include guests actions (default ''Yes'').<br /> * Include log levels (default ''empty''), accepts constants from [[Event_2#Level_property]].<br /> * Include by CRUD (default ''empty''), accepts C, R, U, and D.<br /> * Include by component (default ''empty'')<br /> * Include by event name (default ''empty'')<br /> <br /> === External database log storage plugin (logstore_database) ===<br /> <br /> Defines:<br /> <br /> class \logstore_database\log\store implements \core\log\sql_select_reader, \tool_log\log\writer;<br /> <br /> This log storage plugin is responsible for step 2 only from [[#Figure1|Figure 1]] above. There will be no interface to read from it provided with Moodle core.<br /> <br /> === Legacy log table reader (logstore_legacy) ===<br /> <br /> Defines:<br /> <br /> class \logstore_legacy\log\store implements \core\log\sql_select_reader, \tool_log\log\store;<br /> <br /> This plugin will not conduct any log writing; it will translate existing {log} table data into the new event format and transforms new SQL selects to match the legacy table format. This serves as an emulation layer that allows new reports to access historical data stored in mdl_log table. Users will have to select this datasource manually if they want to see historical data that is not present in new log tables.<br /> <br /> In new reports the legacy data will be presented using a special legacy event class that can not be triggered: \logstore_legacy\event\legacy<br /> <br /> == Performance ==<br /> <br /> Compared to older Moodle version the new system will need to deal with higher number of log entries. This was improved by buffering of log entries together with new improved bulk insert operations in the DML layer. Helper traits were introduced \tool_log\helper\buffered_writer to help stores easily buffer the events.<br /> <br /> Running new and old event logging at the same time with result in 2x number of DB inserts, it will be therefore recommended to disable the old logging as soon as possible.<br /> <br /> In [https://tracker.moodle.org/browse/MDL-42894 MDL-42894], logging api comparison is done and it seems promising. Results are:<br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Enabled Stores<br /> ! dbwrites<br /> ! dbreads<br /> ! Time used<br /> ! Session size<br /> ! Memory<br /> ! Server load<br /> |-<br /> | Legacy + Standard store<br /> | Little increase<br /> | Same<br /> | Same<br /> | Same<br /> | Same<br /> | Increased<br /> |-<br /> | Only Standard store<br /> | Decrease<br /> | Same<br /> | Same<br /> | Same<br /> | Same<br /> | Increased<br /> |-<br /> | Only Legacy store<br /> | Same<br /> | Same<br /> | Same<br /> | Same<br /> | Same<br /> | Decrease<br /> |-<br /> | Neither Legacy nor Standard store<br /> | Decrease<br /> | Same<br /> | Same<br /> | Same<br /> | Same<br /> | Decrease<br /> |}<br /> FYI: Serverload is showing worse in most cases, but as this was done on my local machine with all interference, I am ignoring this for now.<br /> --[[User:Rajesh Taneja|Rajesh Taneja]] ([[User talk:Rajesh Taneja|talk]]) 16:19, 14 February 2014 (WST)<br /> <br /> == Screenshots ==<br /> === Log management page ===<br /> [[File:event-observer.png |frame|center| Log management page]]<br /> <br /> === Log store settings pages ===<br /> [[File:event-observer-2.png |frame|center| settings page for a the standard log setup]]<br /> [[File:external-log-settings.png |frame|center| settings page for an external log: Database setup]]<br /> [[File:external-filter-logs.png |frame|center| settings page for an external log: Filtering]]<br /> <br /> == Overarching considerations ==<br /> <br /> We can't actually predict all use cases, so we must think generically and plan for worst cases. Here are some overarching principles that will be followed in the implementation of the new logging system.<br /> <br /> * Things that don't need to use logs should not use logs. (Recent activity, etc)<br /> * Logging calls should be as cheap as possible.<br /> * The Events API will be the central communication mechanism, allowing lots of potential information gathering tools to exist in future.<br /> * Use plug-ins to determine where to put logs permanently (NoSQL, SAS, file...). Initially, the default will be to the current log table.<br /> * Log everything we possibly can think of.<br /> * Define log level settings (on each logging call) so different sites can choose what they want logged, which allows controls cotrol of log size, speed, etc..<br /> * Function add_to_log should be retained for backward compatibility, without changing existing implementation, but allowing admins to disable it.<br /> <br /> = Reports =<br /> <br /> [[Logging usage#Reports]] describes current reports.<br /> <br /> = Migration to new logging API =<br /> <br /> == Follow-up Projects ==<br /> <br /> * Converting completion to use events - MDL-42897<br /> * Developing a ''Timeline'' page/block so each user to see a stream of activity that is relevant to them individually - MDL-42898<br /> <br /> == Related ==<br /> <br /> '''Here are some ideas of how new even data and observers can be put to use:'''<br /> <br /> * Please note that the log storage API is not optimised for these tasks.<br /> * Timely notifications of critical events (defined by users), for example more than five people posted in the same forum within an hour.<br /> * &quot;Red circle&quot; notification badge counter icons everywhere in Moodle highlighting things that a user needs to pay attention attention to, such as ???.<br /> * Colour heatmaps overlaid on course pages showing recent usage patterns of the course.<br /> * Visualisation of live activity across a whole site (for admins) (is that logging or event handling?)<br /> * Live engagement analytics reporting ??? that take specific actions into account, such as ???.<br /> * Identification of students at risk based on their involvement in the course (or lack of it).<br /> <br /> '''Logging of exceptions, errors and debugging:'''<br /> <br /> * Logging of Errors and warnings is not part of this specification, it meeds to be handled via a completely separate mechanism.<br /> ** People report errors that cannot be duplicated. Logging errors with a stack trace, session variables and other relevant data could be useful for debugging.<br /> * Standard logs may theoretically produce errors and exceptions that need to be logged somewhere else.<br /> * There is no synchronization with server logs to help debugging performance issues. (This will not be addressed by new logging API.)<br /> * There is no logging of error information to help debug Moodle issues. (This will not be addressed by new logging API.)<br /> <br /> '''Performance logging and profiling'''<br /> <br /> We need to measure the performance of logging system and store the information somewhere.<br /> <br /> '''Other'''<br /> <br /> * There is no mechanism for archiving, so old logs are deleted and lost.<br /> * Log deletion is indiscriminate, with no control of what log information is deleted or retained.<br /> <br /> == Places where we need more logs ==<br /> <br /> The principle work of this project is to replace the existing logging API. Once the new system is in place, the coverage of logging around Moodle can be improved.<br /> <br /> Suggestions for places in Moodle where logging is needed should be reported as Tracker issues and linked to the Epic MDL-28443 &quot;Action logging improvements&quot;. Feel free to echo significant areas here.<br /> <br /> * Activities on site, course and activity administration pages.<br /> * Micro activities in a page (more than one per load), such as ???.<br /> * AJAX calls (eg on course page), such as ???.<br /> * Logging of long events (such as an LDAP synchronisation) should have:<br /> ** one unique identifier per event (like for example postfix mail server) to help admin monitor the cron processes and<br /> ** at least 2 log entries (begining and end) for each event, possibly more.<br /> * Should be careful about logging confidential information. Anonymous events can be used to controll privacy.<br /> * Shouldn’t delete logs when course is deleted. There is no API to delete logs, each log storage controls the rotation or deleting of old data individually.<br /> <br /> =See also=<br /> <br /> * [[Event 2]]<br /> * [[Migrating logging calls in plugins]]<br /> * [[Migrating reports accessing logs]]<br /> <br /> Other logging systems:<br /> * http://logstash.net/ <br /> * http://fluentd.org/<br /> * http://logging.apache.org/log4php/<br /> <br /> Examples of data-based learning technology development:<br /> * http://onlinelibrary.wiley.com/doi/10.1111/j.1467-8535.2008.00928.x/abstract <br /> * http://www.sciencedirect.com/science/article/pii/S0360131510000461 -&gt; qtype_pmatch<br /> * http://www.tandfonline.com/doi/abs/10.1080/02680513.2011.567754<br /> * http://oro.open.ac.uk/24619/<br /> * [http://www.adlnet.gov/tla/lrs/ A Learning Record Store (LRS)] is a system that stores the tracking statements communicated through the [https://github.com/adlnet/xAPI-Spec Experience API (xAPI)]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=File:external-log-settings.png&diff=44549 2014-04-29T02:07:00Z

<p>Ankitfrenz: Ankitfrenz uploaded a new version of &amp;quot;File:external-log-settings.png&amp;quot;</p> <hr /> <div></div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Migrating_logging_calls_in_plugins&diff=44548 2014-04-29T01:46:36Z

<p>Ankitfrenz: /* init() and create() */</p> <hr /> <div>This document is aimed to assist developers in replacing existing '''add_to_log()''' and '''events_trigger()''' calls with events. This can be implemented in Moodle 2.6 and will be required in 2.7.<br /> <br /> As a quick reminder: [[Event 2|new events]] were introduced in Moodle 2.6, a new [[Logging 2|logging system]] is being introduced in Moodle 2.7. The '''add_to_log()''' function will be deprecated, but the existing log table will still be present with existing data intact. This original logging is now called ''legacy logging''. The new and legacy logging may coexist in the legacy logging system for purposes of transition, but this is not recommended for performance reasons. When replacing calls to add_to_log() with the triggering of an event, developers must ensure that they also generate an entry for the legacy log. It will only be used if the legacy log is enabled, since it may be enabled on systems that continue to use custom reports relying on presence of the legacy log table and it may take time to migrate such reports.<br /> <br /> == Quick guide ==<br /> <br /> If you are replacing common add_to_log() calls such as &quot;view&quot; and &quot;view all&quot; in mod/XXX/view.php and mod/XXX/index.php, see below. Otherwise do the following.<br /> <br /> === Step 1. Choose a name for the event ===<br /> <br /> Names should follow the syntax OBJECT_VERB, for example &quot;entry_added&quot;, &quot;work_submitted&quot;, etc. It does not need to include a plugin name because this can be obtained from the PHP class namespace. See [[Event 2|the events documentation]] for more details about events names.<br /> <br /> Define a language string for the event name in '''YOURPLUGINDIR/lang/en/FULLPLUGINNAME.php'''.<br /> &lt;code php&gt;<br /> $string['eventEVENTNAME] = 'Something has happened';<br /> &lt;/code&gt;<br /> <br /> === Step 2. Create event class ===<br /> <br /> For each event you must create an event class in '''YOURPLUGINDIR/classes/event/EVENTNAME.php''', with the following format.<br /> &lt;code php&gt;<br /> namespace FULLPLUGINNAME\event;<br /> defined('MOODLE_INTERNAL') || die();<br /> class EVENTNAME extends \core\event\base {<br /> protected function init() {<br /> $this-&gt;data['crud'] = 'c'; // c(reate), r(ead), u(pdate), d(elete)<br /> $this-&gt;data['edulevel'] = self::LEVEL_PARTICIPATING;<br /> $this-&gt;data['objecttable'] = '...';<br /> }<br /> <br /> public static function get_name() {<br /> return get_string('eventEVENTNAME', 'FULLPLUGINNAME');<br /> }<br /> <br /> public function get_description() {<br /> return &quot;User {$this-&gt;userid} has ... ... ... with id {$this-&gt;objectid}.&quot;;<br /> }<br /> <br /> public function get_url() {<br /> return new \moodle_url('....', array('parameter' =&gt; 'value', ...));<br /> }<br /> <br /> public function get_legacy_logdata() {<br /> // Override if you are migrating an add_to_log() call.<br /> return array($this-&gt;courseid, 'PLUGINNAME', 'LOGACTION',<br /> '...........',<br /> $this-&gt;objectid, $this-&gt;contextinstanceid);<br /> }<br /> <br /> public static function get_legacy_eventname() {<br /> // Override ONLY if you are migrating events_trigger() call.<br /> return 'MYPLUGIN_OLD_EVENT_NAME';<br /> }<br /> <br /> protected function get_legacy_eventdata() {<br /> // Override if you migrating events_trigger() call.<br /> $data = new \stdClass();<br /> $data-&gt;id = $this-&gt;objectid;<br /> $data-&gt;userid = $this-&gt;relateduserid;<br /> return $data;<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> === Step 3. Trigger the event instead of add_to_log() ===<br /> <br /> Replace the add_to_log() with an event trigger. The following is a common example of an event trigger inside an activity module.<br /> &lt;code php&gt;<br /> add_to_log($course-&gt;id, 'PLUGINNAME', 'LOGACTION', '...........', $objid, $cmid);<br /> &lt;/code&gt;<br /> <br /> ...becomes...<br /> <br /> &lt;code php&gt;<br /> $event = \FULLPLUGINNAME\event\EVENTNAME::create(array(<br /> 'objectid' =&gt; $objid,<br /> 'context' =&gt; context_module::instance($cmid)<br /> ));<br /> $event-&gt;trigger();<br /> &lt;/code&gt;<br /> <br /> If you need to trigger event multiple times in the code or just prefer shorter syntax you can declare your own static create function in the event class that would populate necessary fields and even add snapshots (see examples in mod_assign). In this case you can triger event in one line:<br /> <br /> &lt;code php&gt;<br /> \FULLPLUGINNAME\event\EVENTNAME::create_from_someobject($someobject)-&gt;trigger();<br /> &lt;/code&gt;<br /> <br /> ===Step 4. Increase the version number in version.php===<br /> <br /> The events that exist are only scanned when a plugin is installed or updated. Therefore when you change events, you need to increase version.php for you plugin.<br /> <br /> == Replacing 'view' events in modules ==<br /> <br /> Calls to add_to_log() to report a 'view' event are usually found in mod/PLUGINNAME/view.php (or in a lib function included by this file) and indicate that a user viewed the module. <br /> <br /> === Step 1. Choosing the name ===<br /> <br /> Because this is a common event, the name is already chosen: '''course_module_viewed''' and the language string is defined in core.<br /> <br /> === Step 2. Defining class ===<br /> <br /> You must create a class for this event in '''YOURPLUGINDIR/classes/event/course_module_viewed.php''' with the following format.<br /> &lt;code php&gt;<br /> namespace FULLPLUGINNAME\event;<br /> defined('MOODLE_INTERNAL') || die();<br /> class course_module_viewed extends \core\event\course_module_viewed {<br /> protected function init() {<br /> $this-&gt;data['objecttable'] = 'PLUGINNAME';<br /> parent::init();<br /> }<br /> // You might need to override get_url() and get_legacy_log_data() if view mode needs to be stored as well.<br /> }<br /> &lt;/code&gt;<br /> <br /> === Step 3. Triggering the event ===<br /> <br /> This example takes data from $PAGE object but you may substitute this with ids and objects that you have fetched.<br /> &lt;code php&gt;<br /> $event = \FULLPLUGINNAME\event\course_module_viewed::create(array(<br /> 'objectid' =&gt; $PAGE-&gt;cm-&gt;instance,<br /> 'context' =&gt; $PAGE-&gt;context,<br /> ));<br /> $event-&gt;add_record_snapshot('course', $PAGE-&gt;course);<br /> // In the next line you can use $PAGE-&gt;activityrecord if you have set it, or skip this line if you don't have a record.<br /> $event-&gt;add_record_snapshot($PAGE-&gt;cm-&gt;modname, $activityrecord);<br /> $event-&gt;trigger();<br /> &lt;/code&gt;<br /> <br /> ===Step 4. Update version.php===<br /> Don't forget to update the plugin version number.<br /> <br /> == Replacing 'view all' events in modules ==<br /> <br /> Calls to add_to_log using 'view_all' are usually found in mod/PLUGINNAME/index.php (or in a lib function included by this file). These invents indicate that a user viewed the list of all instances of this module within the course. <br /> <br /> === Step 1. Choosing the name ===<br /> <br /> Because this is a common event, the name is already chosen: '''course_module_instance_list_viewed''' and the language string is defined in core.<br /> <br /> === Step 2. Defining class ===<br /> <br /> You must create a class for this event in '''YOURPLUGINDIR/classes/event/course_module_instance_list_viewed.php''' with the following structure.<br /> &lt;code php&gt;<br /> namespace FULLPLUGINNAME\event;<br /> defined('MOODLE_INTERNAL') || die();<br /> class course_module_instance_list_viewed extends \core\event\course_module_instance_list_viewed {<br /> }<br /> &lt;/code&gt;<br /> <br /> === Step 3. Triggering the event ===<br /> <br /> &lt;code php&gt;<br /> $event = \FULLPLUGINNAME\event\course_module_instance_list_viewed::create(array(<br /> 'context' =&gt; context_course::instance($course-&gt;id)<br /> ));<br /> $event-&gt;trigger();<br /> &lt;/code&gt;<br /> <br /> == What to include in the event ==<br /> <br /> === init() and create() ===<br /> <br /> Ideally all information needed when initialising and triggering events should already be available without having to run additional queries. Queries run to fill event objects with data will cause additional performance load, which should be avoided. Information that needs to be gathered from the database should be provided by other event methods, which can be called selectively when needed.<br /> <br /> As you noticed in the examples above you can specify additional properties either by the overriding the init() method of the event or when calling create(). The first way is used for properties that are always the same for this event, the second is for dynamic properties that may differ when the event is triggered.<br /> <br /> Usually you need to include the following properties.<br /> {| class=&quot;nicetable&quot;<br /> |-<br /> | '''context''' or '''contextid'''<br /> | required<br /> | Describes the context where the event took place.<br /> | If you want to hardcode the system context, do so in init().<br /> |-<br /> | '''crud'''<br /> | required<br /> | Describes whether the event reflects creation (c), reading (r), updating (u) or deleting (d). This should be a single character string.<br /> | Most often are specified in init().<br /> |-<br /> | '''edulevel'''<br /> | required<br /> | The level of educational value of the event. Can be LEVEL_TEACHING, LEVEL_PARTICIPATING or LEVEL_OTHER.<br /> | Most often are specified in init().<br /> |-<br /> | '''objecttable''' and '''objectid'''<br /> | <br /> | Objecttable is the table that represents the event object to the best, ideally it is the object where the &quot;CRUD&quot; action was performend. Used by events that show the change in one record of one table, which will be the case for the most events.<br /> | Since 'objecttable' is always the same it is usually specified in init().<br /> |-<br /> | '''relateduserid'''<br /> | <br /> | The id of the user affected by the event.<br /> | Only used if it is easy to identify a single user who is affected by this operation. For example a user who is being graded, a user who receives the message, a user being enrolled, etc. '''This is NOT the user who performs the action''' (who is identified in the userid field).<br /> |-<br /> | '''other'''<br /> | <br /> | Everything else that you may think is important about this event. This property will be serialised and stored by loggers.<br /> | Include only necessary information. It can be used in get_description(), get_url() and get_legacy_logdata(). This property should only contain an array or scalar value, it '''can not use objects'''.<br /> Example of information stored in 'other' can be found in event course_module_deleted:<br /> * Definition: https://github.com/moodle/moodle/blob/master/lib/classes/event/course_module_deleted.php#L69<br /> * Triggering: https://github.com/moodle/moodle/blob/master/course/lib.php#L1716..L1727<br /> |}<br /> <br /> Usually you don't need to include the following properties as they are deduced by the base class.<br /> * 'userid': user who performs the action, taken from $USER<br /> * 'courseid': course affected in the operation, which will be taken from context. It need not be specified at all for events that are not related to a particular course.<br /> <br /> See the [[Event_2#Information_contained_in_events|full list of properties]] for more information.<br /> <br /> === get_legacy_logdata() ===<br /> <br /> This method is used to add log data to the legacy log. You need only override this method when replacing an add_to_log() call. Since this document is a transition guide from add_to_log() to events, you will most likely need to override this method. This method needs to return an array (with 3-7 elements) that imitates the arguments that used to be passed to the add_to_log() function. From Moodle 2.7, the get_legacy_logdata() method will only be called if legacy logging is enabled through the legacy logging plugin.<br /> <br /> === get_description() and get_url() ===<br /> <br /> Most reporting tools will display aggregated event information (for example the count of student logins) so those methods, which describe individual events, are not likely to be called often; they will only be used by detailed reports such as loglive. At the moment, use get_description() to provide a very brief internal description of the action performed, so that it can be used for error recovery like any other system log. The description is hard-coded in English but it may be possible that future versions of Moodle (2.8 or later) will allow the use of translatable language strings. These methods should not make DB queries, access global variables, etc. For example, when a course is renamed or when a user is deleted, do not retrieve the course name or user name, instead simply use their ids. These functions should return exactly the same result whenever they are called, regardless of the environment or state, even after they have been restored from logs. <br /> <br /> === get_legacy_eventname() and get_legacy_eventdata() ===<br /> <br /> You will need to override these two functions if you are upgrading events_trigger() calls. These will allow legacy plugins to continue to listen to your new events without upgrading their listeners.<br /> <br /> If you need to provide more detailed information to observers, you can choose to:<br /> * add more information to 'other', but remember that this will be logged and it's better to keep logs as small as possible;<br /> * use record snapshots, which are especially useful for delete actions (you can call get_record_snapshot() inside get_legacy_eventdata() and observers are encouraged to get data from snapshots as well);<br /> * add new properties to your event class and define getter/setter functions, for example set_custom_data() and get_custom_data().<br /> <br /> === add_record_snapshot() ===<br /> <br /> A record snapshot can be added for any DB table related to the event. If it is added it must be an instance of stdClass containing all fields that are present in the corresponding DB table. You must add a record snapshot when you delete something from database. '''Record snapshots cannot be used from reports, it is intended for event observers only.''' Usually observers expect record snapshot identified by 'objecttable' and 'objectid' but developer may also add snapshot of related tables, i.e. when book chapter is updated the developer may decide to add snapshots of related records in tables book_chapters, book, course_modules and course. <br /> <br /> Record snapshots should be added only when you already have an object and do not need to perform any additional DB queries to retrieve it. Otherwise omit it, as the record will be retrieved by get_record_snapshot() automatically, and only if needed. For performance reasons the snapshots are not guaranteed to contain an exact state at the time of event triggering, it may be actually fetched at any time between the triggering of event and its observation.<br /> <br /> == Events DON'Ts ==<br /> <br /> Do not put more information in 'other' than is needed. For example, do not include a full DB record for delete/create operations or a list of all changed properties in edit operations. If observers are interested in this information, it can requested by calling get_record_snapshot(). Never include large text fields in event data. '''Please help to keep the log size reasonable.'''<br /> <br /> Do NOT use $USER, $COURSE, $PAGE or other global variables when overriding get_* methods (with the exception of get_legacy_eventdata).<br /> <br /> Do NOT call $this-&gt;get_record_snapshot() inside the event class (again with the exception of get_legacy_eventdata). If you need additional information for internal functions that cannot be added to existing properties, add it to the 'other' property.<br /> <br /> Do NOT use $this-&gt;context inside an event class. '''Remember that methods get_description() and get_url() may be called on events after they have been restored from logs.''' It is possible that the original context no longer exists when these functions are called. Instead use $this-&gt;contextid, $this-&gt;contextlevel, $this-&gt;contextinstanceid.<br /> <br /> == Validation and testing ==<br /> <br /> You may notice that the most of events in Moodle also have function validate_data() . You can add this function for your own safety to ensure that you don't forget to define all required data when triggering event.<br /> <br /> We highly recommend to cover your events with unit tests. Search in standard plugins for files with the names events_test.php to see examples.<br /> <br /> In order to manually test the event you can perform the action and check how it appears in '''Course Administration &gt; Reports &gt; Logs'''. Also look up your event in the '''Site Administration &gt; Reports &gt; Events list'''.<br /> <br /> == &quot;Installation&quot; of events ==<br /> <br /> Please never forget that you have to bump the plugin version in order to get all the new events &quot;installed&quot;</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Logging_2&diff=44541 2014-04-28T06:10:47Z

<p>Ankitfrenz: /* Places where we need more logs */</p> <hr /> <div>{{Infobox Project<br /> |name = Logging stage 2<br /> |state = Completed<br /> |tracker = MDL-37658<br /> |discussion = https://moodle.org/mod/forum/discuss.php?d=235318<br /> |assignee = moodle.com BACKEND team<br /> }}<br /> <br /> = Benefits of the new logging system =<br /> A few benefits of the new logging system are :-<br /> * allows for capturing of richer information from plugins/core about actions;<br /> * provides control over how much information is logged;<br /> * abstracts log writing and reading so logging can be scaled;<br /> * lets you write/read logs from any external system by the use of logstore plugins;<br /> * control how much logging history is kept; and<br /> * support research, reporting and analytics.<br /> <br /> == Why is Logging an important topic? ==<br /> <br /> Logging is fundamental to research, reporting and analytics. <br /> <br /> Not much of new Moodle development is based on measured data. We need to be able to:<br /> * prove there is a problem and<br /> * prove that a given change is an improvement.<br /> <br /> Logging data can be used by different Moodle users.<br /> *Better data would allow researchers to study what happens in online teaching.<br /> *Better data would give admins more feedback on how to run their site - both technically and process (please note this issue is not about profiling).<br /> *Better data would give teachers better feedback to improve their teaching process.<br /> *Better data would give students better feedback to improve their learning.<br /> <br /> We can't predict all forms of analysis that might happen in future.<br /> * The logging system needs to be flexible in order to accommodate applications by these different users.<br /> * The logging API needs to be constructed in a way that is possible to improve in future.<br /> <br /> == Problems with old logging ==<br /> <br /> The old logging infrastructure had a number of issues that were resolved by this project. A few of these are:-<br /> <br /> * Logging was added ad-hoc by developers and has spotty coverage.<br /> * Some logged actions did not contain important information needed later.<br /> * There were performance and scalability problems, such as:<br /> ** log tables were joined in many popular queries and were slow;<br /> ** all logs used to go to one standard moodle database table, which was not scalable;<br /> ** it was not possible to configure level of logging ; and<br /> ** it was not possible to disable logging completely.<br /> <br /> = Logging =<br /> <br /> The new [[Event 2|Events API]] introduced in Moodle 2.6 provides a notification mechanism and single collection point for actions within Moodle. The Events system also defines information about events that can be extended with additional information and functionality by core code and plugins, as needed.<br /> <br /> In order to capture events a logging API was specified, consisting of a number of plugin types.<br /> <br /> To transition from the old logging system to the new, work was required in a number of areas.<br /> <br /> * In places where we previously added information to 'the' log table, we must instead generate a new event.<br /> * The standard Moodle distribution now includes 2 simple DB logging storage plugin that will store events in new format (internal and external database)<br /> * The original logging code and DB tables are available for full backwards compatibility for users of customised reports. It is possible to enable logging to the old {log} table if required.<br /> * All standard reports have been upgraded to use the new logging system and uses logging retrieval plugin to access log information.<br /> * Custom report plugins (add-ons) will be able to query the {log} table, but should ideally shift to the new logging system over time, so that sites are not forced to continue double logging.<br /> <br /> == Old log usage analysis ==<br /> <br /> See [[Logging_usage|this analysis]] to see log usage in Moodle 2.5 core code.<br /> <br /> == Example scenario ==<br /> <br /> '''Writing to the log'''<br /> <br /> # A student submits an assignment.<br /> # An event is triggered by the Assignment module.<br /> # The log manager plugin observes the event and determines if it is log-worthy depending on some admin settings.<br /> # The log manager sends the event to all enabled log storage subplugins implementing \tool_log\log\writer. Storage plugins may decide to filter out some events based on their admin settings.<br /> # The log store plugin(s) stores the event data optionally including extra information such as remote IP or original logged-in-as user id.<br /> <br /> '''Reading from the log'''<br /> <br /> # A teacher opens activity report.<br /> # Activity reports queries available log readers from the current log manager (implementing \core\log\manager).<br /> # If there is more than one log reader (implementing \core\log\sql_select_reader) available they can select the source of data for the report.<br /> # A teacher requests report of student assignment submissions.<br /> # The report requests events from the log reader and displays them.<br /> <br /> == From event to report ==<br /> <br /> There are four steps of how event is captured, logged and potentially presented in a report. These steps are summarised in [[#Figure1|Figure 1]] below and can be described as follows.<br /> <br /> # Handling of events and filtering what needs to be logged. See interface \core\log\manager below.<br /> # Storing the events data in the log storage (DB, filesystem, etc.). See interface \tool_log\log\writer below.<br /> # Retrieving the data from log storage - each plugin implements some methods to query and extract logs back to Moodle. See interfaces \core\log\reader and \core\log\sql_reader below.<br /> # Displaying the data in the report.<br /> <br /> One plugin may cover multiple steps. For example we expect that most of log writer plugins will also implement log reader. It is also possible to create a report that has built-in event handling, log writing and reading and report presentation (all four steps). Also external logging systems may not wish to allow log data they capture to be reported within Moodle, handling it through an external system, so they may not implement steps 3 and 4 at all.<br /> <br /> &lt;div id=&quot;Figure1&quot; style=&quot;text-align:center&quot;&gt;<br /> [[File:logging_plugins_relation.png]]<br /> '''Figure 1. Logging plugins relationship diagram'''&lt;/div&gt;<br /> <br /> The [[#Figure2|Figure 2]] below shows how the requests are made between user actions, plugins and core when:<br /> <br /> * configuring logging - which log writer plugins are enabled<br /> * event occurs<br /> * report - selecting log store<br /> * viewing report<br /> <br /> &lt;div id=&quot;Figure2&quot; style=&quot;text-align:center&quot;&gt;<br /> [[Image:logging_sequence.png|logging_sequence.png]]<br /> '''Figure 2. Logging plugins sequence diagram'''&lt;/div&gt;<br /> <br /> == Public API ==<br /> <br /> This section describes all interfaces that need to be implemented by log manager and each log storage class.<br /> <br /> === Reading API ===<br /> * '''function \get_log_manager()''' - returns the current log manager if configured or some dummy instance otherwise, it uses the signleton pattern.<br /> * '''interface \core\log\manager''' - log manager interface, in standard distribution implemented by \tool_log\log\manager and \core\log\dummy_manager<br /> ** public function get_readers($interface = null) returns the active storages implementing reader interface, returns array(classname =&gt; storage instance, ...)<br /> * '''interface \core\log\reader''' - general event reader<br /> ** public function get_name() - returns name of the log storage, this will be used when selection data source in reports.<br /> ** public function get_description() - some help for admins.<br /> ** public function is_logging() - is latest data available?<br /> * '''interface \core\log\sql_select_reader''' extends \core\log\reader - general log storage that supports sql selects (or emulates them)<br /> ** public function get_events_select($selectwhere, array $params, $order, $limitfrom, $limitnum) - returns event object instances matching given parameters.<br /> ** public function get_events_select_count($selectwhere, array $params) - returns number of events that would be returned from get_events() with the same parameters.<br /> *** $selectwhere is supposed to be a limited sql predicate.<br /> *** The set of operators allowed in $selectwhere are :- =, &lt;&gt;, &gt;, &gt;=, &lt;, &lt;=<br /> *** The set of keywords allowed in $selectwhere are :- IN, BETWEEN, LIKE, IS NULL, IS NOT NULL<br /> *** Logical operators OR, AND<br /> *** NOT operator<br /> *** ( and ) brackets<br /> *** ? and :named parameter placeholders <br /> *** Use of anything besides the mentioned keywords/operators is strictly forbidden.<br /> * '''interface \core\log\sql_internal_reader''' extends \core\log\reader - log storage that can expose data as read-only database view or table.<br /> ** public function get_internal_log_table_name() - returns database table or view; structure is described in phpdocs, it will include all columns defined by log_sql<br /> <br /> Reports are expected to use only the reading API. Please note that all non-sql readers need to somehow translate the $selectwhere SQL query syntax.<br /> <br /> When reports are searching for log readers they use the get_log_manager()-&gt;get_readers($interface = null) where $interface is the name of reader interface that the report supports.<br /> If there are multiple readers returned by the log manager, then the report is responsible for letting the user choose which storage to create the report on.<br /> <br /> === Writing API ===<br /> * '''interface \tool_log\log\store''' - must be implemented by each store subplugin.<br /> ** public function __construct(\tool_log\log\manager $manager) - no parameters, configuration is taken from admin settings.<br /> ** public function dispose() - called when reading/writing finished.<br /> * '''interface \tool_log\log\writer''' extends \tool_log\log\store - interface indicating the log store may be used for writing.<br /> ** public function write(\core\event\base $event) - called from event observer defined in log manager.<br /> <br /> The writing API is defined in tool_log plugin, the log stores are defined as new subplugin of this plugin.<br /> <br /> Each log store plugin will be responsible for filtering of events, it may use standardised admin settings and filtering or decide to implement custom filtering.<br /> <br /> == Standard logging plugins ==<br /> <br /> Standard Moodle distribution will include four plugins.<br /> <br /> === Logging management plugin (tool_log) ===<br /> <br /> Defines:<br /> <br /> class \tool_log\log\manager implements \core\log\manager;<br /> <br /> The log manager is responsible for step 1 from [[#Figure1|Figure 1]] above. It allows admins to configure which log store subplugin is enabled and in which order they appear. The log store plugins are implemented as tool_log subplugins with class &quot;store&quot; in their namespace (\logstore_xxxx\log\store).<br /> <br /> The log manager registers a '*' event observer, this observer is external - it means that events are received only when database transactions are not in progress.<br /> <br /> === Standard log storage plugin (logstore_standard) ===<br /> <br /> Defines:<br /> <br /> class \logstore_standard\log\store implements \core\log\sql_internal_reader, \tool_log\log\writer;<br /> <br /> The name logstore_standard does not seem to be optimal - ''logstore_db'' is not allowed because it collides with standard /db/ subdirectory in plugins and ''logstore_database'' should be probably reserved for external database logging (to prevent any confusion).<br /> <br /> This log storage plugin is responsible for steps 2 and 3 from [[#Figure1|Figure 1]] above. It is the primary replacement for the former {log} table. The performance will be similar to former log table, but for smaller sites, this simple default will suffice.<br /> <br /> Each plugin decides how much data is kept, when it is deleted, etc.<br /> <br /> ==== Storage settings ====<br /> <br /> Each storage plugin with writer interface is responsible for backlisting or filtering of events. Some of the examples of filtering that can done is as below:-<br /> * Include guests actions (default ''Yes'').<br /> * Include log levels (default ''empty''), accepts constants from [[Event_2#Level_property]].<br /> * Include by CRUD (default ''empty''), accepts C, R, U, and D.<br /> * Include by component (default ''empty'')<br /> * Include by event name (default ''empty'')<br /> <br /> === External database log storage plugin (logstore_database) ===<br /> <br /> Defines:<br /> <br /> class \logstore_database\log\store implements \core\log\sql_select_reader, \tool_log\log\writer;<br /> <br /> This log storage plugin is responsible for step 2 only from [[#Figure1|Figure 1]] above. There will be no interface to read from it provided with Moodle core.<br /> <br /> === Legacy log table reader (logstore_legacy) ===<br /> <br /> Defines:<br /> <br /> class \logstore_legacy\log\store implements \core\log\sql_select_reader, \tool_log\log\store;<br /> <br /> This plugin will not conduct any log writing; it will translate existing {log} table data into the new event format and transforms new SQL selects to match the legacy table format. This serves as an emulation layer that allows new reports to access historical data stored in mdl_log table. Users will have to select this datasource manually if they want to see historical data that is not present in new log tables.<br /> <br /> In new reports the legacy data will be presented using a special legacy event class that can not be triggered: \logstore_legacy\event\legacy<br /> <br /> == Performance ==<br /> <br /> Compared to older Moodle version the new system will need to deal with higher number of log entries. This was improved by buffering of log entries together with new improved bulk insert operations in the DML layer. Helper traits were introduced \tool_log\helper\buffered_writer to help stores easily buffer the events.<br /> <br /> Running new and old event logging at the same time with result in 2x number of DB inserts, it will be therefore recommended to disable the old logging as soon as possible.<br /> <br /> In [https://tracker.moodle.org/browse/MDL-42894 MDL-42894], logging api comparison is done and it seems promising. Results are:<br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Enabled Stores<br /> ! dbwrites<br /> ! dbreads<br /> ! Time used<br /> ! Session size<br /> ! Memory<br /> ! Server load<br /> |-<br /> | Legacy + Standard store<br /> | Little increase<br /> | Same<br /> | Same<br /> | Same<br /> | Same<br /> | Increased<br /> |-<br /> | Only Standard store<br /> | Decrease<br /> | Same<br /> | Same<br /> | Same<br /> | Same<br /> | Increased<br /> |-<br /> | Only Legacy store<br /> | Same<br /> | Same<br /> | Same<br /> | Same<br /> | Same<br /> | Decrease<br /> |-<br /> | Neither Legacy nor Standard store<br /> | Decrease<br /> | Same<br /> | Same<br /> | Same<br /> | Same<br /> | Decrease<br /> |}<br /> FYI: Serverload is showing worse in most cases, but as this was done on my local machine with all interference, I am ignoring this for now.<br /> --[[User:Rajesh Taneja|Rajesh Taneja]] ([[User talk:Rajesh Taneja|talk]]) 16:19, 14 February 2014 (WST)<br /> <br /> == Mockups ==<br /> === Log management page ===<br /> [[File:event-observer.png |frame|center| Log management page]]<br /> <br /> === Log store settings pages ===<br /> [[File:event-observer-2.png |frame|center| settings page for a the standard log setup]]<br /> [[File:external-log-settings.png |frame|center| settings page for an external log setup]]<br /> <br /> == Overarching considerations ==<br /> <br /> We can't actually predict all use cases, so we must think generically and plan for worst cases. Here are some overarching principles that will be followed in the implementation of the new logging system.<br /> <br /> * Things that don't need to use logs should not use logs. (Recent activity, etc)<br /> * Logging calls should be as cheap as possible.<br /> * The Events API will be the central communication mechanism, allowing lots of potential information gathering tools to exist in future.<br /> * Use plug-ins to determine where to put logs permanently (NoSQL, SAS, file...). Initially, the default will be to the current log table.<br /> * Log everything we possibly can think of.<br /> * Define log level settings (on each logging call) so different sites can choose what they want logged, which allows controls cotrol of log size, speed, etc..<br /> * Function add_to_log should be retained for backward compatibility, without changing existing implementation, but allowing admins to disable it.<br /> <br /> = Reports =<br /> <br /> [[Logging usage#Reports]] describes current reports.<br /> <br /> = Migration to new logging API =<br /> <br /> == Follow-up Projects ==<br /> <br /> * Converting completion to use events - MDL-42897<br /> * Developing a ''Timeline'' page/block so each user to see a stream of activity that is relevant to them individually - MDL-42898<br /> <br /> == Related ==<br /> <br /> '''Here are some ideas of how new even data and observers can be put to use:'''<br /> <br /> * Please note that the log storage API is not optimised for these tasks.<br /> * Timely notifications of critical events (defined by users), for example more than five people posted in the same forum within an hour.<br /> * &quot;Red circle&quot; notification badge counter icons everywhere in Moodle highlighting things that a user needs to pay attention attention to, such as ???.<br /> * Colour heatmaps overlaid on course pages showing recent usage patterns of the course.<br /> * Visualisation of live activity across a whole site (for admins) (is that logging or event handling?)<br /> * Live engagement analytics reporting ??? that take specific actions into account, such as ???.<br /> * Identification of students at risk based on their involvement in the course (or lack of it).<br /> <br /> '''Logging of exceptions, errors and debugging:'''<br /> <br /> * Logging of Errors and warnings is not part of this specification, it meeds to be handled via a completely separate mechanism.<br /> ** People report errors that cannot be duplicated. Logging errors with a stack trace, session variables and other relevant data could be useful for debugging.<br /> * Standard logs may theoretically produce errors and exceptions that need to be logged somewhere else.<br /> * There is no synchronization with server logs to help debugging performance issues. (This will not be addressed by new logging API.)<br /> * There is no logging of error information to help debug Moodle issues. (This will not be addressed by new logging API.)<br /> <br /> '''Performance logging and profiling'''<br /> <br /> We need to measure the performance of logging system and store the information somewhere.<br /> <br /> '''Other'''<br /> <br /> * There is no mechanism for archiving, so old logs are deleted and lost.<br /> * Log deletion is indiscriminate, with no control of what log information is deleted or retained.<br /> <br /> == Places where we need more logs ==<br /> <br /> The principle work of this project is to replace the existing logging API. Once the new system is in place, the coverage of logging around Moodle can be improved.<br /> <br /> Suggestions for places in Moodle where logging is needed should be reported as Tracker issues and linked to the Epic MDL-28443 &quot;Action logging improvements&quot;. Feel free to echo significant areas here.<br /> <br /> * Activities on site, course and activity administration pages.<br /> * Micro activities in a page (more than one per load), such as ???.<br /> * AJAX calls (eg on course page), such as ???.<br /> * Logging of long events (such as an LDAP synchronisation) should have:<br /> ** one unique identifier per event (like for example postfix mail server) to help admin monitor the cron processes and<br /> ** at least 2 log entries (begining and end) for each event, possibly more.<br /> * Should be careful about logging confidential information. Anonymous events can be used to controll privacy.<br /> * Shouldn’t delete logs when course is deleted. There is no API to delete logs, each log storage controls the rotation or deleting of old data individually.<br /> <br /> =See also=<br /> <br /> * [[Event 2]]<br /> * [[Migrating logging calls in plugins]]<br /> * [[Migrating reports accessing logs]]<br /> <br /> Other logging systems:<br /> * http://logstash.net/ <br /> * http://fluentd.org/<br /> * http://logging.apache.org/log4php/<br /> <br /> Examples of data-based learning technology development:<br /> * http://onlinelibrary.wiley.com/doi/10.1111/j.1467-8535.2008.00928.x/abstract <br /> * http://www.sciencedirect.com/science/article/pii/S0360131510000461 -&gt; qtype_pmatch<br /> * http://www.tandfonline.com/doi/abs/10.1080/02680513.2011.567754<br /> * http://oro.open.ac.uk/24619/<br /> * [http://www.adlnet.gov/tla/lrs/ A Learning Record Store (LRS)] is a system that stores the tracking statements communicated through the [https://github.com/adlnet/xAPI-Spec Experience API (xAPI)]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Logging_2&diff=44540 2014-04-28T06:06:01Z

<p>Ankitfrenz: Cleanup the doc</p> <hr /> <div>{{Infobox Project<br /> |name = Logging stage 2<br /> |state = Completed<br /> |tracker = MDL-37658<br /> |discussion = https://moodle.org/mod/forum/discuss.php?d=235318<br /> |assignee = moodle.com BACKEND team<br /> }}<br /> <br /> = Benefits of the new logging system =<br /> A few benefits of the new logging system are :-<br /> * allows for capturing of richer information from plugins/core about actions;<br /> * provides control over how much information is logged;<br /> * abstracts log writing and reading so logging can be scaled;<br /> * lets you write/read logs from any external system by the use of logstore plugins;<br /> * control how much logging history is kept; and<br /> * support research, reporting and analytics.<br /> <br /> == Why is Logging an important topic? ==<br /> <br /> Logging is fundamental to research, reporting and analytics. <br /> <br /> Not much of new Moodle development is based on measured data. We need to be able to:<br /> * prove there is a problem and<br /> * prove that a given change is an improvement.<br /> <br /> Logging data can be used by different Moodle users.<br /> *Better data would allow researchers to study what happens in online teaching.<br /> *Better data would give admins more feedback on how to run their site - both technically and process (please note this issue is not about profiling).<br /> *Better data would give teachers better feedback to improve their teaching process.<br /> *Better data would give students better feedback to improve their learning.<br /> <br /> We can't predict all forms of analysis that might happen in future.<br /> * The logging system needs to be flexible in order to accommodate applications by these different users.<br /> * The logging API needs to be constructed in a way that is possible to improve in future.<br /> <br /> == Problems with old logging ==<br /> <br /> The old logging infrastructure had a number of issues that were resolved by this project. A few of these are:-<br /> <br /> * Logging was added ad-hoc by developers and has spotty coverage.<br /> * Some logged actions did not contain important information needed later.<br /> * There were performance and scalability problems, such as:<br /> ** log tables were joined in many popular queries and were slow;<br /> ** all logs used to go to one standard moodle database table, which was not scalable;<br /> ** it was not possible to configure level of logging ; and<br /> ** it was not possible to disable logging completely.<br /> <br /> = Logging =<br /> <br /> The new [[Event 2|Events API]] introduced in Moodle 2.6 provides a notification mechanism and single collection point for actions within Moodle. The Events system also defines information about events that can be extended with additional information and functionality by core code and plugins, as needed.<br /> <br /> In order to capture events a logging API was specified, consisting of a number of plugin types.<br /> <br /> To transition from the old logging system to the new, work was required in a number of areas.<br /> <br /> * In places where we previously added information to 'the' log table, we must instead generate a new event.<br /> * The standard Moodle distribution now includes 2 simple DB logging storage plugin that will store events in new format (internal and external database)<br /> * The original logging code and DB tables are available for full backwards compatibility for users of customised reports. It is possible to enable logging to the old {log} table if required.<br /> * All standard reports have been upgraded to use the new logging system and uses logging retrieval plugin to access log information.<br /> * Custom report plugins (add-ons) will be able to query the {log} table, but should ideally shift to the new logging system over time, so that sites are not forced to continue double logging.<br /> <br /> == Old log usage analysis ==<br /> <br /> See [[Logging_usage|this analysis]] to see log usage in Moodle 2.5 core code.<br /> <br /> == Example scenario ==<br /> <br /> '''Writing to the log'''<br /> <br /> # A student submits an assignment.<br /> # An event is triggered by the Assignment module.<br /> # The log manager plugin observes the event and determines if it is log-worthy depending on some admin settings.<br /> # The log manager sends the event to all enabled log storage subplugins implementing \tool_log\log\writer. Storage plugins may decide to filter out some events based on their admin settings.<br /> # The log store plugin(s) stores the event data optionally including extra information such as remote IP or original logged-in-as user id.<br /> <br /> '''Reading from the log'''<br /> <br /> # A teacher opens activity report.<br /> # Activity reports queries available log readers from the current log manager (implementing \core\log\manager).<br /> # If there is more than one log reader (implementing \core\log\sql_select_reader) available they can select the source of data for the report.<br /> # A teacher requests report of student assignment submissions.<br /> # The report requests events from the log reader and displays them.<br /> <br /> == From event to report ==<br /> <br /> There are four steps of how event is captured, logged and potentially presented in a report. These steps are summarised in [[#Figure1|Figure 1]] below and can be described as follows.<br /> <br /> # Handling of events and filtering what needs to be logged. See interface \core\log\manager below.<br /> # Storing the events data in the log storage (DB, filesystem, etc.). See interface \tool_log\log\writer below.<br /> # Retrieving the data from log storage - each plugin implements some methods to query and extract logs back to Moodle. See interfaces \core\log\reader and \core\log\sql_reader below.<br /> # Displaying the data in the report.<br /> <br /> One plugin may cover multiple steps. For example we expect that most of log writer plugins will also implement log reader. It is also possible to create a report that has built-in event handling, log writing and reading and report presentation (all four steps). Also external logging systems may not wish to allow log data they capture to be reported within Moodle, handling it through an external system, so they may not implement steps 3 and 4 at all.<br /> <br /> &lt;div id=&quot;Figure1&quot; style=&quot;text-align:center&quot;&gt;<br /> [[File:logging_plugins_relation.png]]<br /> '''Figure 1. Logging plugins relationship diagram'''&lt;/div&gt;<br /> <br /> The [[#Figure2|Figure 2]] below shows how the requests are made between user actions, plugins and core when:<br /> <br /> * configuring logging - which log writer plugins are enabled<br /> * event occurs<br /> * report - selecting log store<br /> * viewing report<br /> <br /> &lt;div id=&quot;Figure2&quot; style=&quot;text-align:center&quot;&gt;<br /> [[Image:logging_sequence.png|logging_sequence.png]]<br /> '''Figure 2. Logging plugins sequence diagram'''&lt;/div&gt;<br /> <br /> == Public API ==<br /> <br /> This section describes all interfaces that need to be implemented by log manager and each log storage class.<br /> <br /> === Reading API ===<br /> * '''function \get_log_manager()''' - returns the current log manager if configured or some dummy instance otherwise, it uses the signleton pattern.<br /> * '''interface \core\log\manager''' - log manager interface, in standard distribution implemented by \tool_log\log\manager and \core\log\dummy_manager<br /> ** public function get_readers($interface = null) returns the active storages implementing reader interface, returns array(classname =&gt; storage instance, ...)<br /> * '''interface \core\log\reader''' - general event reader<br /> ** public function get_name() - returns name of the log storage, this will be used when selection data source in reports.<br /> ** public function get_description() - some help for admins.<br /> ** public function is_logging() - is latest data available?<br /> * '''interface \core\log\sql_select_reader''' extends \core\log\reader - general log storage that supports sql selects (or emulates them)<br /> ** public function get_events_select($selectwhere, array $params, $order, $limitfrom, $limitnum) - returns event object instances matching given parameters.<br /> ** public function get_events_select_count($selectwhere, array $params) - returns number of events that would be returned from get_events() with the same parameters.<br /> *** $selectwhere is supposed to be a limited sql predicate.<br /> *** The set of operators allowed in $selectwhere are :- =, &lt;&gt;, &gt;, &gt;=, &lt;, &lt;=<br /> *** The set of keywords allowed in $selectwhere are :- IN, BETWEEN, LIKE, IS NULL, IS NOT NULL<br /> *** Logical operators OR, AND<br /> *** NOT operator<br /> *** ( and ) brackets<br /> *** ? and :named parameter placeholders <br /> *** Use of anything besides the mentioned keywords/operators is strictly forbidden.<br /> * '''interface \core\log\sql_internal_reader''' extends \core\log\reader - log storage that can expose data as read-only database view or table.<br /> ** public function get_internal_log_table_name() - returns database table or view; structure is described in phpdocs, it will include all columns defined by log_sql<br /> <br /> Reports are expected to use only the reading API. Please note that all non-sql readers need to somehow translate the $selectwhere SQL query syntax.<br /> <br /> When reports are searching for log readers they use the get_log_manager()-&gt;get_readers($interface = null) where $interface is the name of reader interface that the report supports.<br /> If there are multiple readers returned by the log manager, then the report is responsible for letting the user choose which storage to create the report on.<br /> <br /> === Writing API ===<br /> * '''interface \tool_log\log\store''' - must be implemented by each store subplugin.<br /> ** public function __construct(\tool_log\log\manager $manager) - no parameters, configuration is taken from admin settings.<br /> ** public function dispose() - called when reading/writing finished.<br /> * '''interface \tool_log\log\writer''' extends \tool_log\log\store - interface indicating the log store may be used for writing.<br /> ** public function write(\core\event\base $event) - called from event observer defined in log manager.<br /> <br /> The writing API is defined in tool_log plugin, the log stores are defined as new subplugin of this plugin.<br /> <br /> Each log store plugin will be responsible for filtering of events, it may use standardised admin settings and filtering or decide to implement custom filtering.<br /> <br /> == Standard logging plugins ==<br /> <br /> Standard Moodle distribution will include four plugins.<br /> <br /> === Logging management plugin (tool_log) ===<br /> <br /> Defines:<br /> <br /> class \tool_log\log\manager implements \core\log\manager;<br /> <br /> The log manager is responsible for step 1 from [[#Figure1|Figure 1]] above. It allows admins to configure which log store subplugin is enabled and in which order they appear. The log store plugins are implemented as tool_log subplugins with class &quot;store&quot; in their namespace (\logstore_xxxx\log\store).<br /> <br /> The log manager registers a '*' event observer, this observer is external - it means that events are received only when database transactions are not in progress.<br /> <br /> === Standard log storage plugin (logstore_standard) ===<br /> <br /> Defines:<br /> <br /> class \logstore_standard\log\store implements \core\log\sql_internal_reader, \tool_log\log\writer;<br /> <br /> The name logstore_standard does not seem to be optimal - ''logstore_db'' is not allowed because it collides with standard /db/ subdirectory in plugins and ''logstore_database'' should be probably reserved for external database logging (to prevent any confusion).<br /> <br /> This log storage plugin is responsible for steps 2 and 3 from [[#Figure1|Figure 1]] above. It is the primary replacement for the former {log} table. The performance will be similar to former log table, but for smaller sites, this simple default will suffice.<br /> <br /> Each plugin decides how much data is kept, when it is deleted, etc.<br /> <br /> ==== Storage settings ====<br /> <br /> Each storage plugin with writer interface is responsible for backlisting or filtering of events. Some of the examples of filtering that can done is as below:-<br /> * Include guests actions (default ''Yes'').<br /> * Include log levels (default ''empty''), accepts constants from [[Event_2#Level_property]].<br /> * Include by CRUD (default ''empty''), accepts C, R, U, and D.<br /> * Include by component (default ''empty'')<br /> * Include by event name (default ''empty'')<br /> <br /> === External database log storage plugin (logstore_database) ===<br /> <br /> Defines:<br /> <br /> class \logstore_database\log\store implements \core\log\sql_select_reader, \tool_log\log\writer;<br /> <br /> This log storage plugin is responsible for step 2 only from [[#Figure1|Figure 1]] above. There will be no interface to read from it provided with Moodle core.<br /> <br /> === Legacy log table reader (logstore_legacy) ===<br /> <br /> Defines:<br /> <br /> class \logstore_legacy\log\store implements \core\log\sql_select_reader, \tool_log\log\store;<br /> <br /> This plugin will not conduct any log writing; it will translate existing {log} table data into the new event format and transforms new SQL selects to match the legacy table format. This serves as an emulation layer that allows new reports to access historical data stored in mdl_log table. Users will have to select this datasource manually if they want to see historical data that is not present in new log tables.<br /> <br /> In new reports the legacy data will be presented using a special legacy event class that can not be triggered: \logstore_legacy\event\legacy<br /> <br /> == Performance ==<br /> <br /> Compared to older Moodle version the new system will need to deal with higher number of log entries. This was improved by buffering of log entries together with new improved bulk insert operations in the DML layer. Helper traits were introduced \tool_log\helper\buffered_writer to help stores easily buffer the events.<br /> <br /> Running new and old event logging at the same time with result in 2x number of DB inserts, it will be therefore recommended to disable the old logging as soon as possible.<br /> <br /> In [https://tracker.moodle.org/browse/MDL-42894 MDL-42894], logging api comparison is done and it seems promising. Results are:<br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Enabled Stores<br /> ! dbwrites<br /> ! dbreads<br /> ! Time used<br /> ! Session size<br /> ! Memory<br /> ! Server load<br /> |-<br /> | Legacy + Standard store<br /> | Little increase<br /> | Same<br /> | Same<br /> | Same<br /> | Same<br /> | Increased<br /> |-<br /> | Only Standard store<br /> | Decrease<br /> | Same<br /> | Same<br /> | Same<br /> | Same<br /> | Increased<br /> |-<br /> | Only Legacy store<br /> | Same<br /> | Same<br /> | Same<br /> | Same<br /> | Same<br /> | Decrease<br /> |-<br /> | Neither Legacy nor Standard store<br /> | Decrease<br /> | Same<br /> | Same<br /> | Same<br /> | Same<br /> | Decrease<br /> |}<br /> FYI: Serverload is showing worse in most cases, but as this was done on my local machine with all interference, I am ignoring this for now.<br /> --[[User:Rajesh Taneja|Rajesh Taneja]] ([[User talk:Rajesh Taneja|talk]]) 16:19, 14 February 2014 (WST)<br /> <br /> == Mockups ==<br /> === Log management page ===<br /> [[File:event-observer.png |frame|center| Log management page]]<br /> <br /> === Log store settings pages ===<br /> [[File:event-observer-2.png |frame|center| settings page for a the standard log setup]]<br /> [[File:external-log-settings.png |frame|center| settings page for an external log setup]]<br /> <br /> == Overarching considerations ==<br /> <br /> We can't actually predict all use cases, so we must think generically and plan for worst cases. Here are some overarching principles that will be followed in the implementation of the new logging system.<br /> <br /> * Things that don't need to use logs should not use logs. (Recent activity, etc)<br /> * Logging calls should be as cheap as possible.<br /> * The Events API will be the central communication mechanism, allowing lots of potential information gathering tools to exist in future.<br /> * Use plug-ins to determine where to put logs permanently (NoSQL, SAS, file...). Initially, the default will be to the current log table.<br /> * Log everything we possibly can think of.<br /> * Define log level settings (on each logging call) so different sites can choose what they want logged, which allows controls cotrol of log size, speed, etc..<br /> * Function add_to_log should be retained for backward compatibility, without changing existing implementation, but allowing admins to disable it.<br /> <br /> = Reports =<br /> <br /> [[Logging usage#Reports]] describes current reports.<br /> <br /> = Migration to new logging API =<br /> <br /> == Follow-up Projects ==<br /> <br /> * Converting completion to use events - MDL-42897<br /> * Developing a ''Timeline'' page/block so each user to see a stream of activity that is relevant to them individually - MDL-42898<br /> <br /> == Related ==<br /> <br /> '''Here are some ideas of how new even data and observers can be put to use:'''<br /> <br /> * Please note that the log storage API is not optimised for these tasks.<br /> * Timely notifications of critical events (defined by users), for example more than five people posted in the same forum within an hour.<br /> * &quot;Red circle&quot; notification badge counter icons everywhere in Moodle highlighting things that a user needs to pay attention attention to, such as ???.<br /> * Colour heatmaps overlaid on course pages showing recent usage patterns of the course.<br /> * Visualisation of live activity across a whole site (for admins) (is that logging or event handling?)<br /> * Live engagement analytics reporting ??? that take specific actions into account, such as ???.<br /> * Identification of students at risk based on their involvement in the course (or lack of it).<br /> <br /> '''Logging of exceptions, errors and debugging:'''<br /> <br /> * Logging of Errors and warnings is not part of this specification, it meeds to be handled via a completely separate mechanism.<br /> ** People report errors that cannot be duplicated. Logging errors with a stack trace, session variables and other relevant data could be useful for debugging.<br /> * Standard logs may theoretically produce errors and exceptions that need to be logged somewhere else.<br /> * There is no synchronization with server logs to help debugging performance issues. (This will not be addressed by new logging API.)<br /> * There is no logging of error information to help debug Moodle issues. (This will not be addressed by new logging API.)<br /> <br /> '''Performance logging and profiling'''<br /> <br /> We need to measure the performance of logging system and store the information somewhere.<br /> <br /> '''Other'''<br /> <br /> * There is no mechanism for archiving, so old logs are deleted and lost.<br /> * Log deletion is indiscriminate, with no control of what log information is deleted or retained.<br /> <br /> == Places where we need more logs ==<br /> <br /> The principle work of this project is to replace the existing logging API. Once the new system is in place, the coverage of logging around Moodle can be improved.<br /> <br /> Suggestions for places in Moodle where logging is needed should be reported as Tracker issues and linked to the Epic MDL-28443 &quot;Action logging improvements&quot;. Feel free to echo significant areas here.<br /> <br /> * Activities on site, course and activity administration pages.<br /> * Micro activities in a page (more than one per load), such as ???.<br /> * AJAX calls (eg on course page), such as ???.<br /> * Logging of long events (such as an LDAP synchronisation) should have:<br /> ** one unique identifier per event (like for example postfix mail server) to help admin monitor the cron processes and<br /> ** at least 2 log entries (begining and end) for each event, possibly more.<br /> * Should be careful about logging confidential information. The privacy is controlled by event access control and can_access() method in each storage plugin..<br /> * Shouldn’t delete logs when course is deleted. There is no API to delete logs, each log storage controls the rotation or deleting of old data individually.<br /> <br /> =See also=<br /> <br /> * [[Event 2]]<br /> * [[Migrating logging calls in plugins]]<br /> * [[Migrating reports accessing logs]]<br /> <br /> Other logging systems:<br /> * http://logstash.net/ <br /> * http://fluentd.org/<br /> * http://logging.apache.org/log4php/<br /> <br /> Examples of data-based learning technology development:<br /> * http://onlinelibrary.wiley.com/doi/10.1111/j.1467-8535.2008.00928.x/abstract <br /> * http://www.sciencedirect.com/science/article/pii/S0360131510000461 -&gt; qtype_pmatch<br /> * http://www.tandfonline.com/doi/abs/10.1080/02680513.2011.567754<br /> * http://oro.open.ac.uk/24619/<br /> * [http://www.adlnet.gov/tla/lrs/ A Learning Record Store (LRS)] is a system that stores the tracking statements communicated through the [https://github.com/adlnet/xAPI-Spec Experience API (xAPI)]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Events_API&diff=44538 2014-04-28T04:35:18Z

<p>Ankitfrenz: Cleanup the doc</p> <hr /> <div>{{Infobox Project<br /> |name = Events 2<br /> |state = Completed<br /> |tracker = MDL-39797 , MDL-39952, MDL-39846<br /> |discussion = https://moodle.org/mod/forum/discuss.php?d=229425<br /> |assignee = Backend Team<br /> }}<br /> <br /> = What are events? =<br /> <br /> Events are atomic pieces of information describing something that happened in Moodle. Events are primarily the result of user actions, but could also be the result of the [[:en:Cron|cron]] process or administration actions [[:en:Administration via command line|undertaken via the command line]].<br /> <br /> When an action takes place, an event is created by a [[Core APIs|core API]] or [[Plugins|plugin]]. The Events system then disseminates this event information to observers registered for this event. In this way, the events system acts as a communication backbone throughout the Moodle system.<br /> <br /> Event observers can not modify event data or interrupt the dispatching of events, it is a one way communication channel.<br /> <br /> = Why is a new events system needed? =<br /> <br /> The need to improve the Events system was prompted by a need for a richer and more efficient logging system, however the benefits of this improvement will be useful to other parts of Moodle that observe event information.<br /> <br /> * The events need to be more strictly defined if we want to use them for new logging and other advanced use cases. They need to contain a lot more information in a standardised way (such as most fields from current log table and log_actions table).<br /> * Complex data types were allowed in old events which was causing major problems when serialising/storing/unserializing the data.<br /> * The logging and events contain similar information and are triggered at the same places, new events would remove this code duplication. All events should be loggable and all current log entries should be triggered as events.<br /> * The logging system will become an event observer, listening to all events and directing them to logging storage plugins in a controllable way.<br /> * It will be possible to subscribe to '*' event, which would allow a system to potentially observe, and selectively deal with, all events. Current handlers do not get event name which makes this problematic.<br /> * Current event handlers may trigger exceptions during site upgrade which would lead to fatal upgrade problems. The new design eliminates this.<br /> * Failure in handlers blocked dispatching of subsequent events. Instead problems in new observers would be only logged and execution would continue normally.<br /> * Current execution of external handlers during DB transactions blocks other handlers. This would be eliminated by in-memory buffer for external events.<br /> * It would good to have observer priority.<br /> * Nested events are not dispatched sequentially, it would change the order of events received in lower priority handlers.<br /> <br /> = Performance =<br /> Some basic profiling has been conducted.<br /> <br /> There is a general plan to complete pre- and post-implementation testing as development happens. The new system will be imemented in parallel with the old one which should help with comparison of new and old logging and event triggering performance on each page.<br /> <br /> Our aim is to trigger more events and log more information, which is going to impact on performance. We hope to offset that impact by improving log storage, simplifying event dispatching and adding other core performance improvements. The proposed class structure of the base event should allow some new advanced techniques, which may also improve performance in some scenarios.<br /> <br /> More details will be added to this section soon.<br /> <br /> = Events API =<br /> <br /> Each plugin will define the events that it can report (trigger) by extending an abstract base class, once for each possible event. This approach will have several benefits.<br /> ; Events will be active objects<br /> : When they are triggered and possibly after they are reinstantiated (say, when they are retrieved from a log), an event object will be able to provide callback functions for various purposes (such as capability checks).<br /> ; Automatic inclusion<br /> : Event class definitions will be automatically included when needed, without having to maintain lists of known event types. New event definitions can be added without the need to upgrade, only purging of MUC cache is required after adding new observer.<br /> ; Maintainability<br /> : It will be easy to add new events and migrate existing events. Code review will be simplified because there will be less duplication of code when triggering events and all event related information/code will be concentrated in one file in fixed locations.<br /> ; Self documenting<br /> : The behaviour of events will be combined with the definition of events in one place (file). It will be easy for event observer writers to know what events a plugin can trigger. This includes support for autocompletion and code inspection in modern IDEs.<br /> ; Quick, self-validating data structure<br /> : As events are instantiated objects, the PHP processor will validate the structure and type of event classes. This does not ensure data value validity, but does give some assurance of consistency and it also detects common typos.<br /> <br /> == Backwards compatibility and migration ==<br /> <br /> Events:<br /> * All legacy events in the standard distribution has been replaced with the new events api and events_trigger() has been deprecated.<br /> * For events that already exist in Moodle 2.5 the additional legacy information has been added to the event data (in properties 'legacyeventname' and 'legacyeventdata')<br /> * The legacy events handling code is maintained separately and will continue being supported in Moodle 2.x.<br /> * All legacy events-handlers has been migrated to the new observers in standard distribution.<br /> * In future, more subsystems may be migrated to events-observers, ex.: gradebook history, completion.<br /> <br /> Logging:<br /> * Function add_to_log() has been deprecated with a notice as of Moodle 2.7.<br /> * Existing add_to_log() parameters has been migrated inside new events method get_legacy_log_data() and core_event_base::trigger() calls add_to_log() automatically (this will depend on $CFG-&gt;loglifetime setting for performance reasons).<br /> <br /> == Event dispatching and observers ==<br /> <br /> The new event dispatching system is completely separate from the old events code. Original event handlers are now called observers with the description stored in the same db/events.php file, but as a new array with a different format.<br /> <br /> === Event observers ===<br /> <br /> The observers are described in db/events.php in the array $observers, the array is not indexed and contains a list of observers defined as an array with the following properties;<br /> * eventname – fully qualified event class name or &quot;*&quot; indicating all events, ex.: ''\plugintype_pluginname\event\something_happened''.<br /> * callback - PHP callable type.<br /> * includefile - optional. File to be included before calling the observer. Path relative to dirroot.<br /> * priority - optional. Defaults to 0. Observers with higher priority are notified first.<br /> * internal - optional. Defaults to true. Non-internal observers are not called during database transactions, but instead after a successful commit of the transaction.<br /> <br /> &lt;code php&gt;<br /> <br /> $observers = array(<br /> <br /> array(<br /> 'eventname' =&gt; '\core\event\sample_executed',<br /> 'callback' =&gt; 'core_event_sample_observer::observe_one',<br /> ),<br /> <br /> array(<br /> 'eventname' =&gt; '\core\event\sample_executed',<br /> 'callback' =&gt; 'core_event_sample_observer::external_observer',<br /> 'priority' =&gt; 200,<br /> 'internal' =&gt; false,<br /> ),<br /> <br /> array(<br /> 'eventname' =&gt; '*',<br /> 'callback' =&gt; 'core_event_sample_observer::observe_all',<br /> 'includefile' =&gt; null,<br /> 'internal' =&gt; true,<br /> 'priority' =&gt; 9999,<br /> ),<br /> <br /> );<br /> <br /> &lt;/code&gt;<br /> <br /> === Event dispatching ===<br /> <br /> A list of available observers is constructed on the fly directly from all available in 'events.php' files. Previously handlers were installed only during installation and upgrade. There is no risk of performance regression because the list is already cached in MUC. Observers get events before installation or any upgrade, however observers are not notified during the initial installation of Moodle core tables.<br /> <br /> Developers of observers must make sure that execution does not end with a fatal error under any condition (before install, before upgrade or normal operation). Exceptions are automatically captured, logged in the PHP error log, and notification of other observers continues. Current handlers must not throw any exceptions at any time.<br /> <br /> Observers are notified sequentially in the same order in which events were triggered. This means that events triggered in observers are queued in FIFO buffer and are processed after all observers are notified.<br /> <br /> === Differences from old event handling ===<br /> <br /> # New events contain a lot more structured information.<br /> # There is separate context cache which may be used when deleting data or for observer performance improvements.<br /> # No database access in new event dispatching code.<br /> # There is no support for cron execution - this eliminates performance problems, simplifies events dispatching and prevents abuse of cron events.<br /> # Events triggered in observers are processed in a different order.<br /> # External events are buffered when a transaction is in progress, instead of being sent to the cron queue.<br /> # It is possible to define multiple observers for one event in one events.php file.<br /> # It is possible to subscribe an observer to all events.<br /> # The new event manager is using frankenstyle autoloading - smaller memory footprint when events are not used on the current page.<br /> <br /> == Triggering events ==<br /> <br /> * All event definitions are classes extending the \core\event\base class.<br /> * Events are triggered by creating a new instance of the class event and executing $event-&gt;trigger().<br /> * Each event class name is a unique identifier of the event.<br /> * Class names and namespace follow the identifier scheme \'''frankenstyle_component'''\event\'''some_object_action'''. Core events have prefix 'core_'.<br /> * Each event class is defined in a separate file. File name and location must match the class name for the use of auto loading, for example: '''plugindir'''/classes/event/'''something_happened'''.php<br /> * The event identifier suffix has the form ''some_object_action'' ('''something_happened''' in the example above) and should follow our standard naming convention. The last word after underscore is automatically parsed as action, the rest of word is object.<br /> <br /> Decision:[[#Verb_list| Recommended verb list]]<br /> <br /> Examples: \core\event\course_completed, \mod_assign\event\submission_commented, \mod_forum\event\post_shared, \mod_forum\event\post_responded, etc.<br /> <br /> * Ideally, it should be possible to trigger an event without gathering additional information for the event. To reduce the cost of data gathering, specifically the cost of database reads, at least the minimal values needed to trigger an event should be already available in variables.<br /> <br /> An example of triggering an event:<br /> &lt;code php&gt;<br /> $event = \mod_myplugin\event\something_happened::create(array('context' =&gt; $context, 'objectid' =&gt; YYY, 'other' =&gt; ZZZ));<br /> // ... code that may add some record snapshots<br /> $event-&gt;trigger();<br /> &lt;/code&gt;<br /> <br /> <br /> === Use of php autoloading ===<br /> <br /> All new OOP APIs in Moodle 2.6 onwards are going to use class auto loading - see [[Automatic class loading]]. New events use PHP strictly defined namespaces which concentrate all events classes in classes/event/ subdirectory.<br /> <br /> === Why separate classes? ===<br /> Pros<br /> * Maintainability - It is much easier to review, debug, integrate.<br /> * Self documenting, behaviour is combined with definition.<br /> * It is extremely flexible for plugin developers and core devs too.<br /> * Automatically lists events without being installed - PHPDocs as events documentation.<br /> * It is included only when needed using autoloading.<br /> * Self-validating data structure (by PHP).<br /> * Some developers will find it easier to copy whole class files as templates.<br /> Cons<br /> * Big learning curve for developers without OOP skills (all other new subsystems in Moodle already use OOP, you can not code without these skills any more).<br /> * Some developers may find it harder to copy-and-paste examples because they will need to create new class first and use it afterwards (this can be viewed as a benefit because it forces developers to think more about events).<br /> <br /> == Information contained in events ==<br /> <br /> Events have to contain as much information as they can, but this should not affect the performance. That's why part of the information is available in properties, and the rest via methods. This allows for delaying the computation of the data at the time it is really needed, if it ever is.<br /> <br /> === Properties ===<br /> <br /> List of properties that the developer has to pass to the event upon creation, or automatically generated when possible and cost free. Some of those properties not mandatory.<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Property name<br /> ! Title<br /> ! Type<br /> ! Required<br /> ! Comment<br /> |-<br /> | ''eventname''<br /> | Event name<br /> | ''static, automatic from class name''<br /> | -<br /> | Automatically computed by copying class name<br /> |-<br /> | ''component''<br /> | Component<br /> | ''static, automatic from top namespace''<br /> | -<br /> | Component declaring the event, automatically computed from class name.<br /> |-<br /> | ''action''<br /> | Action<br /> | ''static, automatic from last word in class name''<br /> | -<br /> | Can be automatically computed from class name.<br /> |-<br /> | ''target''<br /> | target of action<br /> | ''static, automatic from class name''<br /> | -<br /> | Target on which the action is taken, can be automatically computed from class name.<br /> |-<br /> | objecttable<br /> | Database table name<br /> | static<br /> | optional (Must be set if objetid present)<br /> | Database table name which represents the event object to the best. Never use a relationship table here.<br /> |-<br /> | objectid<br /> | Object ID<br /> | variable<br /> | Optional (Must be set if objettable present)<br /> | Id of the object record from objecttable.<br /> |-<br /> | '''''crud'''''<br /> | Transaction type<br /> | ''static''<br /> | optional<br /> | One of [crud] letters. Statically declared in the event class method init().<br /> |-<br /> | '''''level''''' / '''''edulevel'''''<br /> | Level<br /> | ''static''<br /> | optional<br /> | Level of educational value of the event. Statically declared in the event class method init(). Changed from '''''level''''' to '''''edulevel''''' in Moodle 2.7 (See below for more details)<br /> |-<br /> | contextid<br /> | Context ID<br /> | mandatory<br /> | -<br /> |-<br /> | contextlevel<br /> | Context level<br /> | automatic from context<br /> | -<br /> | This tells you if it was a course, activity, course category, etc.<br /> |-<br /> | contextinstanceid<br /> | Context instanceid<br /> | automatic from context<br /> | -<br /> | Based on context level this may be course id , course module id, course category, etc.<br /> |-<br /> | userid<br /> | User ID<br /> | defaults to current user<br /> | -<br /> | User ID, or 0 when not logged in, or -1 when other (System, CLI, Cron, ...)<br /> |-<br /> | courseid<br /> | Affected course<br /> | defaults to course context from context<br /> | -<br /> | This is used only for contexts at and bellow course level - this can be used to filter events by course (includes all course activities)<br /> |-<br /> | relateduserid<br /> | Affected user<br /> | variable<br /> | optional<br /> | Is this action related to some user? This could be used for some personal timeline view.<br /> |-<br /> | anonymous<br /> | Anonymous action<br /> | variable<br /> | optional (Defaults to 0)<br /> | Is this action anonymous? Reports should ignore events with anonymous set to 1.<br /> |-<br /> | other<br /> | All other data<br /> | variable array<br /> | optional<br /> | Any other fields needed for event description - scalars or arrays, must be serialisable using json_encode()<br /> |-<br /> | timecreated<br /> | Time of the event<br /> | automatic<br /> | -<br /> | Time when the event was triggered.<br /> |}<br /> <br /> * static: It is the same for all event instances of this class.<br /> * variable: It might not be same for all instances of this event class.<br /> * mandatory': Is required in order to trigger the event.<br /> * optional: Is not required to trigger the event.<br /> <br /> ==== Level property ====<br /> <br /> The edulevel property helps defining the educational value of the event. It is intentional that the list is limited to only 3 different constants, having too many options would make it harder for developers to pick the right one(s). We also have to keep in mind that this is not supposed to answer all the questions about a particular event, other event properties like the courseid, the context, the component name can be used with the level to get more granular reports.<br /> <br /> Remember that this is event based. If the user that has triggered the event is not really &quot;participating&quot; because he is an admin, or a manager, then it is the job of the report to filter those. The event itself has a static educational level.<br /> <br /> '''Teaching''' (LEVEL_TEACHING: 1)<br /> <br /> Any event/action that is performed by someone (typically a teacher) and has a teaching value (anything that is affecting the learning experience/environment of the students). This should not be combined with &quot;Participating&quot; events.<br /> <br /> Valid events:<br /> <br /> * A teacher grading a student<br /> * A teacher modifying the course settings<br /> * A teacher adding a new section to the course page<br /> * A teacher modifying a module settings<br /> * A teacher adding a page to course<br /> * A teacher leaving a feedback<br /> <br /> INVALID events:<br /> <br /> * A teacher posting in a forum (it might affect the learning experience, but not necessarily, so the teacher is just participating)<br /> <br /> '''Participating''' (LEVEL_PARTICIPATING: 2)<br /> <br /> Any event/action that is performed by a user, that is related (or could be related) to his learning experience.<br /> <br /> Valid events:<br /> <br /> * A user posting to a forum<br /> * A user submitting an assignment<br /> * A user blogging<br /> * A user reading someone's blog<br /> * A user posting a comment<br /> * A user chatting on a chat activity<br /> * A user viewing the course page<br /> * A user deletes a blog post<br /> <br /> INVALID events:<br /> <br /> * A user updating his profile<br /> * A user visiting someone's profile<br /> * A user viewing his /my/ page<br /> * A user sending a message to another one<br /> <br /> '''Other''' (LEVEL_OTHER: 0)<br /> <br /> Any other action, whether they are related to the site administration, or are specific to user. They do not have any educational value.<br /> <br /> === Methods ===<br /> <br /> The computation of this data is not required by default, but can be accessed by any event observer if need be.<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Method<br /> ! Comment<br /> |-<br /> | get_name()<br /> | Returns localised name of the event, it is the same for all instances.<br /> |-<br /> | get_description()<br /> | Returns non-localised description of one particular event. There are plans to make this localised in future.<br /> |-<br /> | can_view($user)<br /> | This method is deprecated, please do not use this.<br /> |-<br /> | get_url()<br /> | Returns Moodle URL where the event can be observed afterwards. Can be null, if no valid location is present.<br /> |-<br /> | get_legacy_eventname()<br /> | Information necessary for event backward compatibility.<br /> |-<br /> | get_legacy_eventdata()<br /> | Information necessary for event backward compatibility.<br /> |-<br /> | get_legacy_logdata()<br /> | Information necessary for logging backward compatibility.<br /> |}<br /> <br /> ===Record caching===<br /> <br /> The standard event data may not contain all the information observers need. The built-in record snapshot support in events allows developers to attach more auxiliary information when triggering events, it may be for example course record, some record that was just deleted, etc. <br /> * Snapshots are expected to be an exact snapshot of the database table at the instance when the event was triggered.<br /> * Snapshot can be set and requested for any table. If not cached, it defaults to direct $DB-&gt;get_record calls.<br /> * Please be aware that the snapshots are not stored in the event, and cannot be restored.<br /> * Snapshot are supposed to be used only by observers. They should never be used by reports or by the event itself.<br /> * When using a snapshot in an observer, please make sure you are taking proper care of handling exceptions as the record you are requesting could have been deleted in the time, in between your observer is notified about the event and the trigger.<br /> * We recommend all delete event must add snapshot of the deleted record.<br /> <br /> &lt;code php&gt;<br /> $event = \core\event\role_assigned::create(<br /> array('context'=&gt;$context, 'objectid'=&gt;$ra-&gt;roleid, 'relateduserid'=&gt;$ra-&gt;userid,<br /> 'other'=&gt;array('id'=&gt;$ra-&gt;id, 'component'=&gt;$ra-&gt;component, 'itemid'=&gt;$ra-&gt;itemid)));<br /> $event-&gt;add_record_snapshot('role_assignments', $ra);<br /> $event-&gt;trigger();<br /> &lt;/code&gt;<br /> <br /> &lt;code php&gt;<br /> $event = \core\event\role_unassigned::create(<br /> array('context'=&gt;$context, 'objectid'=&gt;$ra-&gt;roleid, 'relateduserid'=&gt;$ra-&gt;userid,<br /> 'other'=&gt;array('id'=&gt;$ra-&gt;id, 'component'=&gt;$ra-&gt;component, 'itemid'=&gt;$ra-&gt;itemid)));<br /> $event-&gt;add_record_snapshot('role_assignments', $ra);<br /> $event-&gt;trigger();<br /> &lt;/code&gt;<br /> <br /> The related methods are:<br /> * public function add_record_snapshot($tablename, $record)<br /> * public function get_record_snapshot($tablename, $id)<br /> <br /> == Events naming convention ==<br /> <br /> Clear event names help developers when reading what events are triggered, and defining the events properties when defining the event class.<br /> <br /> Decision: \&lt;component&gt;\event\&lt;some_object&gt;_&lt;verb&gt;<br /> <br /> === Existing events ===<br /> <br /> List of existing events in Moodle code base, along with their 2.5 couterparts.<br /> <br /> This list is out of date. For a full list of events check out the [https://docs.moodle.org/en/Event_list_report Event list report] which is located in &quot;Site administration &gt; Reports &gt; Event list&quot; of your Moodle installation (2.7+).<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Fully qualified event name<br /> ! 2.5 name<br /> ! Component<br /> ! Object<br /> ! Action (Verb)<br /> ! Comment<br /> |-<br /> | '''assignsubmission_comments\event\comment_created'''<br /> | -<br /> | assignsubmission_comments<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''assignsubmission_comments\event\comment_deleted'''<br /> | -<br /> | assignsubmission_comments<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''assignsubmission_file\event\assessable_uploaded'''<br /> | assessable_file_uploaded<br /> | assignsubmission_file<br /> | assessable<br /> | uploaded<br /> | To be deprecated MDL-35197<br /> |- <br /> | '''assignsubmission_file\event\submission_created'''<br /> | -<br /> | assignsubmission_file<br /> | submission<br /> | created<br /> | <br /> |- <br /> | '''assignsubmission_file\event\submission_updated'''<br /> | -<br /> | assignsubmission_file<br /> | submission<br /> | updated<br /> | <br /> |- <br /> | '''assignsubmission_onlinetext\event\assessable_uploaded'''<br /> | assessable_content_uploaded<br /> | assignsubmission_onlinetext<br /> | assessable<br /> | uploaded<br /> | <br /> |- <br /> | '''assignsubmission_onlinetext\event\submission_created'''<br /> | -<br /> | assignsubmission_onlinetext<br /> | submission<br /> | created<br /> | <br /> |- <br /> | '''assignsubmission_onlinetext\event\submission_updated'''<br /> | -<br /> | assignsubmission_onlinetext<br /> | submission<br /> | updated<br /> | <br /> |- <br /> | '''block_comments\event\comment_created'''<br /> | -<br /> | block_comments<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''block_comments\event\comment_deleted'''<br /> | -<br /> | block_comments<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''booktool_exportimscp\event\book_exported'''<br /> | -<br /> | booktool_exportimscp<br /> | book<br /> | exported<br /> | <br /> |- <br /> | '''booktool_print\event\book_printed'''<br /> | -<br /> | booktool_print<br /> | book<br /> | printed<br /> | <br /> |- <br /> | '''booktool_print\event\chapter_printed'''<br /> | -<br /> | booktool_print<br /> | chapter<br /> | printed<br /> | <br /> |- <br /> | '''core\event\assessable_submitted'''<br /> | -<br /> | core<br /> | assessable<br /> | submitted<br /> | Abstract class <br /> |- <br /> | '''core\event\assessable_uploaded'''<br /> | -<br /> | core<br /> | assessable<br /> | uploaded<br /> | Abstract class <br /> |- <br /> | '''core\event\base'''<br /> | -<br /> | core<br /> | base<br /> | -<br /> | Abstract class <br /> |- <br /> | '''core\event\blog_association_created'''<br /> | -<br /> | core<br /> | blog_association<br /> | created<br /> | <br /> |- <br /> | '''core\event\blog_comment_created'''<br /> | -<br /> | core<br /> | blog_comment<br /> | created<br /> | <br /> |- <br /> | '''core\event\blog_comment_deleted'''<br /> | -<br /> | core<br /> | blog_comment<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\blog_entries_viewed'''<br /> | -<br /> | core<br /> | blog_entries<br /> | viewed<br /> | <br /> |- <br /> | '''core\event\blog_entry_created'''<br /> | blog_entry_added<br /> | core<br /> | blog_entry<br /> | created<br /> | <br /> |- <br /> | '''core\event\blog_entry_deleted'''<br /> | blog_entry_deleted<br /> | core<br /> | blog_entry<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\blog_entry_updated'''<br /> | blog_entry_edited<br /> | core<br /> | blog_entry<br /> | updated<br /> | <br /> |- <br /> | '''core\event\cohort_created'''<br /> | cohort_added<br /> | core<br /> | cohort<br /> | created<br /> | <br /> |- <br /> | '''core\event\cohort_deleted'''<br /> | cohort_deleted<br /> | core<br /> | cohort<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\cohort_member_added'''<br /> | cohort_member_added<br /> | core<br /> | cohort_member<br /> | added<br /> | <br /> |- <br /> | '''core\event\cohort_member_removed'''<br /> | cohort_member_removed<br /> | core<br /> | cohort_member<br /> | removed<br /> | <br /> |- <br /> | '''core\event\cohort_updated'''<br /> | cohort_updated<br /> | core<br /> | cohort<br /> | updated<br /> | <br /> |- <br /> | '''core\event\comment_created'''<br /> | -<br /> | core<br /> | comment<br /> | created<br /> | Abstract class <br /> |- <br /> | '''core\event\comment_deleted'''<br /> | -<br /> | core<br /> | comment<br /> | deleted<br /> | Abstract class <br /> |- <br /> | '''core\event\comments_viewed'''<br /> | -<br /> | core<br /> | comments<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\content_viewed'''<br /> | -<br /> | core<br /> | content<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\course_category_created'''<br /> | -<br /> | core<br /> | course_category<br /> | created<br /> | <br /> |- <br /> | '''core\event\course_category_deleted'''<br /> | course_category_deleted<br /> | core<br /> | course_category<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\course_category_updated'''<br /> | -<br /> | core<br /> | course_category<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_completed'''<br /> | course_completed<br /> | core<br /> | course<br /> | completed<br /> | <br /> |- <br /> | '''core\event\course_completion_updated'''<br /> | -<br /> | core<br /> | course_completion<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_content_deleted'''<br /> | course_content_removed<br /> | core<br /> | course_content<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\course_created'''<br /> | course_created<br /> | core<br /> | course<br /> | created<br /> | <br /> |- <br /> | '''core\event\course_deleted'''<br /> | course_deleted<br /> | core<br /> | course<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\course_module_completion_updated'''<br /> | activity_completion_changed<br /> | core<br /> | course_module_completion<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_module_created'''<br /> | mod_created<br /> | core<br /> | course_module<br /> | created<br /> | <br /> |- <br /> | '''core\event\course_module_deleted'''<br /> | mod_deleted<br /> | core<br /> | course_module<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\course_module_instance_list_viewed'''<br /> | -<br /> | core<br /> | course_module_instance_list<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\course_module_instances_list_viewed'''<br /> | -<br /> | core<br /> | course_module_instances_list<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\course_module_updated'''<br /> | mod_updated<br /> | core<br /> | course_module<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_module_viewed'''<br /> | -<br /> | core<br /> | course_module<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\course_reset_ended'''<br /> | -<br /> | core<br /> | course_reset<br /> | ended<br /> | <br /> |- <br /> | '''core\event\course_reset_started'''<br /> | -<br /> | core<br /> | course_reset<br /> | started<br /> | <br /> |- <br /> | '''core\event\course_restored'''<br /> | course_restored<br /> | core<br /> | course<br /> | restored<br /> | <br /> |- <br /> | '''core\event\course_section_updated'''<br /> | -<br /> | core<br /> | course_section<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_updated'''<br /> | course_updated<br /> | core<br /> | course<br /> | updated<br /> | <br /> |- <br /> | '''core\event\email_failed'''<br /> | -<br /> | core<br /> | email<br /> | failed<br /> | <br /> |- <br /> | '''core\event\group_created'''<br /> | groups_group_created<br /> | core<br /> | group<br /> | created<br /> | <br /> |- <br /> | '''core\event\group_deleted'''<br /> | groups_group_deleted<br /> | core<br /> | group<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\group_member_added'''<br /> | groups_member_added<br /> | core<br /> | group_member<br /> | added<br /> | <br /> |- <br /> | '''core\event\group_member_removed'''<br /> | groups_member_removed<br /> | core<br /> | group_member<br /> | removed<br /> | <br /> |- <br /> | '''core\event\group_updated'''<br /> | groups_group_updated<br /> | core<br /> | group<br /> | updated<br /> | <br /> |- <br /> | '''core\event\grouping_created'''<br /> | groups_grouping_created<br /> | core<br /> | grouping<br /> | created<br /> | <br /> |- <br /> | '''core\event\grouping_deleted'''<br /> | groups_grouping_deleted<br /> | core<br /> | grouping<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\grouping_updated'''<br /> | groups_grouping_updated<br /> | core<br /> | grouping<br /> | updated<br /> | <br /> |- <br /> | '''core\event\manager'''<br /> | -<br /> | core<br /> | manager<br /> | anager<br /> | <br /> |- <br /> | '''core\event\mnet_access_control_created'''<br /> | -<br /> | core<br /> | mnet_access_control<br /> | created<br /> | <br /> |- <br /> | '''core\event\mnet_access_control_updated'''<br /> | -<br /> | core<br /> | mnet_access_control<br /> | updated<br /> | <br /> |- <br /> | '''core\event\note_created'''<br /> | -<br /> | core<br /> | note<br /> | created<br /> | <br /> |- <br /> | '''core\event\note_deleted'''<br /> | -<br /> | core<br /> | note<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\note_updated'''<br /> | -<br /> | core<br /> | note<br /> | updated<br /> | <br /> |- <br /> | '''core\event\notes_viewed'''<br /> | -<br /> | core<br /> | notes<br /> | viewed<br /> | <br /> |- <br /> | '''core\event\role_allow_assign_updated'''<br /> | -<br /> | core<br /> | role_allow_assign<br /> | updated<br /> | <br /> |- <br /> | '''core\event\role_allow_override_updated'''<br /> | -<br /> | core<br /> | role_allow_override<br /> | updated<br /> | <br /> |- <br /> | '''core\event\role_allow_switch_updated'''<br /> | -<br /> | core<br /> | role_allow_switch<br /> | updated<br /> | <br /> |- <br /> | '''core\event\role_assigned'''<br /> | role_assigned<br /> | core<br /> | role<br /> | assigned<br /> | <br /> |- <br /> | '''core\event\role_capabilities_updated'''<br /> | -<br /> | core<br /> | role_capabilities<br /> | updated<br /> | <br /> |- <br /> | '''core\event\role_deleted'''<br /> | -<br /> | core<br /> | role<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\role_unassigned'''<br /> | role_unassigned<br /> | core<br /> | role<br /> | unassigned<br /> | <br /> |- <br /> | '''core\event\user_created'''<br /> | user_created<br /> | core<br /> | user<br /> | created<br /> | <br /> |- <br /> | '''core\event\user_deleted'''<br /> | user_deleted<br /> | core<br /> | user<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\user_enrolment_created'''<br /> | user_enrolled<br /> | core<br /> | user_enrolment<br /> | created<br /> | <br /> |- <br /> | '''core\event\user_enrolment_deleted'''<br /> | user_unenrolled<br /> | core<br /> | user_enrolment<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\user_enrolment_updated'''<br /> | user_enrol_modified<br /> | core<br /> | user_enrolment<br /> | updated<br /> | <br /> |- <br /> | '''core\event\user_list_viewed'''<br /> | -<br /> | core<br /> | user_list<br /> | viewed<br /> | <br /> |- <br /> | '''core\event\user_loggedin'''<br /> | -<br /> | core<br /> | user<br /> | loggedin<br /> | <br /> |- <br /> | '''core\event\user_loggedinas'''<br /> | -<br /> | core<br /> | user<br /> | loggedinas<br /> | <br /> |- <br /> | '''core\event\user_loggedout'''<br /> | user_logout<br /> | core<br /> | user<br /> | loggedout<br /> | <br /> |- <br /> | '''core\event\user_login_failed'''<br /> | -<br /> | core<br /> | user_login<br /> | failed<br /> | <br /> |- <br /> | '''core\event\user_profile_viewed'''<br /> | -<br /> | core<br /> | user_profile<br /> | viewed<br /> | <br /> |- <br /> | '''core\event\user_updated'''<br /> | user_updated<br /> | core<br /> | user<br /> | updated<br /> | <br /> |- <br /> | '''core\event\webservice_function_called'''<br /> | -<br /> | core<br /> | webservice_function<br /> | called<br /> | <br /> |- <br /> | '''core\event\webservice_login_failed'''<br /> | -<br /> | core<br /> | webservice_login<br /> | failed<br /> | <br /> |- <br /> | '''core\event\webservice_service_created'''<br /> | -<br /> | core<br /> | webservice_service<br /> | created<br /> | <br /> |- <br /> | '''core\event\webservice_service_deleted'''<br /> | -<br /> | core<br /> | webservice_service<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\webservice_service_updated'''<br /> | -<br /> | core<br /> | webservice_service<br /> | updated<br /> | <br /> |- <br /> | '''core\event\webservice_service_user_added'''<br /> | -<br /> | core<br /> | webservice_service_user<br /> | added<br /> | <br /> |- <br /> | '''core\event\webservice_service_user_removed'''<br /> | -<br /> | core<br /> | webservice_service_user<br /> | removed<br /> | <br /> |- <br /> | '''core\event\webservice_token_created'''<br /> | -<br /> | core<br /> | webservice_token<br /> | created<br /> | <br /> |- <br /> | '''core\event\webservice_token_sent'''<br /> | -<br /> | core<br /> | webservice_token<br /> | sent<br /> | <br /> |- <br /> | '''logstore_legacy\event\legacy_logged'''<br /> | -<br /> | logstore_legacy<br /> | legacy<br /> | logged<br /> | <br /> |- <br /> | '''mod_assign\event\all_submissions_downloaded'''<br /> | -<br /> | mod_assign<br /> | all_submissions<br /> | downloaded<br /> | <br /> |- <br /> | '''mod_assign\event\assessable_submitted'''<br /> | assessable_submitted<br /> | mod_assign<br /> | assessable<br /> | submitted<br /> | <br /> |- <br /> | '''mod_assign\event\extension_granted'''<br /> | -<br /> | mod_assign<br /> | extension<br /> | granted<br /> | <br /> |- <br /> | '''mod_assign\event\identities_revealed'''<br /> | -<br /> | mod_assign<br /> | identities<br /> | revealed<br /> | <br /> |- <br /> | '''mod_assign\event\marker_updated'''<br /> | -<br /> | mod_assign<br /> | marker<br /> | updated<br /> | <br /> |- <br /> | '''mod_assign\event\statement_accepted'''<br /> | -<br /> | mod_assign<br /> | statement<br /> | accepted<br /> | <br /> |- <br /> | '''mod_assign\event\submission_created'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | created<br /> | Abstract class <br /> |- <br /> | '''mod_assign\event\submission_duplicated'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | duplicated<br /> | <br /> |- <br /> | '''mod_assign\event\submission_graded'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | graded<br /> | <br /> |- <br /> | '''mod_assign\event\submission_locked'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | locked<br /> | <br /> |- <br /> | '''mod_assign\event\submission_status_updated'''<br /> | -<br /> | mod_assign<br /> | submission_status<br /> | updated<br /> | <br /> |- <br /> | '''mod_assign\event\submission_unlocked'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | unlocked<br /> | <br /> |- <br /> | '''mod_assign\event\submission_updated'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | updated<br /> | Abstract class <br /> |- <br /> | '''mod_assign\event\workflow_state_updated'''<br /> | -<br /> | mod_assign<br /> | workflow_state<br /> | updated<br /> | <br /> |- <br /> | '''mod_book\event\chapter_created'''<br /> | -<br /> | mod_book<br /> | chapter<br /> | created<br /> | <br /> |- <br /> | '''mod_book\event\chapter_deleted'''<br /> | -<br /> | mod_book<br /> | chapter<br /> | deleted<br /> | <br /> |- <br /> | '''mod_book\event\chapter_updated'''<br /> | -<br /> | mod_book<br /> | chapter<br /> | updated<br /> | <br /> |- <br /> | '''mod_book\event\chapter_viewed'''<br /> | -<br /> | mod_book<br /> | chapter<br /> | viewed<br /> | <br /> |- <br /> | '''mod_book\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_book<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_book\event\course_module_viewed'''<br /> | -<br /> | mod_book<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_chat\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_chat<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_chat\event\message_sent'''<br /> | -<br /> | mod_chat<br /> | message<br /> | sent<br /> | <br /> |- <br /> | '''mod_chat\event\sessions_viewed'''<br /> | -<br /> | mod_chat<br /> | sessions<br /> | viewed<br /> | <br /> |- <br /> | '''mod_choice\event\answer_submitted'''<br /> | -<br /> | mod_choice<br /> | answer<br /> | submitted<br /> | <br /> |- <br /> | '''mod_choice\event\answer_updated'''<br /> | -<br /> | mod_choice<br /> | answer<br /> | updated<br /> | <br /> |- <br /> | '''mod_choice\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_choice<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_choice\event\course_module_viewed'''<br /> | -<br /> | mod_choice<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_choice\event\report_viewed'''<br /> | -<br /> | mod_choice<br /> | report<br /> | viewed<br /> | <br /> |- <br /> | '''mod_data\event\comment_created'''<br /> | -<br /> | mod_data<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''mod_data\event\comment_deleted'''<br /> | -<br /> | mod_data<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''mod_data\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_data<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_data\event\course_module_viewed'''<br /> | -<br /> | mod_data<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_data\event\field_created'''<br /> | -<br /> | mod_data<br /> | field<br /> | created<br /> | <br /> |- <br /> | '''mod_data\event\field_deleted'''<br /> | -<br /> | mod_data<br /> | field<br /> | deleted<br /> | <br /> |- <br /> | '''mod_data\event\field_updated'''<br /> | -<br /> | mod_data<br /> | field<br /> | updated<br /> | <br /> |- <br /> | '''mod_data\event\record_created'''<br /> | -<br /> | mod_data<br /> | record<br /> | created<br /> | <br /> |- <br /> | '''mod_data\event\record_deleted'''<br /> | -<br /> | mod_data<br /> | record<br /> | deleted<br /> | <br /> |- <br /> | '''mod_data\event\record_updated'''<br /> | -<br /> | mod_data<br /> | record<br /> | updated<br /> | <br /> |- <br /> | '''mod_data\event\template_updated'''<br /> | -<br /> | mod_data<br /> | template<br /> | updated<br /> | <br /> |- <br /> | '''mod_data\event\template_viewed'''<br /> | -<br /> | mod_data<br /> | template<br /> | viewed<br /> | <br /> |- <br /> | '''mod_feedback\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_feedback<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_feedback\event\course_module_viewed'''<br /> | -<br /> | mod_feedback<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_feedback\event\response_deleted'''<br /> | -<br /> | mod_feedback<br /> | response<br /> | deleted<br /> | <br /> |- <br /> | '''mod_feedback\event\response_submitted'''<br /> | -<br /> | mod_feedback<br /> | response<br /> | submitted<br /> | <br /> |- <br /> | '''mod_folder\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_folder<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_folder\event\course_module_viewed'''<br /> | -<br /> | mod_folder<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_folder\event\folder_updated'''<br /> | -<br /> | mod_folder<br /> | folder<br /> | updated<br /> | <br /> |- <br /> | '''mod_forum\event\assessable_uploaded'''<br /> | assessable_content_uploaded<br /> | mod_forum<br /> | assessable<br /> | uploaded<br /> | <br /> |- <br /> | '''mod_forum\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_forum<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_forum\event\course_searched'''<br /> | -<br /> | mod_forum<br /> | course<br /> | searched<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_created'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | created<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_deleted'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | deleted<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_moved'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | moved<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_updated'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | updated<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_viewed'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | viewed<br /> | <br /> |- <br /> | '''mod_forum\event\forum_viewed'''<br /> | -<br /> | mod_forum<br /> | forum<br /> | viewed<br /> | <br /> |- <br /> | '''mod_forum\event\post_created'''<br /> | -<br /> | mod_forum<br /> | post<br /> | created<br /> | <br /> |- <br /> | '''mod_forum\event\post_deleted'''<br /> | -<br /> | mod_forum<br /> | post<br /> | deleted<br /> | <br /> |- <br /> | '''mod_forum\event\post_updated'''<br /> | -<br /> | mod_forum<br /> | post<br /> | updated<br /> | <br /> |- <br /> | '''mod_forum\event\readtracking_disabled'''<br /> | -<br /> | mod_forum<br /> | readtracking<br /> | disabled<br /> | <br /> |- <br /> | '''mod_forum\event\readtracking_enabled'''<br /> | -<br /> | mod_forum<br /> | readtracking<br /> | enabled<br /> | <br /> |- <br /> | '''mod_forum\event\subscribers_viewed'''<br /> | -<br /> | mod_forum<br /> | subscribers<br /> | viewed<br /> | <br /> |- <br /> | '''mod_forum\event\subscription_created'''<br /> | -<br /> | mod_forum<br /> | subscription<br /> | created<br /> | <br /> |- <br /> | '''mod_forum\event\subscription_deleted'''<br /> | -<br /> | mod_forum<br /> | subscription<br /> | deleted<br /> | <br /> |- <br /> | '''mod_forum\event\userreport_viewed'''<br /> | -<br /> | mod_forum<br /> | userreport<br /> | viewed<br /> | <br /> |- <br /> | '''mod_glossary\event\comment_created'''<br /> | -<br /> | mod_glossary<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''mod_glossary\event\comment_deleted'''<br /> | -<br /> | mod_glossary<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''mod_lesson\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_lesson<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lesson\event\course_module_viewed'''<br /> | -<br /> | mod_lesson<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lesson\event\essay_assessed'''<br /> | -<br /> | mod_lesson<br /> | essay<br /> | assessed<br /> | <br /> |- <br /> | '''mod_lesson\event\essay_attempt_viewed'''<br /> | -<br /> | mod_lesson<br /> | essay_attempt<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lesson\event\highscore_added'''<br /> | -<br /> | mod_lesson<br /> | highscore<br /> | added<br /> | <br /> |- <br /> | '''mod_lesson\event\highscores_viewed'''<br /> | -<br /> | mod_lesson<br /> | highscores<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lesson\event\lesson_ended'''<br /> | -<br /> | mod_lesson<br /> | lesson<br /> | ended<br /> | <br /> |- <br /> | '''mod_lesson\event\lesson_started'''<br /> | -<br /> | mod_lesson<br /> | lesson<br /> | started<br /> | <br /> |- <br /> | '''mod_lti\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_lti<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lti\event\course_module_viewed'''<br /> | -<br /> | mod_lti<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lti\event\unknown_service_api_called'''<br /> | lti_unknown_service_api_call<br /> | mod_lti<br /> | unknown_service_api<br /> | called<br /> | <br /> |- <br /> | '''mod_page\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_page<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_page\event\course_module_viewed'''<br /> | -<br /> | mod_page<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_quiz\event\attempt_abandoned'''<br /> | quiz_attempt_abandoned<br /> | mod_quiz<br /> | attempt<br /> | abandoned<br /> | <br /> |- <br /> | '''mod_quiz\event\attempt_becameoverdue'''<br /> | quiz_attempt_overdue<br /> | mod_quiz<br /> | attempt<br /> | becameoverdue<br /> | <br /> |- <br /> | '''mod_quiz\event\attempt_started'''<br /> | quiz_attempt_started<br /> | mod_quiz<br /> | attempt<br /> | started<br /> | <br /> |- <br /> | '''mod_quiz\event\attempt_submitted'''<br /> | quiz_attempt_submitted<br /> | mod_quiz<br /> | attempt<br /> | submitted<br /> | <br /> |- <br /> | '''mod_resource\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_resource<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_resource\event\course_module_viewed'''<br /> | -<br /> | mod_resource<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\attempt_deleted'''<br /> | -<br /> | mod_scorm<br /> | attempt<br /> | deleted<br /> | <br /> |- <br /> | '''mod_scorm\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_scorm<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\course_module_viewed'''<br /> | -<br /> | mod_scorm<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\interactions_viewed'''<br /> | -<br /> | mod_scorm<br /> | interactions<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\report_viewed'''<br /> | -<br /> | mod_scorm<br /> | report<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\sco_launched'''<br /> | -<br /> | mod_scorm<br /> | sco<br /> | launched<br /> | <br /> |- <br /> | '''mod_scorm\event\tracks_viewed'''<br /> | -<br /> | mod_scorm<br /> | tracks<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\user_report_viewed'''<br /> | -<br /> | mod_scorm<br /> | user_report<br /> | viewed<br /> | <br /> |- <br /> | '''mod_url\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_url<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_url\event\course_module_viewed'''<br /> | -<br /> | mod_url<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\comment_created'''<br /> | -<br /> | mod_wiki<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''mod_wiki\event\comment_deleted'''<br /> | -<br /> | mod_wiki<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''mod_wiki\event\comments_viewed'''<br /> | -<br /> | mod_wiki<br /> | comments<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_wiki<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\course_module_viewed'''<br /> | -<br /> | mod_wiki<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_created'''<br /> | -<br /> | mod_wiki<br /> | page<br /> | created<br /> | <br /> |- <br /> | '''mod_wiki\event\page_deleted'''<br /> | -<br /> | mod_wiki<br /> | page<br /> | deleted<br /> | <br /> |- <br /> | '''mod_wiki\event\page_diff_viewed'''<br /> | -<br /> | mod_wiki<br /> | page_diff<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_history_viewed'''<br /> | -<br /> | mod_wiki<br /> | page_history<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_locks_deleted'''<br /> | -<br /> | mod_wiki<br /> | page_locks<br /> | deleted<br /> | <br /> |- <br /> | '''mod_wiki\event\page_map_viewed'''<br /> | -<br /> | mod_wiki<br /> | page_map<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_updated'''<br /> | -<br /> | mod_wiki<br /> | page<br /> | updated<br /> | <br /> |- <br /> | '''mod_wiki\event\page_version_deleted'''<br /> | -<br /> | mod_wiki<br /> | page_version<br /> | deleted<br /> | <br /> |- <br /> | '''mod_wiki\event\page_version_restored'''<br /> | -<br /> | mod_wiki<br /> | page_version<br /> | restored<br /> | <br /> |- <br /> | '''mod_wiki\event\page_version_viewed'''<br /> | -<br /> | mod_wiki<br /> | page_version<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_viewed'''<br /> | -<br /> | mod_wiki<br /> | page<br /> | viewed<br /> | <br /> |- <br /> | '''mod_workshop\event\assessable_uploaded'''<br /> | assessable_content_uploaded<br /> | mod_workshop<br /> | assessable<br /> | uploaded<br /> | <br /> |- <br /> | '''mod_workshop\event\assessment_evaluated'''<br /> | -<br /> | mod_workshop<br /> | assessment<br /> | evaluated<br /> | <br /> |- <br /> | '''mod_workshop\event\assessment_evaluations_reset'''<br /> | -<br /> | mod_workshop<br /> | assessment_evaluations<br /> | reset<br /> | <br /> |- <br /> | '''mod_workshop\event\assessment_reevaluated'''<br /> | -<br /> | mod_workshop<br /> | assessment<br /> | reevaluated<br /> | <br /> |- <br /> | '''mod_workshop\event\course_module_viewed'''<br /> | workshop_viewed<br /> | mod_workshop<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_workshop\event\instances_list_viewed'''<br /> | -<br /> | mod_workshop<br /> | instances_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_workshop\event\phase_switched'''<br /> | -<br /> | mod_workshop<br /> | phase<br /> | switched<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_assessed'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | assessed<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_created'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | created<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_reassessed'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | reassessed<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_updated'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | updated<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_viewed'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | viewed<br /> | <br /> |- <br /> | '''report_log\event\content_viewed'''<br /> | -<br /> | report_log<br /> | content<br /> | viewed<br /> | <br /> |- <br /> | '''report_loglive\event\content_viewed'''<br /> | -<br /> | report_loglive<br /> | content<br /> | viewed<br /> | <br /> |- <br /> | '''report_outline\event\content_viewed'''<br /> | -<br /> | report_outline<br /> | content<br /> | viewed<br /> | <br /> |- <br /> | '''report_participation\event\content_viewed'''<br /> | -<br /> | report_participation<br /> | content<br /> | viewed<br /> | <br /> |- <br /> | '''report_stats\event\content_viewed'''<br /> | -<br /> | report_stats<br /> | content<br /> | viewed<br /> | <br /> |- <br /> |}<br /> <br /> === Verb list ===<br /> All events must use a verb from this list. New verbs should be added to this list if required.<br /> {| class=&quot;nicetable&quot;<br /> |-<br /> !verb<br /> !Explanation<br /> !Source<br /> |-<br /> |abandoned<br /> |When a attempt is abandoned by user (Quiz attempt)<br /> |Moodle<br /> |-<br /> |accepted<br /> |Example: Accepting a statement when submitting an assignment.<br /> |Moodle<br /> |-<br /> |added<br /> | Used to represent &quot;something that already exists is now part of/bound to another entity&quot;. Examples: &quot;Admin added role to user X&quot;, &quot;Admin added user X to group A&quot;. Wrong example: &quot;User added course in category&quot; because it is a 'move' action, except if a course can be part of multiple categories. The good examples work because: A user can have multiple roles, a user can be in multiple groups.<br /> |Moodle<br /> |-<br /> |answered<br /> | Indicates the actor responded to a Question<br /> |Tincan<br /> |-<br /> |assessed<br /> | Some submitted material has been assessed<br /> |Moodle<br /> |-<br /> |assigned<br /> | Assign some privilege or role to user.<br /> |Moodle<br /> |-<br /> |attempted<br /> | Trying to do an activity. Example: attempting a Math class.<br /> |Tincan<br /> |-<br /> |awarded<br /> | ex:-teacher awarded student a badge.<br /> |Moodle<br /> |-<br /> |backedup<br /> | When a backup has been performed.<br /> |Moodle <br /> |-<br /> |becomeoverdue<br /> | When an activity is overdue Example: Quiz attempt is overdue<br /> |Moodle <br /> |-<br /> |called<br /> | When a call to something is made like an API @see unknown_service_api_called.php<br /> |Moodle<br /> |-<br /> |commented<br /> |Offered an opinion or written experience of the activity. Can be used with the learner as the actor or a system as an actor. Comments can be sent from either party with the idea that the other will read and react to the content.<br /> |Tincan<br /> |-<br /> |completed<br /> |To experience the activity in its entirety. Used to affirm the completion of content. This can be simply experiencing all the content, be tied to objectives or interactions, or determined in any other way. Any content that has been initialized, but not yet completed, should be considered incomplete. There is no verb to 'incomplete' an activity, one would void the statement which completes the activity.&quot;<br /> |Tincan<br /> |-<br /> |created<br /> |Used to represent &quot;something new has been created&quot;.<br /> |Moodle<br /> |-<br /> |deleted<br /> |Used to indicate the object in context was deleted.<br /> |Moodle<br /> |-<br /> |disabled<br /> |When an activity is disabled. Example: forum read tracking disabled.<br /> |Moodle<br /> |-<br /> |downloaded<br /> |When a user download file from user. Example submission/report downloaded.<br /> |Moodle<br /> |-<br /> |duplicated<br /> |For something that has been copied.<br /> |Moodle<br /> |-<br /> |enabled<br /> |When some setting is enabled. Example: forum read tracking enabled.<br /> |Moodle<br /> |-<br /> |ended<br /> |When a process ends. Example: Lesson ended or course reset ended.<br /> |Moodle<br /> |-<br /> |evaluated<br /> |Material has been evaluated.<br /> |Moodle<br /> |-<br /> |exported<br /> |When a report is exported in certain format.<br /> |Moodle<br /> |-<br /> |failed<br /> |Learner did not perform the activity to a level of pre-determined satisfaction. Used to affirm the lack of success a learner experienced within the learning content in relation to a threshold. If the user performed below the minimum to the level of this threshold, the content is 'failed'. The opposite of 'passed'. This is also used in case when message sending is failed.<br /> |Tincan<br /> |-<br /> |graded<br /> |Used to represent an activity was graded.<br /> |Moodle<br /> |-<br /> |granted<br /> |User is granted some extension or capability. Example: extension granted for submission.<br /> |Moodle<br /> |-<br /> |imported<br /> |The act of moving an object into another location or system.<br /> |Tincan<br /> |-<br /> |launched<br /> |When an external object is launched. Try consider started if there is related stopped event.<br /> |Moodle<br /> |-<br /> |locked<br /> |When an activity is locked. Should have a related unlocked event.<br /> |Moodle<br /> |-<br /> |loggedin/loggedout<br /> | For login and logout.<br /> |Moodle<br /> |-<br /> |loggedinas<br /> | If user is logged in as different user. This is used by only one event (user_loggedinas). Adding this verb makes event name more clear, then using loggedin verb.<br /> |Moodle<br /> |-<br /> |locked<br /> |<br /> |Moodle<br /> |-<br /> |moved<br /> | Used to indicate the object in context was moved.<br /> |Moodle<br /> |-<br /> |passed<br /> |Used to affirm the success a learner experienced within the learning content in relation to a threshold. If the user performed at a minimum to the level of this threshold, the content is 'passed'. The opposite of 'failed'.<br /> |Tincan<br /> |-<br /> |printed<br /> |Something is printed.<br /> |Moodle<br /> |-<br /> |reassessed<br /> |Submitted material has been assessed again.<br /> |Moodle<br /> |-<br /> |reevaluated<br /> |Material has been evaluated again.<br /> |Moodle<br /> |-<br /> |removed<br /> |By opposition to &quot;Added&quot;. This does not mean that the object has been deleted, but removed from the entity, or not bound to it any more.<br /> |Moodle<br /> |-<br /> |reset<br /> |Sets one or more properties back to the default value.<br /> |Moodle<br /> |-<br /> |restored<br /> |When restoring a backup. Rolling back to a previous state.<br /> |Moodle<br /> |-<br /> |revealed<br /> |Some identity is revealed. Example: Identities revealed after blind marking.<br /> |Moodle<br /> |-<br /> |searched<br /> |Something is searched. Example: searched in course.<br /> |Moodle<br /> |-<br /> |sent<br /> |Message sent.<br /> |Moodle<br /> |-<br /> |started<br /> |Some activity started<br /> |Moodle<br /> |-<br /> |submitted<br /> |This is very close to &quot;Attempted&quot;. Depends on context which one should be used. For example:- &quot;Admin submitted a form. Student attempted a quiz.&quot; is correct, however some cases might not be as clear as the previous example. We can say both &quot;Student submitted an assignment&quot; or &quot;student attempted an assignment&quot;. We need to make the difference clear.<br /> |Moodle<br /> |-<br /> |suspended<br /> | Suspend something. (example a user)<br /> | Tincan (However the context is different)<br /> |-<br /> |switched<br /> |Something has been switched. For example:- The workshop phase has been switched to assessment&quot;<br /> |Moodle<br /> |-<br /> |unassigned<br /> |As opposed to assigned. When some role is unassigned.<br /> |Moodle<br /> |-<br /> |unlocked<br /> |<br /> |Moodle<br /> |-<br /> |upgraded<br /> |Something was upgraded, some module probably<br /> |Moodle<br /> |-<br /> |updated<br /> |Used to indicate the object in context was updated. Simple example is &quot;Admin updated course xyz&quot;.<br /> |Moodle<br /> |-<br /> |uploaded<br /> |When an assignment is uploaded.<br /> |Moodle<br /> |-<br /> |viewed<br /> |Something has been viewed. For example:- &quot;Student viewed chapter 1 of book 1.&quot;<br /> |Moodle<br /> |-<br /> |}<br /> <br /> === Rules ===<br /> <br /> ==== Use singular ====<br /> <br /> Plurals must be used on objects when it's a ''One to Many'' relationship. Ex: bulk import, mass deletion, ... In any other case, use the singular.<br /> <br /> ==== Ends with a verb ====<br /> <br /> The last word (after the last underscore) must be a verb.<br /> <br /> === Deprecated events ===<br /> Following are the events that were supported in 2.5, but deprecated in 2.6 or later<br /> <br /> groups_groupings_deleted (see MDL-41312)<br /> <br /> groups_groupings_groups_removed (see MDL-41312)<br /> <br /> groups_groups_deleted (see MDL-41312)<br /> <br /> groups_members_removed (see MDL-41312)<br /> <br /> == Shared events ==<br /> <br /> Decision: Not supported at this stage.<br /> <br /> In Moodle 2.5 we have a good example of a shared event: 'assessable_content_uploaded' which is triggered in ''forum'', 'assignment'' and ''workshop''.<br /> <br /> The problem with shared events is that we cannot easily track what component triggered them. Of course we could add a new property to the event to keep track of that, but we would soon need more information and more properties. Also, in the case of a logger, the event received would be unique, where in fact it should be considered different depending on the component firing it.<br /> <br /> In our first implementation, we will create one specific event per module. This flexibility does not prevent any observer from capturing them, but still makes sure that the consistency and specificity of each event is maintained.<br /> <br /> It could happen that some events are defined in core and shared, but this should not really happen as low-level APIs should trigger the event, and a module should call that low API instead of doing the job itself.<br /> <br /> == One to many ==<br /> <br /> Decision: Each event should have a one to one relationship. We can reconsider this at a later stage, if the performance hit is extremely high.<br /> <br /> In 2.5, some events are triggered when an action happens on multiple objects. We have to decide whether we want to keep supporting ''One to Many'' events or not.<br /> <br /> Keeping a list of all changes for multiple actions may be problematic because you would have to keep them all in memory until all things are processed. This might also result in the order of events being incorrect. The only correct solution seems to be to trigger each item individually and then many things at the end. Performance needs to be improved elsewhere...<br /> <br /> === Accuracy ===<br /> <br /> When uploading a bunch of users using the CSV upload feature, if only one event is triggered, it means that the observers of ''user_created'' won't be triggered. And so some functionality can be lost as, as a plugin developer, I expect this ''user_created'' to be triggered regardless of the way they have been uploaded. Of course, the developer could observe the event ''bulk_user_imported'', but that means that he could miss some relevant observers.<br /> <br /> This applies to existing events.<br /> <br /> === Performance ===<br /> <br /> Triggering one event is cheaper then repeating the same events x number of times...<br /> <br /> === Information tracking ===<br /> <br /> A ''bulk'' event, might not be verbose enough to allow for proper logging afterwards. Though this is the responsibility of the logger, we probably want to make it easy to store relevant information.<br /> <br /> === Double event ===<br /> <br /> In the case of a bulk user import, if we were to trigger an event per user created, we probably want to trigger one event 'user_bulk_upload_started' when the action starts.<br /> <br /> == Unit Testing ==<br /> <br /> With unit testing for this system we want to assert the following:<br /> <br /> * That event strict validation and custom validation works.<br /> * Missing event data is auto filled with accurate data.<br /> * Typos in properties passed to ::create() are captured (if we decide to validate).<br /> * The legacy methods return the expected values (use assertEventLegacyData() and assertEventLegacyData())<br /> * The class properties are correctly overridden (crud, level, action, object, ...).<br /> * The properties automatically generated (component, name, ...) are correct.<br /> * Events are dispatched to the corresponding observers.<br /> * Events are dispatched to the corresponding legacy handlers.<br /> * Events are dispatched to the * observers.<br /> * Events perform an add_to_log() if it has legacy log data.<br /> * 'Events restore' restored the whole event data, and does not miss any information.<br /> * 'Events restore' does not generate any extra information.<br /> * Event methods should check context object or avoid using it, as context might not be valid at time of event restore (use assertEventContextNotUsed())<br /> <br /> = PHP docs =<br /> * All events php docs must include @since parameter, indicating when the event was first included in standard Moodle distribution.<br /> * All events must declare the $other properties using mark down in the php docs. This later might be converted to a self documenting structure. (See MDL-45108)<br /> <br /> &lt;code php&gt;<br /> /**<br /> * blog_association_created<br /> *<br /> * Class for event to be triggered when a new blog entry is associated with a context.<br /> *<br /> * @property-read array $other {<br /> * Extra information about event.<br /> *<br /> * - string associatetype: type of blog association, course/coursemodule.<br /> * - int blogid: id of blog.<br /> * - int associateid: id of associate.<br /> * - string subject: blog subject.<br /> * }<br /> *<br /> * @package core<br /> * @since Moodle 2.7<br /> * @copyright 2013 onwards Ankit Agarwal<br /> * @license http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later<br /> */<br /> &lt;/code&gt;<br /> <br /> = Example events =<br /> <br /> == Assignment ==<br /> <br /> Assumption: Course contains groups with students in each group.<br /> <br /> '''1.''' Teacher creates an assignment with group mode set to 'Separate groups' and Feedback type set to comments and files.<br /> *Event: User 'Teacher' has created assignment 'B' in course 'C101'.<br /> '''2.''' A student views the assignment.<br /> *Event: User 'Student' has viewed assignment 'B' in course 'C101'.<br /> '''3.''' A member from one of the groups submits an assignment<br /> *Event: User 'Student' has added a submission for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: Email sent to the teacher and all students in that group.<br /> '''4.''' User 'Adrian' adds some changes to the assignment and updates it.<br /> *Event: User 'Adrian' has updated the submission for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: Email sent to the teacher and all students in that group.<br /> '''5.''' Teacher views the assignment.<br /> *Event: User 'Teacher' has viewed assignment 'B' in course 'C101'.<br /> '''6.''' Teacher clicks on 'View/grade all submissions'<br /> *Event: User 'Teacher' has viewed the assignment 'B' grade area in course 'C101'.<br /> '''7.''' Teacher clicks to grade the student's submission.<br /> *Event: User 'Teacher' has viewed the submission for user 'student' for assignment 'B' in course 'C101'.<br /> '''8.''' Teacher marks the assignment with the setting 'Apply grades and feedback to entire group' set to 'Yes' leaving a comment and a file.<br /> *Event: User 'Teacher' has marked assignment 'B' for group 'C' in course 'C101'.<br /> *Event: User 'Teacher' has left a comment for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: User 'Teacher' has uploaded a feedback file for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: User 'Teacher' has uploaded a file to the course 'C101'.<br /> *Event: Email sent to user 'Student' notifying them their submission for assignment 'B' has been marked. - This is done for all users in the group.<br /> '''9.''' User 'Adrian' views the feedback.<br /> *Event: User 'Adrian' has viewed assignment 'B' in course 'C101'.<br /> '''10.''' User 'Adrian' opens the feedback file.<br /> *Event: User 'Adrian' has viewed the file 'A' for assignment 'B' in course 'C101'.<br /> '''11.''' User 'Adrian' adds some changes to the assignment insulting the teachers marking and updates it.<br /> *Event: User 'Adrian' has updated the submission for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: Email sent to user 'Teacher' notifying them that user 'Adrian' has updated the submission for assignment 'B'.<br /> *Event: Email sent to user 'Student' notifying them their submission for assignment 'B' has been updated. - This is done for all users in the group.<br /> '''12.''' The teacher clicks directly on the link in the email to be taken to the grading page.<br /> *Event: User 'Teacher' has viewed the submission for user 'student' for assignment 'B' in course 'C101'.<br /> '''13.''' The teacher is upset due to the harsh comments and decides to mark Adrian down, but not the rest of the group by setting 'Apply grades and feedback to entire group' set to 'No'.<br /> *Event: User 'Teacher' has marked assignment 'B' for user 'Adrian' in course 'C101'.<br /> *Event: User 'Teacher' has left a comment for assignment 'B' for user 'Adrian' in course 'C101'.<br /> *Event: User 'Teacher' has uploaded a feedback file for assignment 'B' for user 'Adrian' in course 'C101'.<br /> *Event: Email sent to user 'Adrian' notifying them their submission for assignment 'B' has been marked.<br /> <br /> = FAQs =<br /> <br /> ; Why not use create events in core subsystems? : Because we could not see all core events in one place, it would create problems when naming event classes and finally subsystems are incomplete, we would have to add more now because we could not move the events in the future.<br /> <br /> = Possible future work = <br /> * MDL-45108 &quot;Other&quot; parameters should be defined in a method similar to webservices<br /> * MDL-45217 Create traits for refactoring event triggers<br /> * MDL-42897 Converting completion to use events<br /> * MDL-42898 Develop a timeline page/block<br /> <br /> = See Also =<br /> [[Logging 2]] <br /> <br /> [[Tin Can]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Events_API&diff=44522 2014-04-24T08:14:46Z

<p>Ankitfrenz: /* PHP dpcs = */</p> <hr /> <div>{{Infobox Project<br /> |name = Events 2<br /> |state = Implementation in progress<br /> |tracker = MDL-39797 , MDL-39952, MDL-39846<br /> |discussion = https://moodle.org/mod/forum/discuss.php?d=229425<br /> |assignee = Backend Team<br /> }}<br /> <br /> = What are events? =<br /> <br /> Events are atomic pieces of information describing something that happened in Moodle. Events are primarily the result of user actions, but could also be the result of the [[:en:Cron|cron]] process or administration actions [[:en:Administration via command line|undertaken via the command line]].<br /> <br /> When an action takes place, an event is created by a [[Core APIs|core API]] or [[Plugins|plugin]]. The Events system then disseminates this event information to observers registered for this event. In this way, the events system acts as a communication backbone throughout the Moodle system.<br /> <br /> Event observers can not modify event data or interrupt the dispatching of events, it is a one way communication channel.<br /> <br /> = Why is a new events system needed? =<br /> <br /> The need to improve the Events system was prompted by a need for a richer and more efficient logging system, however the benefits of this improvement will be useful to other parts of Moodle that observe event information.<br /> <br /> * The events need to be more strictly defined if we want to use them for new logging and other advanced use cases. They need to contain a lot more information in a standardised way (such as most fields from current log table and log_actions table).<br /> * Complex data types were allowed in old events which was causing major problems when serialising/storing/unserializing the data.<br /> * The logging and events contain similar information and are triggered at the same places, new events would remove this code duplication. All events should be loggable and all current log entries should be triggered as events.<br /> * The logging system will become an event observer, listening to all events and directing them to logging storage plugins in a controllable way.<br /> * It will be possible to subscribe to '*' event, which would allow a system to potentially observe, and selectively deal with, all events. Current handlers do not get event name which makes this problematic.<br /> * Current event handlers may trigger exceptions during site upgrade which would lead to fatal upgrade problems. The new design eliminates this.<br /> * Failure in handlers blocked dispatching of subsequent events. Instead problems in new observers would be only logged and execution would continue normally.<br /> * Current execution of external handlers during DB transactions blocks other handlers. This would be eliminated by in-memory buffer for external events.<br /> * It would good to have observer priority.<br /> * Nested events are not dispatched sequentially, it would change the order of events received in lower priority handlers.<br /> <br /> = Performance =<br /> Some basic profiling has been conducted.<br /> <br /> There is a general plan to complete pre- and post-implementation testing as development happens. The new system will be imemented in parallel with the old one which should help with comparison of new and old logging and event triggering performance on each page.<br /> <br /> Our aim is to trigger more events and log more information, which is going to impact on performance. We hope to offset that impact by improving log storage, simplifying event dispatching and adding other core performance improvements. The proposed class structure of the base event should allow some new advanced techniques, which may also improve performance in some scenarios.<br /> <br /> More details will be added to this section soon.<br /> <br /> = Events API =<br /> <br /> Each plugin will define the events that it can report (trigger) by extending an abstract base class, once for each possible event. This approach will have several benefits.<br /> ; Events will be active objects<br /> : When they are triggered and possibly after they are reinstantiated (say, when they are retrieved from a log), an event object will be able to provide callback functions for various purposes (such as capability checks).<br /> ; Automatic inclusion<br /> : Event class definitions will be automatically included when needed, without having to maintain lists of known event types. New event definitions can be added without the need to upgrade, only purging of MUC cache is required after adding new observer.<br /> ; Maintainability<br /> : It will be easy to add new events and migrate existing events. Code review will be simplified because there will be less duplication of code when triggering events and all event related information/code will be concentrated in one file in fixed locations.<br /> ; Self documenting<br /> : The behaviour of events will be combined with the definition of events in one place (file). It will be easy for event observer writers to know what events a plugin can trigger. This includes support for autocompletion and code inspection in modern IDEs.<br /> ; Quick, self-validating data structure<br /> : As events are instantiated objects, the PHP processor will validate the structure and type of event classes. This does not ensure data value validity, but does give some assurance of consistency and it also detects common typos.<br /> <br /> == Backwards compatibility and migration ==<br /> <br /> Events:<br /> * Moodle core and standard plugins will replace all calls to the events_trigger() function with new events classes.<br /> * For events that already exist in Moodle 2.5 the additional legacy information should be added to the event data (in properties 'legacyeventname' and 'legacyeventdata'.<br /> * The function events_trigger() will continue working as before, but it will be called automatically after a new event is processed using the 'legacyeventname' and 'legacyeventdata'.<br /> * The legacy events handling code will be maintained separately and will continue being supported in Moodle 2.x. New legacy events will not be added.<br /> * Existing legacy event handlers will be migrated to new event handlers accepting new event class instances.<br /> * More subsystems may be migrated to events-handlers, ex.: gradebook history.<br /> <br /> Logging:<br /> * Function add_to_log() and all logging internals will continue working as before.<br /> * Existing add_to_log() parameters will be migrated inside new events method get_legacy_log_data() and core_event_base::trigger() will call add_to_log() automatically (this will depend on $CFG-&gt;loglifetime setting for performance reasons).<br /> <br /> == Event dispatching and observers ==<br /> <br /> The new event dispatching system is completely separate from the old events code. Original event handlers are now called observers with the description stored in the same db/events.php file, but as a new array with a different format.<br /> <br /> === Event observers ===<br /> <br /> The observers are described in db/events.php in the array $observers, the array is not indexed and contains a list of observers defined as an array with the following properties;<br /> * eventname - event class name or &quot;*&quot; indicating all events. All events must use namespace, ex.: ''\plugintype_pluginname\event\something_happened''.<br /> * callback - PHP callable type.<br /> * includefile - optional. File to be included before calling the observer. Path relative to dirroot.<br /> * priority - optional. Defaults to 0. Observers with higher priority are notified first.<br /> * internal - optional. Defaults to true. Non-internal observers are not called during database transactions, but instead after a successful commit of the transaction.<br /> <br /> &lt;code php&gt;<br /> <br /> $observers = array(<br /> <br /> array(<br /> 'eventname' =&gt; '\core\event\sample_executed',<br /> 'callback' =&gt; 'core_event_sample_observer::observe_one',<br /> ),<br /> <br /> array(<br /> 'eventname' =&gt; '\core\event\sample_executed',<br /> 'callback' =&gt; 'core_event_sample_observer::external_observer',<br /> 'priority' =&gt; 200,<br /> 'internal' =&gt; false,<br /> ),<br /> <br /> array(<br /> 'eventname' =&gt; '*',<br /> 'callback' =&gt; 'core_event_sample_observer::observe_all',<br /> 'includefile' =&gt; null,<br /> 'internal' =&gt; true,<br /> 'priority' =&gt; 9999,<br /> ),<br /> <br /> );<br /> <br /> &lt;/code&gt;<br /> <br /> === Event dispatching ===<br /> <br /> A list of available observers is constructed on the fly directly from all available events.php files. Previously handlers were installed only during installation and upgrade. There is no risk of performance regression because the list is already cached in MUC. Observers get events before installation or any upgrade, however observers are not notified during the initial installation of moodle core tables.<br /> <br /> Developers of observers must make sure that execution does not end with a fatal error under any condition (before install, before upgrade or normal operation). Exceptions are automatically captured, logged in the PHP error log, and notification of other observers continues. Current handlers must not throw any exceptions at any time.<br /> <br /> Observers are notified sequentially in the same order in which events were triggered. This means that events triggered in observers are queued in FIFO buffer and are processed after all observers are notified.<br /> <br /> === Differences from old event handling ===<br /> <br /> # New events contain a lot more structured information.<br /> # New event data must not contain any PHP classes.<br /> # There is separate context cache which may be used when deleting data or for observer performance improvements.<br /> # No database access in new event dispatching code.<br /> # There is no support for cron execution - this eliminates performance problems, simplifies events dispatching and prevents abuse of cron events.<br /> # Events triggered in observers are processed in a different order.<br /> # External events are buffered when a transaction is in progress, instead of being sent to the cron queue.<br /> # It is possible to define multiple observers for one event in one events.php file.<br /> # It is possible to subscribe an observer to all events.<br /> # The new event manager is using frankenstyle autoloading - smaller memory footprint when events are not used on the current page.<br /> <br /> == Triggering events ==<br /> <br /> * All event descriptions are objects extending the \core\event\base class.<br /> * Events are triggered by creating a new instance of the class event and executing $event-&gt;trigger().<br /> * Each event class name is a unique identifier of the event.<br /> * Class names and namespace follow the identifier scheme \'''frankenstyle_component'''\event\'''some_object_action'''. Core events have prefix 'core_'.<br /> * Plugins define each event class in a separate file. File name and location must match the class name, for example: '''plugindir'''/classes/event/'''something_happened'''.php<br /> * The event identifier suffix has the form ''some_object_action'' ('''something_happened''' in the example above) and should follow our standard naming convention. The last word after underscore is automatically parsed as action, the rest of words is object.<br /> <br /> Decision:[[#Verb_list| Recommended verb list]]<br /> <br /> Examples: \core\event\course_completed, \mod_assign\event\submission_commented, \mod_forum\event\post_shared, \mod_forum\event\post_responded, etc.<br /> <br /> * Ideally, it should be possible to trigger an event without gathering additional information for the event. To reduce the cost of data gathering, specifically the cost of database reads, at least the minimal values needed to trigger an event should be already available in variables.<br /> <br /> An example of triggering an event:<br /> &lt;code php&gt;<br /> $event = \mod_myplugin\event\something_happened::create(array('context' =&gt; $context, 'objectid' =&gt; YYY, 'other' =&gt; ZZZ));<br /> // ... code that may add some record snapshots<br /> $event-&gt;trigger();<br /> &lt;/code&gt;<br /> <br /> <br /> === Use of php autoloading ===<br /> <br /> All new OOP APIs in Moodle 2.6 are going to use class auto loading - see [[Automatic class loading]]. New events use PHP strictly defined namespaces which concentrate all events classes in classes/event/ subdirectory.<br /> <br /> === Why separate classes? ===<br /> There were two alternatives proposed on how to define the event structure. The first is a separate class for each event (extending the base class), the other being each event is based on a generic event instance of the base class.<br /> &lt;pre&gt;<br /> Decision: Use separate class for each event.<br /> &lt;/pre&gt;<br /> '''Each plugin creates its own event class for each event'''<br /> <br /> Pros<br /> * Maintainability - It is much easier to review, debug, integrate.<br /> * Self documenting, behaviour is combined with definition.<br /> * It is extremely flexible for plugin developers and core devs too.<br /> * Automatically lists events without being installed - PHPDocs as events documentation.<br /> * It is included only when needed using autoloading.<br /> * Self-validating data structure (by PHP).<br /> * Some developers will find it easier to copy whole class files as templates.<br /> Cons<br /> * Big learning curve for developers without OOP skills (all other new subsystems in Moodle already use OOP, you can not code without these skills any more).<br /> * Some developers may find it harder to copy-and-paste examples because they will need to create new class first and use it afterwards (this can be viewed as a benefit because it forces developers to think more about events).<br /> <br /> <br /> '''Each plugin defines events in a list based on a generic object'''<br /> <br /> Pros<br /> * Easier for some developers (this can be eliminated with developer documentation).<br /> * Some developers think it gives more control of event structure in core (we can easily solve that with private access and validation in the base class).<br /> Cons<br /> * It is not flexible enough. PHP code gives developers more freedom.<br /> * It would not be possible to implement any performance hacks in custom methods. All data would have to be calculated even if it is not used.<br /> * It would be necessary to define access control callbacks in other code.<br /> * It would be harder and slower to integrate legacy logging.<br /> * It would be harder and slower to implement support for legacy events.<br /> * Event observers could not use event class names as reliable identifiers.<br /> * Event object and action could not be parsed from class name, it would have to be stored in event properties every time you trigger event.<br /> * Requires upgrade/install to register an event in DB table with MUC cache. Events could not be triggered earlier.<br /> * The localised descriptions and names would have to be stored as properties, it would not be possible to store them in any definition.<br /> * The implementation of an events infrastructure would be significantly more complex and error prone.<br /> <br /> == Information contained in events ==<br /> <br /> Events have to contain as much information as they can, but this should not affect the performance. That's why part of the information is available in properties, and the rest via methods. This allows for delaying the computation of the data at the time it is really needed, if it ever is.<br /> <br /> === Properties ===<br /> <br /> List of properties that the developer has to pass to the event upon creation, or automatically generated when possible and cost free. Some of those properties not mandatory.<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Property name<br /> ! Title<br /> ! Type<br /> ! Comment<br /> |-<br /> | ''eventname''<br /> | Event name<br /> | ''static, automatic from class name''<br /> | Automatically computed by copying class name<br /> |-<br /> | ''component''<br /> | Component<br /> | ''static, automatic from top namespace''<br /> | Component declaring the event, automatically computed from class name.<br /> |-<br /> | ''action''<br /> | Action<br /> | ''static, automatic from last word in class name''<br /> | Can be automatically computed from class name.<br /> |-<br /> | ''target''<br /> | target of action<br /> | ''static, automatic from class name''<br /> | Target on which the action is taken, can be automatically computed from class name.<br /> |-<br /> | objecttable<br /> | Database table name<br /> |<br /> | optional database table name where is/was the object stored. Never use a relationship table here.<br /> |-<br /> | objectid<br /> | Object ID<br /> |<br /> | optional id of the object record from objecttable<br /> |-<br /> | '''''crud'''''<br /> | Transaction type<br /> | ''static mandatory''<br /> | One of [crud] letters. Statically declared in the event class method init().<br /> |-<br /> | '''''level''''' / '''''edulevel'''''<br /> | Level<br /> | ''static mandatory''<br /> | Level of educational value of the event. Statically declared in the event class method init(). Changed from '''''level''''' to '''''edulevel''''' in Moodle 2.7 (See below for more details)<br /> |-<br /> | contextid<br /> | Context ID<br /> | mandatory<br /> | <br /> |-<br /> | contextlevel<br /> | Context level<br /> | automatic from context<br /> | This tells you if it was a course, activity, course category, etc.<br /> |-<br /> | contextinstanceid<br /> | Context instanceid<br /> | automatic from context<br /> | Based on context level this may be course id , course module id, course category, etc.<br /> |-<br /> | userid<br /> | User ID<br /> | defaults to current user<br /> | User ID, or 0 when not logged in, or -1 when other (System, CLI, Cron, ...)<br /> |-<br /> | courseid<br /> | Affected course<br /> | defaults to course context from context<br /> | This is used only for contexts at and bellow course level - this can be used to filter events by course (includes all course activities)<br /> |-<br /> | relateduserid<br /> | Affected user<br /> |<br /> | Is this action related to some user? This could be used for some personal timeline view.<br /> |-<br /> | other<br /> | All other data<br /> |<br /> | Any other fields needed for event description - scalars or arrays, must be serialisable using json_encode()<br /> |-<br /> | timecreated<br /> | Time of the event<br /> | automatic<br /> |<br /> |}<br /> <br /> * ''static'': It is the same for all event instances of this class.<br /> * '''mandatory''': Is required in order to trigger the event.<br /> <br /> ==== Level property ====<br /> <br /> The edulevel property helps defining the educational value of the event. It is intentional that the list is limited to only 3 different constants, having too many options would make it harder for developers to pick the right one(s). We also have to keep in mind that this is not supposed to answer all the questions about a particular event, other event properties like the courseid, the context, the component name can be used with the level to get more granular reports.<br /> <br /> Remember that this is event based. If the user that has triggered the event is not really &quot;participating&quot; because he is an admin, or a manager, then it is the job of the report to filter those. The event itself has a static educational level.<br /> <br /> '''Teaching''' (LEVEL_TEACHING: 1)<br /> <br /> Any event/action that is performed by someone (typically a teacher) and has a teaching value (anything that is affecting the learning experience/environment of the students). This should not be combined with &quot;Participating&quot; events.<br /> <br /> Valid events:<br /> <br /> * A teacher grading a student<br /> * A teacher modifying the course settings<br /> * A teacher adding a new section to the course page<br /> * A teacher modifying a module settings<br /> * A teacher adding a page to course<br /> * A teacher leaving a feedback<br /> <br /> INVALID events:<br /> <br /> * A teacher posting in a forum (it might affect the learning experience, but not necessarily, so the teacher is just participating)<br /> <br /> '''Participating''' (LEVEL_PARTICIPATING: 2)<br /> <br /> Any event/action that is performed by a user, that is related (or could be related) to his learning experience.<br /> <br /> Valid events:<br /> <br /> * A user posting to a forum<br /> * A user submitting an assignment<br /> * A user blogging<br /> * A user reading someone's blog<br /> * A user posting a comment<br /> * A user chatting on a chat activity<br /> * A user viewing the course page<br /> * A user deletes a blog post<br /> <br /> INVALID events:<br /> <br /> * A user updating his profile<br /> * A user visiting someone's profile<br /> * A user viewing his /my/ page<br /> * A user sending a message to another one<br /> <br /> '''Other''' (LEVEL_OTHER: 0)<br /> <br /> Any other action, whether they are related to the site administration, or are specific to user. They do not have any educational value.<br /> <br /> === Methods ===<br /> <br /> The computation of this data is not required by default, but can be accessed by any event observer if need be.<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Method<br /> ! Comment<br /> |-<br /> | get_name()<br /> | Returns localised name of the event, it is the same for all instances.<br /> |-<br /> | get_description()<br /> | Returns localised description of one particular event.<br /> |-<br /> | can_view($user)<br /> | Can the specified user view the event?<br /> |-<br /> | get_url()<br /> | Returns Moodle URL where the event can be observed afterwards.<br /> |-<br /> | get_legacy_eventname()<br /> | Information necessary for event BC.<br /> |-<br /> | get_legacy_eventdata()<br /> | Information necessary for event BC.<br /> |-<br /> | get_legacy_logdata()<br /> | Information necessary for logging BC.<br /> |}<br /> <br /> ===Record caching===<br /> <br /> The standard event data may not contain all the information observers need. The built-in record snapshot support in events allows developers to attach more auxiliary information when triggering events, it may be for example course record, some record that was just deleted, etc. The snapshot is meant to be a full database record, as it will be automatically fetched from get_record_snapshot() if not set previously and assuming the property ''objecttable'' is set. Please be aware that the snapshots are not stored in the event, and cannot be restored.<br /> <br /> &lt;code php&gt;<br /> $event = \core\event\role_assigned::create(<br /> array('context'=&gt;$context, 'objectid'=&gt;$ra-&gt;roleid, 'relateduserid'=&gt;$ra-&gt;userid,<br /> 'other'=&gt;array('id'=&gt;$ra-&gt;id, 'component'=&gt;$ra-&gt;component, 'itemid'=&gt;$ra-&gt;itemid)));<br /> $event-&gt;add_record_snapshot('role_assignments', $ra);<br /> $event-&gt;trigger();<br /> &lt;/code&gt;<br /> <br /> &lt;code php&gt;<br /> $event = \core\event\role_unassigned::create(<br /> array('context'=&gt;$context, 'objectid'=&gt;$ra-&gt;roleid, 'relateduserid'=&gt;$ra-&gt;userid,<br /> 'other'=&gt;array('id'=&gt;$ra-&gt;id, 'component'=&gt;$ra-&gt;component, 'itemid'=&gt;$ra-&gt;itemid)));<br /> $event-&gt;add_record_snapshot('role_assignments', $ra);<br /> $event-&gt;trigger();<br /> &lt;/code&gt;<br /> <br /> The related methods are:<br /> * public function add_record_snapshot($tablename, $record)<br /> * public function get_record_snapshot($tablename, $id)<br /> <br /> === Rejected properties and methods ===<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Property<br /> ! Title<br /> ! Why<br /> |-<br /> | URL<br /> | relevant page URL<br /> | These URLs can be constructed on the fly from other data, external log plugins may use get_url() method.<br /> |-<br /> | version<br /> | Event specification number<br /> | The event specification should never change<br /> |-<br /> | type<br /> | Type of event (action, error, ...)<br /> | Event are not intended for error logging or debugging.<br /> |-<br /> | actor<br /> | Whether current execution is cron, cli, user, ...<br /> | Impossible to track down at a low level<br /> |-<br /> | severity<br /> | Severity following [http://tools.ietf.org/html/rfc5424#section-6.2.1 logging standards]<br /> | Our logging does not match this, as we will not (at present) log errors<br /> |-<br /> | coursecatname<br /> | Category name<br /> | Might be costly to retrieve for little gain<br /> |-<br /> | coursename<br /> | Course name<br /> | Might be costly to retrieve for little gain<br /> |-<br /> | cmname<br /> | Course module name<br /> | Might be costly to retrieve for little gain<br /> |-<br /> | categoryid <br /> | Course category id<br /> | Categories are a tree structure, we can not identify them by one integer. It would have to be a path.<br /> |-<br /> | cmid <br /> | Course module id<br /> | Can be derived from contextlevel and contextinstanceid<br /> |-<br /> | associatedobject<br /> | Associated object<br /> | Object associated to the main object. Ie: The user to whom a message is sent.<br /> |-<br /> | associatedobjectid<br /> | Associated object ID<br /> | Identifier of the associated object<br /> |-<br /> | realuserid<br /> | Real User ID<br /> | Will be tracked by log plugins only - user who &quot;logged in as&quot;, stores the real user ID<br /> |-<br /> | origin<br /> | Origin of the event<br /> | Will be tracked by log plugins only - CLI, cron, Webservice, ... (optionally with IP address)<br /> |}<br /> <br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Method<br /> ! Comment<br /> ! Why<br /> |-<br /> | get_all_affected_users()<br /> | Returns all the users affected by this event<br /> | It is expensive to fetch all users and it changes in time, so it would be unreliable too. For now we store only one user who is related to each event.<br /> |-<br /> | get_objecturl()<br /> | Returns the URL to view the object<br /> | There is usually only one URL where event changes may be observed. The URL may depend on current user capabilities too.<br /> |-<br /> | get_associatedobjecturl()<br /> | Returns the URL to view the associated object<br /> | No associated user property is present.<br /> |-<br /> | get_currenturl()<br /> | Returns the current URL, uses $PAGE.<br /> | This information may be added by logger, current page info is not part of events data.<br /> |-<br /> | get_useripaddress()<br /> | Returns the User IP address<br /> | Page access method is not part of events API, this should be implemented as logdata properties in loggers.<br /> |}<br /> <br /> == Events naming convention ==<br /> <br /> Clear event names help developers when reading what events are triggered, and defining the events properties when defining the event class.<br /> <br /> Decision: \&lt;component&gt;\event\&lt;some_object&gt;_&lt;verb&gt;<br /> <br /> === Existing events ===<br /> <br /> List of existing events in Moodle code base, along with their 2.5 couterparts.<br /> <br /> This list is out of date. For a full list of events check out the [https://docs.moodle.org/en/Event_list_report Event list report] which is located in &quot;Site administration &gt; Reports &gt; Event list&quot; of your Moodle installation (2.7+).<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Fully qualified event name<br /> ! 2.5 name<br /> ! Component<br /> ! Object<br /> ! Action (Verb)<br /> ! Comment<br /> |-<br /> | '''assignsubmission_comments\event\comment_created'''<br /> | -<br /> | assignsubmission_comments<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''assignsubmission_comments\event\comment_deleted'''<br /> | -<br /> | assignsubmission_comments<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''assignsubmission_file\event\assessable_uploaded'''<br /> | assessable_file_uploaded<br /> | assignsubmission_file<br /> | assessable<br /> | uploaded<br /> | To be deprecated MDL-35197<br /> |- <br /> | '''assignsubmission_file\event\submission_created'''<br /> | -<br /> | assignsubmission_file<br /> | submission<br /> | created<br /> | <br /> |- <br /> | '''assignsubmission_file\event\submission_updated'''<br /> | -<br /> | assignsubmission_file<br /> | submission<br /> | updated<br /> | <br /> |- <br /> | '''assignsubmission_onlinetext\event\assessable_uploaded'''<br /> | assessable_content_uploaded<br /> | assignsubmission_onlinetext<br /> | assessable<br /> | uploaded<br /> | <br /> |- <br /> | '''assignsubmission_onlinetext\event\submission_created'''<br /> | -<br /> | assignsubmission_onlinetext<br /> | submission<br /> | created<br /> | <br /> |- <br /> | '''assignsubmission_onlinetext\event\submission_updated'''<br /> | -<br /> | assignsubmission_onlinetext<br /> | submission<br /> | updated<br /> | <br /> |- <br /> | '''block_comments\event\comment_created'''<br /> | -<br /> | block_comments<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''block_comments\event\comment_deleted'''<br /> | -<br /> | block_comments<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''booktool_exportimscp\event\book_exported'''<br /> | -<br /> | booktool_exportimscp<br /> | book<br /> | exported<br /> | <br /> |- <br /> | '''booktool_print\event\book_printed'''<br /> | -<br /> | booktool_print<br /> | book<br /> | printed<br /> | <br /> |- <br /> | '''booktool_print\event\chapter_printed'''<br /> | -<br /> | booktool_print<br /> | chapter<br /> | printed<br /> | <br /> |- <br /> | '''core\event\assessable_submitted'''<br /> | -<br /> | core<br /> | assessable<br /> | submitted<br /> | Abstract class <br /> |- <br /> | '''core\event\assessable_uploaded'''<br /> | -<br /> | core<br /> | assessable<br /> | uploaded<br /> | Abstract class <br /> |- <br /> | '''core\event\base'''<br /> | -<br /> | core<br /> | base<br /> | -<br /> | Abstract class <br /> |- <br /> | '''core\event\blog_association_created'''<br /> | -<br /> | core<br /> | blog_association<br /> | created<br /> | <br /> |- <br /> | '''core\event\blog_comment_created'''<br /> | -<br /> | core<br /> | blog_comment<br /> | created<br /> | <br /> |- <br /> | '''core\event\blog_comment_deleted'''<br /> | -<br /> | core<br /> | blog_comment<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\blog_entries_viewed'''<br /> | -<br /> | core<br /> | blog_entries<br /> | viewed<br /> | <br /> |- <br /> | '''core\event\blog_entry_created'''<br /> | blog_entry_added<br /> | core<br /> | blog_entry<br /> | created<br /> | <br /> |- <br /> | '''core\event\blog_entry_deleted'''<br /> | blog_entry_deleted<br /> | core<br /> | blog_entry<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\blog_entry_updated'''<br /> | blog_entry_edited<br /> | core<br /> | blog_entry<br /> | updated<br /> | <br /> |- <br /> | '''core\event\cohort_created'''<br /> | cohort_added<br /> | core<br /> | cohort<br /> | created<br /> | <br /> |- <br /> | '''core\event\cohort_deleted'''<br /> | cohort_deleted<br /> | core<br /> | cohort<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\cohort_member_added'''<br /> | cohort_member_added<br /> | core<br /> | cohort_member<br /> | added<br /> | <br /> |- <br /> | '''core\event\cohort_member_removed'''<br /> | cohort_member_removed<br /> | core<br /> | cohort_member<br /> | removed<br /> | <br /> |- <br /> | '''core\event\cohort_updated'''<br /> | cohort_updated<br /> | core<br /> | cohort<br /> | updated<br /> | <br /> |- <br /> | '''core\event\comment_created'''<br /> | -<br /> | core<br /> | comment<br /> | created<br /> | Abstract class <br /> |- <br /> | '''core\event\comment_deleted'''<br /> | -<br /> | core<br /> | comment<br /> | deleted<br /> | Abstract class <br /> |- <br /> | '''core\event\comments_viewed'''<br /> | -<br /> | core<br /> | comments<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\content_viewed'''<br /> | -<br /> | core<br /> | content<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\course_category_created'''<br /> | -<br /> | core<br /> | course_category<br /> | created<br /> | <br /> |- <br /> | '''core\event\course_category_deleted'''<br /> | course_category_deleted<br /> | core<br /> | course_category<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\course_category_updated'''<br /> | -<br /> | core<br /> | course_category<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_completed'''<br /> | course_completed<br /> | core<br /> | course<br /> | completed<br /> | <br /> |- <br /> | '''core\event\course_completion_updated'''<br /> | -<br /> | core<br /> | course_completion<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_content_deleted'''<br /> | course_content_removed<br /> | core<br /> | course_content<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\course_created'''<br /> | course_created<br /> | core<br /> | course<br /> | created<br /> | <br /> |- <br /> | '''core\event\course_deleted'''<br /> | course_deleted<br /> | core<br /> | course<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\course_module_completion_updated'''<br /> | activity_completion_changed<br /> | core<br /> | course_module_completion<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_module_created'''<br /> | mod_created<br /> | core<br /> | course_module<br /> | created<br /> | <br /> |- <br /> | '''core\event\course_module_deleted'''<br /> | mod_deleted<br /> | core<br /> | course_module<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\course_module_instance_list_viewed'''<br /> | -<br /> | core<br /> | course_module_instance_list<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\course_module_instances_list_viewed'''<br /> | -<br /> | core<br /> | course_module_instances_list<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\course_module_updated'''<br /> | mod_updated<br /> | core<br /> | course_module<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_module_viewed'''<br /> | -<br /> | core<br /> | course_module<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\course_reset_ended'''<br /> | -<br /> | core<br /> | course_reset<br /> | ended<br /> | <br /> |- <br /> | '''core\event\course_reset_started'''<br /> | -<br /> | core<br /> | course_reset<br /> | started<br /> | <br /> |- <br /> | '''core\event\course_restored'''<br /> | course_restored<br /> | core<br /> | course<br /> | restored<br /> | <br /> |- <br /> | '''core\event\course_section_updated'''<br /> | -<br /> | core<br /> | course_section<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_updated'''<br /> | course_updated<br /> | core<br /> | course<br /> | updated<br /> | <br /> |- <br /> | '''core\event\email_failed'''<br /> | -<br /> | core<br /> | email<br /> | failed<br /> | <br /> |- <br /> | '''core\event\group_created'''<br /> | groups_group_created<br /> | core<br /> | group<br /> | created<br /> | <br /> |- <br /> | '''core\event\group_deleted'''<br /> | groups_group_deleted<br /> | core<br /> | group<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\group_member_added'''<br /> | groups_member_added<br /> | core<br /> | group_member<br /> | added<br /> | <br /> |- <br /> | '''core\event\group_member_removed'''<br /> | groups_member_removed<br /> | core<br /> | group_member<br /> | removed<br /> | <br /> |- <br /> | '''core\event\group_updated'''<br /> | groups_group_updated<br /> | core<br /> | group<br /> | updated<br /> | <br /> |- <br /> | '''core\event\grouping_created'''<br /> | groups_grouping_created<br /> | core<br /> | grouping<br /> | created<br /> | <br /> |- <br /> | '''core\event\grouping_deleted'''<br /> | groups_grouping_deleted<br /> | core<br /> | grouping<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\grouping_updated'''<br /> | groups_grouping_updated<br /> | core<br /> | grouping<br /> | updated<br /> | <br /> |- <br /> | '''core\event\manager'''<br /> | -<br /> | core<br /> | manager<br /> | anager<br /> | <br /> |- <br /> | '''core\event\mnet_access_control_created'''<br /> | -<br /> | core<br /> | mnet_access_control<br /> | created<br /> | <br /> |- <br /> | '''core\event\mnet_access_control_updated'''<br /> | -<br /> | core<br /> | mnet_access_control<br /> | updated<br /> | <br /> |- <br /> | '''core\event\note_created'''<br /> | -<br /> | core<br /> | note<br /> | created<br /> | <br /> |- <br /> | '''core\event\note_deleted'''<br /> | -<br /> | core<br /> | note<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\note_updated'''<br /> | -<br /> | core<br /> | note<br /> | updated<br /> | <br /> |- <br /> | '''core\event\notes_viewed'''<br /> | -<br /> | core<br /> | notes<br /> | viewed<br /> | <br /> |- <br /> | '''core\event\role_allow_assign_updated'''<br /> | -<br /> | core<br /> | role_allow_assign<br /> | updated<br /> | <br /> |- <br /> | '''core\event\role_allow_override_updated'''<br /> | -<br /> | core<br /> | role_allow_override<br /> | updated<br /> | <br /> |- <br /> | '''core\event\role_allow_switch_updated'''<br /> | -<br /> | core<br /> | role_allow_switch<br /> | updated<br /> | <br /> |- <br /> | '''core\event\role_assigned'''<br /> | role_assigned<br /> | core<br /> | role<br /> | assigned<br /> | <br /> |- <br /> | '''core\event\role_capabilities_updated'''<br /> | -<br /> | core<br /> | role_capabilities<br /> | updated<br /> | <br /> |- <br /> | '''core\event\role_deleted'''<br /> | -<br /> | core<br /> | role<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\role_unassigned'''<br /> | role_unassigned<br /> | core<br /> | role<br /> | unassigned<br /> | <br /> |- <br /> | '''core\event\user_created'''<br /> | user_created<br /> | core<br /> | user<br /> | created<br /> | <br /> |- <br /> | '''core\event\user_deleted'''<br /> | user_deleted<br /> | core<br /> | user<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\user_enrolment_created'''<br /> | user_enrolled<br /> | core<br /> | user_enrolment<br /> | created<br /> | <br /> |- <br /> | '''core\event\user_enrolment_deleted'''<br /> | user_unenrolled<br /> | core<br /> | user_enrolment<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\user_enrolment_updated'''<br /> | user_enrol_modified<br /> | core<br /> | user_enrolment<br /> | updated<br /> | <br /> |- <br /> | '''core\event\user_list_viewed'''<br /> | -<br /> | core<br /> | user_list<br /> | viewed<br /> | <br /> |- <br /> | '''core\event\user_loggedin'''<br /> | -<br /> | core<br /> | user<br /> | loggedin<br /> | <br /> |- <br /> | '''core\event\user_loggedinas'''<br /> | -<br /> | core<br /> | user<br /> | loggedinas<br /> | <br /> |- <br /> | '''core\event\user_loggedout'''<br /> | user_logout<br /> | core<br /> | user<br /> | loggedout<br /> | <br /> |- <br /> | '''core\event\user_login_failed'''<br /> | -<br /> | core<br /> | user_login<br /> | failed<br /> | <br /> |- <br /> | '''core\event\user_profile_viewed'''<br /> | -<br /> | core<br /> | user_profile<br /> | viewed<br /> | <br /> |- <br /> | '''core\event\user_updated'''<br /> | user_updated<br /> | core<br /> | user<br /> | updated<br /> | <br /> |- <br /> | '''core\event\webservice_function_called'''<br /> | -<br /> | core<br /> | webservice_function<br /> | called<br /> | <br /> |- <br /> | '''core\event\webservice_login_failed'''<br /> | -<br /> | core<br /> | webservice_login<br /> | failed<br /> | <br /> |- <br /> | '''core\event\webservice_service_created'''<br /> | -<br /> | core<br /> | webservice_service<br /> | created<br /> | <br /> |- <br /> | '''core\event\webservice_service_deleted'''<br /> | -<br /> | core<br /> | webservice_service<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\webservice_service_updated'''<br /> | -<br /> | core<br /> | webservice_service<br /> | updated<br /> | <br /> |- <br /> | '''core\event\webservice_service_user_added'''<br /> | -<br /> | core<br /> | webservice_service_user<br /> | added<br /> | <br /> |- <br /> | '''core\event\webservice_service_user_removed'''<br /> | -<br /> | core<br /> | webservice_service_user<br /> | removed<br /> | <br /> |- <br /> | '''core\event\webservice_token_created'''<br /> | -<br /> | core<br /> | webservice_token<br /> | created<br /> | <br /> |- <br /> | '''core\event\webservice_token_sent'''<br /> | -<br /> | core<br /> | webservice_token<br /> | sent<br /> | <br /> |- <br /> | '''logstore_legacy\event\legacy_logged'''<br /> | -<br /> | logstore_legacy<br /> | legacy<br /> | logged<br /> | <br /> |- <br /> | '''mod_assign\event\all_submissions_downloaded'''<br /> | -<br /> | mod_assign<br /> | all_submissions<br /> | downloaded<br /> | <br /> |- <br /> | '''mod_assign\event\assessable_submitted'''<br /> | assessable_submitted<br /> | mod_assign<br /> | assessable<br /> | submitted<br /> | <br /> |- <br /> | '''mod_assign\event\extension_granted'''<br /> | -<br /> | mod_assign<br /> | extension<br /> | granted<br /> | <br /> |- <br /> | '''mod_assign\event\identities_revealed'''<br /> | -<br /> | mod_assign<br /> | identities<br /> | revealed<br /> | <br /> |- <br /> | '''mod_assign\event\marker_updated'''<br /> | -<br /> | mod_assign<br /> | marker<br /> | updated<br /> | <br /> |- <br /> | '''mod_assign\event\statement_accepted'''<br /> | -<br /> | mod_assign<br /> | statement<br /> | accepted<br /> | <br /> |- <br /> | '''mod_assign\event\submission_created'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | created<br /> | Abstract class <br /> |- <br /> | '''mod_assign\event\submission_duplicated'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | duplicated<br /> | <br /> |- <br /> | '''mod_assign\event\submission_graded'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | graded<br /> | <br /> |- <br /> | '''mod_assign\event\submission_locked'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | locked<br /> | <br /> |- <br /> | '''mod_assign\event\submission_status_updated'''<br /> | -<br /> | mod_assign<br /> | submission_status<br /> | updated<br /> | <br /> |- <br /> | '''mod_assign\event\submission_unlocked'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | unlocked<br /> | <br /> |- <br /> | '''mod_assign\event\submission_updated'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | updated<br /> | Abstract class <br /> |- <br /> | '''mod_assign\event\workflow_state_updated'''<br /> | -<br /> | mod_assign<br /> | workflow_state<br /> | updated<br /> | <br /> |- <br /> | '''mod_book\event\chapter_created'''<br /> | -<br /> | mod_book<br /> | chapter<br /> | created<br /> | <br /> |- <br /> | '''mod_book\event\chapter_deleted'''<br /> | -<br /> | mod_book<br /> | chapter<br /> | deleted<br /> | <br /> |- <br /> | '''mod_book\event\chapter_updated'''<br /> | -<br /> | mod_book<br /> | chapter<br /> | updated<br /> | <br /> |- <br /> | '''mod_book\event\chapter_viewed'''<br /> | -<br /> | mod_book<br /> | chapter<br /> | viewed<br /> | <br /> |- <br /> | '''mod_book\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_book<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_book\event\course_module_viewed'''<br /> | -<br /> | mod_book<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_chat\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_chat<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_chat\event\message_sent'''<br /> | -<br /> | mod_chat<br /> | message<br /> | sent<br /> | <br /> |- <br /> | '''mod_chat\event\sessions_viewed'''<br /> | -<br /> | mod_chat<br /> | sessions<br /> | viewed<br /> | <br /> |- <br /> | '''mod_choice\event\answer_submitted'''<br /> | -<br /> | mod_choice<br /> | answer<br /> | submitted<br /> | <br /> |- <br /> | '''mod_choice\event\answer_updated'''<br /> | -<br /> | mod_choice<br /> | answer<br /> | updated<br /> | <br /> |- <br /> | '''mod_choice\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_choice<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_choice\event\course_module_viewed'''<br /> | -<br /> | mod_choice<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_choice\event\report_viewed'''<br /> | -<br /> | mod_choice<br /> | report<br /> | viewed<br /> | <br /> |- <br /> | '''mod_data\event\comment_created'''<br /> | -<br /> | mod_data<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''mod_data\event\comment_deleted'''<br /> | -<br /> | mod_data<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''mod_data\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_data<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_data\event\course_module_viewed'''<br /> | -<br /> | mod_data<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_data\event\field_created'''<br /> | -<br /> | mod_data<br /> | field<br /> | created<br /> | <br /> |- <br /> | '''mod_data\event\field_deleted'''<br /> | -<br /> | mod_data<br /> | field<br /> | deleted<br /> | <br /> |- <br /> | '''mod_data\event\field_updated'''<br /> | -<br /> | mod_data<br /> | field<br /> | updated<br /> | <br /> |- <br /> | '''mod_data\event\record_created'''<br /> | -<br /> | mod_data<br /> | record<br /> | created<br /> | <br /> |- <br /> | '''mod_data\event\record_deleted'''<br /> | -<br /> | mod_data<br /> | record<br /> | deleted<br /> | <br /> |- <br /> | '''mod_data\event\record_updated'''<br /> | -<br /> | mod_data<br /> | record<br /> | updated<br /> | <br /> |- <br /> | '''mod_data\event\template_updated'''<br /> | -<br /> | mod_data<br /> | template<br /> | updated<br /> | <br /> |- <br /> | '''mod_data\event\template_viewed'''<br /> | -<br /> | mod_data<br /> | template<br /> | viewed<br /> | <br /> |- <br /> | '''mod_feedback\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_feedback<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_feedback\event\course_module_viewed'''<br /> | -<br /> | mod_feedback<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_feedback\event\response_deleted'''<br /> | -<br /> | mod_feedback<br /> | response<br /> | deleted<br /> | <br /> |- <br /> | '''mod_feedback\event\response_submitted'''<br /> | -<br /> | mod_feedback<br /> | response<br /> | submitted<br /> | <br /> |- <br /> | '''mod_folder\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_folder<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_folder\event\course_module_viewed'''<br /> | -<br /> | mod_folder<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_folder\event\folder_updated'''<br /> | -<br /> | mod_folder<br /> | folder<br /> | updated<br /> | <br /> |- <br /> | '''mod_forum\event\assessable_uploaded'''<br /> | assessable_content_uploaded<br /> | mod_forum<br /> | assessable<br /> | uploaded<br /> | <br /> |- <br /> | '''mod_forum\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_forum<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_forum\event\course_searched'''<br /> | -<br /> | mod_forum<br /> | course<br /> | searched<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_created'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | created<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_deleted'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | deleted<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_moved'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | moved<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_updated'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | updated<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_viewed'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | viewed<br /> | <br /> |- <br /> | '''mod_forum\event\forum_viewed'''<br /> | -<br /> | mod_forum<br /> | forum<br /> | viewed<br /> | <br /> |- <br /> | '''mod_forum\event\post_created'''<br /> | -<br /> | mod_forum<br /> | post<br /> | created<br /> | <br /> |- <br /> | '''mod_forum\event\post_deleted'''<br /> | -<br /> | mod_forum<br /> | post<br /> | deleted<br /> | <br /> |- <br /> | '''mod_forum\event\post_updated'''<br /> | -<br /> | mod_forum<br /> | post<br /> | updated<br /> | <br /> |- <br /> | '''mod_forum\event\readtracking_disabled'''<br /> | -<br /> | mod_forum<br /> | readtracking<br /> | disabled<br /> | <br /> |- <br /> | '''mod_forum\event\readtracking_enabled'''<br /> | -<br /> | mod_forum<br /> | readtracking<br /> | enabled<br /> | <br /> |- <br /> | '''mod_forum\event\subscribers_viewed'''<br /> | -<br /> | mod_forum<br /> | subscribers<br /> | viewed<br /> | <br /> |- <br /> | '''mod_forum\event\subscription_created'''<br /> | -<br /> | mod_forum<br /> | subscription<br /> | created<br /> | <br /> |- <br /> | '''mod_forum\event\subscription_deleted'''<br /> | -<br /> | mod_forum<br /> | subscription<br /> | deleted<br /> | <br /> |- <br /> | '''mod_forum\event\userreport_viewed'''<br /> | -<br /> | mod_forum<br /> | userreport<br /> | viewed<br /> | <br /> |- <br /> | '''mod_glossary\event\comment_created'''<br /> | -<br /> | mod_glossary<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''mod_glossary\event\comment_deleted'''<br /> | -<br /> | mod_glossary<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''mod_lesson\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_lesson<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lesson\event\course_module_viewed'''<br /> | -<br /> | mod_lesson<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lesson\event\essay_assessed'''<br /> | -<br /> | mod_lesson<br /> | essay<br /> | assessed<br /> | <br /> |- <br /> | '''mod_lesson\event\essay_attempt_viewed'''<br /> | -<br /> | mod_lesson<br /> | essay_attempt<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lesson\event\highscore_added'''<br /> | -<br /> | mod_lesson<br /> | highscore<br /> | added<br /> | <br /> |- <br /> | '''mod_lesson\event\highscores_viewed'''<br /> | -<br /> | mod_lesson<br /> | highscores<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lesson\event\lesson_ended'''<br /> | -<br /> | mod_lesson<br /> | lesson<br /> | ended<br /> | <br /> |- <br /> | '''mod_lesson\event\lesson_started'''<br /> | -<br /> | mod_lesson<br /> | lesson<br /> | started<br /> | <br /> |- <br /> | '''mod_lti\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_lti<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lti\event\course_module_viewed'''<br /> | -<br /> | mod_lti<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lti\event\unknown_service_api_called'''<br /> | lti_unknown_service_api_call<br /> | mod_lti<br /> | unknown_service_api<br /> | called<br /> | <br /> |- <br /> | '''mod_page\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_page<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_page\event\course_module_viewed'''<br /> | -<br /> | mod_page<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_quiz\event\attempt_abandoned'''<br /> | quiz_attempt_abandoned<br /> | mod_quiz<br /> | attempt<br /> | abandoned<br /> | <br /> |- <br /> | '''mod_quiz\event\attempt_becameoverdue'''<br /> | quiz_attempt_overdue<br /> | mod_quiz<br /> | attempt<br /> | becameoverdue<br /> | <br /> |- <br /> | '''mod_quiz\event\attempt_started'''<br /> | quiz_attempt_started<br /> | mod_quiz<br /> | attempt<br /> | started<br /> | <br /> |- <br /> | '''mod_quiz\event\attempt_submitted'''<br /> | quiz_attempt_submitted<br /> | mod_quiz<br /> | attempt<br /> | submitted<br /> | <br /> |- <br /> | '''mod_resource\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_resource<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_resource\event\course_module_viewed'''<br /> | -<br /> | mod_resource<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\attempt_deleted'''<br /> | -<br /> | mod_scorm<br /> | attempt<br /> | deleted<br /> | <br /> |- <br /> | '''mod_scorm\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_scorm<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\course_module_viewed'''<br /> | -<br /> | mod_scorm<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\interactions_viewed'''<br /> | -<br /> | mod_scorm<br /> | interactions<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\report_viewed'''<br /> | -<br /> | mod_scorm<br /> | report<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\sco_launched'''<br /> | -<br /> | mod_scorm<br /> | sco<br /> | launched<br /> | <br /> |- <br /> | '''mod_scorm\event\tracks_viewed'''<br /> | -<br /> | mod_scorm<br /> | tracks<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\user_report_viewed'''<br /> | -<br /> | mod_scorm<br /> | user_report<br /> | viewed<br /> | <br /> |- <br /> | '''mod_url\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_url<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_url\event\course_module_viewed'''<br /> | -<br /> | mod_url<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\comment_created'''<br /> | -<br /> | mod_wiki<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''mod_wiki\event\comment_deleted'''<br /> | -<br /> | mod_wiki<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''mod_wiki\event\comments_viewed'''<br /> | -<br /> | mod_wiki<br /> | comments<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_wiki<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\course_module_viewed'''<br /> | -<br /> | mod_wiki<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_created'''<br /> | -<br /> | mod_wiki<br /> | page<br /> | created<br /> | <br /> |- <br /> | '''mod_wiki\event\page_deleted'''<br /> | -<br /> | mod_wiki<br /> | page<br /> | deleted<br /> | <br /> |- <br /> | '''mod_wiki\event\page_diff_viewed'''<br /> | -<br /> | mod_wiki<br /> | page_diff<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_history_viewed'''<br /> | -<br /> | mod_wiki<br /> | page_history<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_locks_deleted'''<br /> | -<br /> | mod_wiki<br /> | page_locks<br /> | deleted<br /> | <br /> |- <br /> | '''mod_wiki\event\page_map_viewed'''<br /> | -<br /> | mod_wiki<br /> | page_map<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_updated'''<br /> | -<br /> | mod_wiki<br /> | page<br /> | updated<br /> | <br /> |- <br /> | '''mod_wiki\event\page_version_deleted'''<br /> | -<br /> | mod_wiki<br /> | page_version<br /> | deleted<br /> | <br /> |- <br /> | '''mod_wiki\event\page_version_restored'''<br /> | -<br /> | mod_wiki<br /> | page_version<br /> | restored<br /> | <br /> |- <br /> | '''mod_wiki\event\page_version_viewed'''<br /> | -<br /> | mod_wiki<br /> | page_version<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_viewed'''<br /> | -<br /> | mod_wiki<br /> | page<br /> | viewed<br /> | <br /> |- <br /> | '''mod_workshop\event\assessable_uploaded'''<br /> | assessable_content_uploaded<br /> | mod_workshop<br /> | assessable<br /> | uploaded<br /> | <br /> |- <br /> | '''mod_workshop\event\assessment_evaluated'''<br /> | -<br /> | mod_workshop<br /> | assessment<br /> | evaluated<br /> | <br /> |- <br /> | '''mod_workshop\event\assessment_evaluations_reset'''<br /> | -<br /> | mod_workshop<br /> | assessment_evaluations<br /> | reset<br /> | <br /> |- <br /> | '''mod_workshop\event\assessment_reevaluated'''<br /> | -<br /> | mod_workshop<br /> | assessment<br /> | reevaluated<br /> | <br /> |- <br /> | '''mod_workshop\event\course_module_viewed'''<br /> | workshop_viewed<br /> | mod_workshop<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_workshop\event\instances_list_viewed'''<br /> | -<br /> | mod_workshop<br /> | instances_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_workshop\event\phase_switched'''<br /> | -<br /> | mod_workshop<br /> | phase<br /> | switched<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_assessed'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | assessed<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_created'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | created<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_reassessed'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | reassessed<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_updated'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | updated<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_viewed'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | viewed<br /> | <br /> |- <br /> | '''report_log\event\content_viewed'''<br /> | -<br /> | report_log<br /> | content<br /> | viewed<br /> | <br /> |- <br /> | '''report_loglive\event\content_viewed'''<br /> | -<br /> | report_loglive<br /> | content<br /> | viewed<br /> | <br /> |- <br /> | '''report_outline\event\content_viewed'''<br /> | -<br /> | report_outline<br /> | content<br /> | viewed<br /> | <br /> |- <br /> | '''report_participation\event\content_viewed'''<br /> | -<br /> | report_participation<br /> | content<br /> | viewed<br /> | <br /> |- <br /> | '''report_stats\event\content_viewed'''<br /> | -<br /> | report_stats<br /> | content<br /> | viewed<br /> | <br /> |- <br /> |}<br /> <br /> === Verb list ===<br /> All events must use a verb from this list. New verbs should be added to this list if required.<br /> {| class=&quot;nicetable&quot;<br /> |-<br /> !verb<br /> !Explanation<br /> !Source<br /> |-<br /> |abandoned<br /> |When a attempt is abandoned by user (Quiz attempt)<br /> |Moodle<br /> |-<br /> |accepted<br /> |Example: Accepting a statement when submitting an assignment.<br /> |Moodle<br /> |-<br /> |added<br /> | Used to represent &quot;something that already exists is now part of/bound to another entity&quot;. Examples: &quot;Admin added role to user X&quot;, &quot;Admin added user X to group A&quot;. Wrong example: &quot;User added course in category&quot; because it is a 'move' action, except if a course can be part of multiple categories. The good examples work because: A user can have multiple roles, a user can be in multiple groups.<br /> |Moodle<br /> |-<br /> |answered<br /> | Indicates the actor responded to a Question<br /> |Tincan<br /> |-<br /> |assessed<br /> | Some submitted material has been assessed<br /> |Moodle<br /> |-<br /> |assigned<br /> | Assign some privilege or role to user.<br /> |Moodle<br /> |-<br /> |attempted<br /> | Trying to do an activity. Example: attempting a Math class.<br /> |Tincan<br /> |-<br /> |awarded<br /> | ex:-teacher awarded student a badge.<br /> |Moodle<br /> |-<br /> |backedup<br /> | When a backup has been performed.<br /> |Moodle <br /> |-<br /> |becomeoverdue<br /> | When an activity is overdue Example: Quiz attempt is overdue<br /> |Moodle <br /> |-<br /> |called<br /> | When a call to something is made like an API @see unknown_service_api_called.php<br /> |Moodle<br /> |-<br /> |commented<br /> |Offered an opinion or written experience of the activity. Can be used with the learner as the actor or a system as an actor. Comments can be sent from either party with the idea that the other will read and react to the content.<br /> |Tincan<br /> |-<br /> |completed<br /> |To experience the activity in its entirety. Used to affirm the completion of content. This can be simply experiencing all the content, be tied to objectives or interactions, or determined in any other way. Any content that has been initialized, but not yet completed, should be considered incomplete. There is no verb to 'incomplete' an activity, one would void the statement which completes the activity.&quot;<br /> |Tincan<br /> |-<br /> |created<br /> |Used to represent &quot;something new has been created&quot;.<br /> |Moodle<br /> |-<br /> |deleted<br /> |Used to indicate the object in context was deleted.<br /> |Moodle<br /> |-<br /> |disabled<br /> |When an activity is disabled. Example: forum read tracking disabled.<br /> |Moodle<br /> |-<br /> |downloaded<br /> |When a user download file from user. Example submission/report downloaded.<br /> |Moodle<br /> |-<br /> |duplicated<br /> |For something that has been copied.<br /> |Moodle<br /> |-<br /> |enabled<br /> |When some setting is enabled. Example: forum read tracking enabled.<br /> |Moodle<br /> |-<br /> |ended<br /> |When a process ends. Example: Lesson ended or course reset ended.<br /> |Moodle<br /> |-<br /> |evaluated<br /> |Material has been evaluated.<br /> |Moodle<br /> |-<br /> |exported<br /> |When a report is exported in certain format.<br /> |Moodle<br /> |-<br /> |failed<br /> |Learner did not perform the activity to a level of pre-determined satisfaction. Used to affirm the lack of success a learner experienced within the learning content in relation to a threshold. If the user performed below the minimum to the level of this threshold, the content is 'failed'. The opposite of 'passed'. This is also used in case when message sending is failed.<br /> |Tincan<br /> |-<br /> |graded<br /> |Used to represent an activity was graded.<br /> |Moodle<br /> |-<br /> |granted<br /> |User is granted some extension or capability. Example: extension granted for submission.<br /> |Moodle<br /> |-<br /> |imported<br /> |The act of moving an object into another location or system.<br /> |Tincan<br /> |-<br /> |launched<br /> |When an external object is launched. Try consider started if there is related stopped event.<br /> |Moodle<br /> |-<br /> |locked<br /> |When an activity is locked. Should have a related unlocked event.<br /> |Moodle<br /> |-<br /> |loggedin/loggedout<br /> | For login and logout.<br /> |Moodle<br /> |-<br /> |loggedinas<br /> | If user is logged in as different user. This is used by only one event (user_loggedinas). Adding this verb makes event name more clear, then using loggedin verb.<br /> |Moodle<br /> |-<br /> |locked<br /> |<br /> |Moodle<br /> |-<br /> |moved<br /> | Used to indicate the object in context was moved.<br /> |Moodle<br /> |-<br /> |passed<br /> |Used to affirm the success a learner experienced within the learning content in relation to a threshold. If the user performed at a minimum to the level of this threshold, the content is 'passed'. The opposite of 'failed'.<br /> |Tincan<br /> |-<br /> |printed<br /> |Something is printed.<br /> |Moodle<br /> |-<br /> |reassessed<br /> |Submitted material has been assessed again.<br /> |Moodle<br /> |-<br /> |reevaluated<br /> |Material has been evaluated again.<br /> |Moodle<br /> |-<br /> |removed<br /> |By opposition to &quot;Added&quot;. This does not mean that the object has been deleted, but removed from the entity, or not bound to it any more.<br /> |Moodle<br /> |-<br /> |reset<br /> |Sets one or more properties back to the default value.<br /> |Moodle<br /> |-<br /> |restored<br /> |When restoring a backup. Rolling back to a previous state.<br /> |Moodle<br /> |-<br /> |revealed<br /> |Some identity is revealed. Example: Identities revealed after blind marking.<br /> |Moodle<br /> |-<br /> |searched<br /> |Something is searched. Example: searched in course.<br /> |Moodle<br /> |-<br /> |sent<br /> |Message sent.<br /> |Moodle<br /> |-<br /> |started<br /> |Some activity started<br /> |Moodle<br /> |-<br /> |submitted<br /> |This is very close to &quot;Attempted&quot;. Depends on context which one should be used. For example:- &quot;Admin submitted a form. Student attempted a quiz.&quot; is correct, however some cases might not be as clear as the previous example. We can say both &quot;Student submitted an assignment&quot; or &quot;student attempted an assignment&quot;. We need to make the difference clear.<br /> |Moodle<br /> |-<br /> |suspended<br /> | Suspend something. (example a user)<br /> | Tincan (However the context is different)<br /> |-<br /> |switched<br /> |Something has been switched. For example:- The workshop phase has been switched to assessment&quot;<br /> |Moodle<br /> |-<br /> |unassigned<br /> |As opposed to assigned. When some role is unassigned.<br /> |Moodle<br /> |-<br /> |unlocked<br /> |<br /> |Moodle<br /> |-<br /> |upgraded<br /> |Something was upgraded, some module probably<br /> |Moodle<br /> |-<br /> |updated<br /> |Used to indicate the object in context was updated. Simple example is &quot;Admin updated course xyz&quot;.<br /> |Moodle<br /> |-<br /> |uploaded<br /> |When an assignment is uploaded.<br /> |Moodle<br /> |-<br /> |viewed<br /> |Something has been viewed. For example:- &quot;Student viewed chapter 1 of book 1.&quot;<br /> |Moodle<br /> |-<br /> |}<br /> <br /> === Rules ===<br /> <br /> ==== Use singular ====<br /> <br /> Plurals must be used on objects when it's a ''One to Many'' relationship. Ex: bulk import, mass deletion, ... In any other case, use the singular.<br /> <br /> ==== Ends with a verb ====<br /> <br /> The last word (after the last underscore) must be a verb.<br /> <br /> === Deprecated events ===<br /> Following are the events that were supported in 2.5, but deprecated in 2.6 or later<br /> <br /> groups_groupings_deleted (see MDL-41312)<br /> <br /> groups_groupings_groups_removed (see MDL-41312)<br /> <br /> groups_groups_deleted (see MDL-41312)<br /> <br /> groups_members_removed (see MDL-41312)<br /> <br /> == Shared events ==<br /> <br /> Decision: Not supported at this stage.<br /> <br /> In Moodle 2.5 we have a good example of a shared event: 'assessable_content_uploaded' which is triggered in ''forum'', 'assignment'' and ''workshop''.<br /> <br /> The problem with shared events is that we cannot easily track what component triggered them. Of course we could add a new property to the event to keep track of that, but we would soon need more information and more properties. Also, in the case of a logger, the event received would be unique, where in fact it should be considered different depending on the component firing it.<br /> <br /> In our first implementation, we will create one specific event per module. This flexibility does not prevent any observer from capturing them, but still makes sure that the consistency and specificity of each event is maintained.<br /> <br /> It could happen that some events are defined in core and shared, but this should not really happen as low-level APIs should trigger the event, and a module should call that low API instead of doing the job itself.<br /> <br /> == One to many ==<br /> <br /> Decision: Each event should have a one to one relationship. We can reconsider this at a later stage, if the performance hit is extremely high.<br /> <br /> In 2.5, some events are triggered when an action happens on multiple objects. We have to decide whether we want to keep supporting ''One to Many'' events or not.<br /> <br /> Keeping a list of all changes for multiple actions may be problematic because you would have to keep them all in memory until all things are processed. This might also result in the order of events being incorrect. The only correct solution seems to be to trigger each item individually and then many things at the end. Performance needs to be improved elsewhere...<br /> <br /> === Accuracy ===<br /> <br /> When uploading a bunch of users using the CSV upload feature, if only one event is triggered, it means that the observers of ''user_created'' won't be triggered. And so some functionality can be lost as, as a plugin developer, I expect this ''user_created'' to be triggered regardless of the way they have been uploaded. Of course, the developer could observe the event ''bulk_user_imported'', but that means that he could miss some relevant observers.<br /> <br /> This applies to existing events.<br /> <br /> === Performance ===<br /> <br /> Triggering one event is cheaper then repeating the same events x number of times...<br /> <br /> === Information tracking ===<br /> <br /> A ''bulk'' event, might not be verbose enough to allow for proper logging afterwards. Though this is the responsibility of the logger, we probably want to make it easy to store relevant information.<br /> <br /> === Double event ===<br /> <br /> In the case of a bulk user import, if we were to trigger an event per user created, we probably want to trigger one event 'user_bulk_upload_started' when the action starts.<br /> <br /> == Unit Testing ==<br /> <br /> With unit testing for this system we want to assert the following:<br /> <br /> * That event strict validation and custom validation works.<br /> * Missing event data is auto filled with accurate data.<br /> * Typos in properties passed to ::create() are captured (if we decide to validate).<br /> * The legacy methods return the expected values (use assertEventLegacyData() and assertEventLegacyData())<br /> * The class properties are correctly overridden (crud, level, action, object, ...).<br /> * The properties automatically generated (component, name, ...) are correct.<br /> * Events are dispatched to the corresponding observers.<br /> * Events are dispatched to the corresponding legacy handlers.<br /> * Events are dispatched to the * observers.<br /> * Events perform an add_to_log() if it has legacy log data.<br /> * 'Events restore' restored the whole event data, and does not miss any information.<br /> * 'Events restore' does not generate any extra information.<br /> * Event methods should check context object or avoid using it, as context might not be valid at time of event restore (use assertEventContextNotUsed())<br /> <br /> = PHP docs =<br /> * All events php docs must include @since parameter, indicating when the event was first included in standard Moodle distribution.<br /> * All events must declare the $other properties using mark down in the php docs.<br /> <br /> = Example events =<br /> <br /> == Assignment ==<br /> <br /> Assumption: Course contains groups with students in each group.<br /> <br /> '''1.''' Teacher creates an assignment with group mode set to 'Separate groups' and Feedback type set to comments and files.<br /> *Event: User 'Teacher' has created assignment 'B' in course 'C101'.<br /> '''2.''' A student views the assignment.<br /> *Event: User 'Student' has viewed assignment 'B' in course 'C101'.<br /> '''3.''' A member from one of the groups submits an assignment<br /> *Event: User 'Student' has added a submission for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: Email sent to the teacher and all students in that group.<br /> '''4.''' User 'Adrian' adds some changes to the assignment and updates it.<br /> *Event: User 'Adrian' has updated the submission for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: Email sent to the teacher and all students in that group.<br /> '''5.''' Teacher views the assignment.<br /> *Event: User 'Teacher' has viewed assignment 'B' in course 'C101'.<br /> '''6.''' Teacher clicks on 'View/grade all submissions'<br /> *Event: User 'Teacher' has viewed the assignment 'B' grade area in course 'C101'.<br /> '''7.''' Teacher clicks to grade the student's submission.<br /> *Event: User 'Teacher' has viewed the submission for user 'student' for assignment 'B' in course 'C101'.<br /> '''8.''' Teacher marks the assignment with the setting 'Apply grades and feedback to entire group' set to 'Yes' leaving a comment and a file.<br /> *Event: User 'Teacher' has marked assignment 'B' for group 'C' in course 'C101'.<br /> *Event: User 'Teacher' has left a comment for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: User 'Teacher' has uploaded a feedback file for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: User 'Teacher' has uploaded a file to the course 'C101'.<br /> *Event: Email sent to user 'Student' notifying them their submission for assignment 'B' has been marked. - This is done for all users in the group.<br /> '''9.''' User 'Adrian' views the feedback.<br /> *Event: User 'Adrian' has viewed assignment 'B' in course 'C101'.<br /> '''10.''' User 'Adrian' opens the feedback file.<br /> *Event: User 'Adrian' has viewed the file 'A' for assignment 'B' in course 'C101'.<br /> '''11.''' User 'Adrian' adds some changes to the assignment insulting the teachers marking and updates it.<br /> *Event: User 'Adrian' has updated the submission for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: Email sent to user 'Teacher' notifying them that user 'Adrian' has updated the submission for assignment 'B'.<br /> *Event: Email sent to user 'Student' notifying them their submission for assignment 'B' has been updated. - This is done for all users in the group.<br /> '''12.''' The teacher clicks directly on the link in the email to be taken to the grading page.<br /> *Event: User 'Teacher' has viewed the submission for user 'student' for assignment 'B' in course 'C101'.<br /> '''13.''' The teacher is upset due to the harsh comments and decides to mark Adrian down, but not the rest of the group by setting 'Apply grades and feedback to entire group' set to 'No'.<br /> *Event: User 'Teacher' has marked assignment 'B' for user 'Adrian' in course 'C101'.<br /> *Event: User 'Teacher' has left a comment for assignment 'B' for user 'Adrian' in course 'C101'.<br /> *Event: User 'Teacher' has uploaded a feedback file for assignment 'B' for user 'Adrian' in course 'C101'.<br /> *Event: Email sent to user 'Adrian' notifying them their submission for assignment 'B' has been marked.<br /> <br /> = FAQs =<br /> <br /> ; Why not use create events in core subsystems? : Because we could not see all core events in one place, it would create problems when naming event classes and finally subsystems are incomplete, we would have to add more now because we could not move the events in the future.<br /> <br /> = Development stages =<br /> <br /> == Stage 1 ==<br /> <br /> * Finish class loader spec and implement basic Frankenstyle class loader.<br /> * Describe new observer definition - just few new flags in current db/events.php<br /> * Describe new event dispatcher.<br /> * Describe core_event_base class.<br /> * Current (= legacy) events triggering:<br /> ** Re-factor current event handling code to new self-contained class - do not change functionality, keep events_trigger().<br /> ** Create new event handler management class that deals with installation and upgrades of both legacy and new handlers.<br /> * New events:<br /> ** Create new core_event_base class.<br /> ** Create new self-contained event dispatcher class with '*' handler support.<br /> ** In function core_event_base::trigger() check if the event has property 'legacyeventname' execute events_trigger($this-&gt;legacyeventname, $this-&gt;legacyeventdata) after triggering new event.<br /> ** Write unit tests for all new events code.<br /> * No changes to be made to the current logging system yet.<br /> <br /> After completing this stage everything should continue to work as it did before and we can start parallel work on further stages.<br /> <br /> == Stage 2 (requires completion of Stage 1) ==<br /> <br /> * Create event classes and replace existing calls to events_trigger() and with new event classes containing legacy information properties.<br /> * Add more events throughout the standard Moodle package in places where we have add_to_log(). Implement some_event::get_legacy_log_data() which returns original parameters of add_to_log() and remove it. Old add_to_log() function is called in core_event_base::trigger() automatically with original parameters.<br /> * Add even more new events all over the place.<br /> <br /> The difficult part is defining the new event classes properly because we must not change them after the 2.6 release.<br /> <br /> == Stage 3 (requires partial completion of Stage 2) ==<br /> <br /> * Migrate current legacy event handlers to new handlers with one event class instance parameter, ex.: enrol plugins.<br /> <br /> == Stage 4 (requires partial completion of Stage 2) ==<br /> <br /> * Implement an event logging handler.<br /> * Implement logging storage plugins.<br /> * Define logging apis.<br /> * Create new reports.<br /> * Switch to new logging everywhere after Stage 2 has been completed and new reports are usable.<br /> <br /> See [[Logging 2]]<br /> <br /> == Stage 5 ==<br /> <br /> * Decide how much backwards compatibility we want for old log tables. Most probably they will get only legacy log data.<br /> * Implement some BC solution for old code that reads log tables directly.<br /> <br /> See [[Logging 2]]<br /> <br /> == Stage 6 (requires completion of Stage 4 and 5) ==<br /> <br /> Moodle 2.8dev? This is the ultimate end of old logging via the ''log'' table.<br /> <br /> * Deprecate the add_to_log() function with a debug message and do nothing inside.<br /> * Remove all legacy logging from event classes.<br /> <br /> See [[Logging 2]]<br /> <br /> = See Also =<br /> [[Logging 2]] <br /> <br /> [[Tin Can]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Events_API&diff=44521 2014-04-24T08:14:15Z

<p>Ankitfrenz: </p> <hr /> <div>{{Infobox Project<br /> |name = Events 2<br /> |state = Implementation in progress<br /> |tracker = MDL-39797 , MDL-39952, MDL-39846<br /> |discussion = https://moodle.org/mod/forum/discuss.php?d=229425<br /> |assignee = Backend Team<br /> }}<br /> <br /> = What are events? =<br /> <br /> Events are atomic pieces of information describing something that happened in Moodle. Events are primarily the result of user actions, but could also be the result of the [[:en:Cron|cron]] process or administration actions [[:en:Administration via command line|undertaken via the command line]].<br /> <br /> When an action takes place, an event is created by a [[Core APIs|core API]] or [[Plugins|plugin]]. The Events system then disseminates this event information to observers registered for this event. In this way, the events system acts as a communication backbone throughout the Moodle system.<br /> <br /> Event observers can not modify event data or interrupt the dispatching of events, it is a one way communication channel.<br /> <br /> = Why is a new events system needed? =<br /> <br /> The need to improve the Events system was prompted by a need for a richer and more efficient logging system, however the benefits of this improvement will be useful to other parts of Moodle that observe event information.<br /> <br /> * The events need to be more strictly defined if we want to use them for new logging and other advanced use cases. They need to contain a lot more information in a standardised way (such as most fields from current log table and log_actions table).<br /> * Complex data types were allowed in old events which was causing major problems when serialising/storing/unserializing the data.<br /> * The logging and events contain similar information and are triggered at the same places, new events would remove this code duplication. All events should be loggable and all current log entries should be triggered as events.<br /> * The logging system will become an event observer, listening to all events and directing them to logging storage plugins in a controllable way.<br /> * It will be possible to subscribe to '*' event, which would allow a system to potentially observe, and selectively deal with, all events. Current handlers do not get event name which makes this problematic.<br /> * Current event handlers may trigger exceptions during site upgrade which would lead to fatal upgrade problems. The new design eliminates this.<br /> * Failure in handlers blocked dispatching of subsequent events. Instead problems in new observers would be only logged and execution would continue normally.<br /> * Current execution of external handlers during DB transactions blocks other handlers. This would be eliminated by in-memory buffer for external events.<br /> * It would good to have observer priority.<br /> * Nested events are not dispatched sequentially, it would change the order of events received in lower priority handlers.<br /> <br /> = Performance =<br /> Some basic profiling has been conducted.<br /> <br /> There is a general plan to complete pre- and post-implementation testing as development happens. The new system will be imemented in parallel with the old one which should help with comparison of new and old logging and event triggering performance on each page.<br /> <br /> Our aim is to trigger more events and log more information, which is going to impact on performance. We hope to offset that impact by improving log storage, simplifying event dispatching and adding other core performance improvements. The proposed class structure of the base event should allow some new advanced techniques, which may also improve performance in some scenarios.<br /> <br /> More details will be added to this section soon.<br /> <br /> = Events API =<br /> <br /> Each plugin will define the events that it can report (trigger) by extending an abstract base class, once for each possible event. This approach will have several benefits.<br /> ; Events will be active objects<br /> : When they are triggered and possibly after they are reinstantiated (say, when they are retrieved from a log), an event object will be able to provide callback functions for various purposes (such as capability checks).<br /> ; Automatic inclusion<br /> : Event class definitions will be automatically included when needed, without having to maintain lists of known event types. New event definitions can be added without the need to upgrade, only purging of MUC cache is required after adding new observer.<br /> ; Maintainability<br /> : It will be easy to add new events and migrate existing events. Code review will be simplified because there will be less duplication of code when triggering events and all event related information/code will be concentrated in one file in fixed locations.<br /> ; Self documenting<br /> : The behaviour of events will be combined with the definition of events in one place (file). It will be easy for event observer writers to know what events a plugin can trigger. This includes support for autocompletion and code inspection in modern IDEs.<br /> ; Quick, self-validating data structure<br /> : As events are instantiated objects, the PHP processor will validate the structure and type of event classes. This does not ensure data value validity, but does give some assurance of consistency and it also detects common typos.<br /> <br /> == Backwards compatibility and migration ==<br /> <br /> Events:<br /> * Moodle core and standard plugins will replace all calls to the events_trigger() function with new events classes.<br /> * For events that already exist in Moodle 2.5 the additional legacy information should be added to the event data (in properties 'legacyeventname' and 'legacyeventdata'.<br /> * The function events_trigger() will continue working as before, but it will be called automatically after a new event is processed using the 'legacyeventname' and 'legacyeventdata'.<br /> * The legacy events handling code will be maintained separately and will continue being supported in Moodle 2.x. New legacy events will not be added.<br /> * Existing legacy event handlers will be migrated to new event handlers accepting new event class instances.<br /> * More subsystems may be migrated to events-handlers, ex.: gradebook history.<br /> <br /> Logging:<br /> * Function add_to_log() and all logging internals will continue working as before.<br /> * Existing add_to_log() parameters will be migrated inside new events method get_legacy_log_data() and core_event_base::trigger() will call add_to_log() automatically (this will depend on $CFG-&gt;loglifetime setting for performance reasons).<br /> <br /> == Event dispatching and observers ==<br /> <br /> The new event dispatching system is completely separate from the old events code. Original event handlers are now called observers with the description stored in the same db/events.php file, but as a new array with a different format.<br /> <br /> === Event observers ===<br /> <br /> The observers are described in db/events.php in the array $observers, the array is not indexed and contains a list of observers defined as an array with the following properties;<br /> * eventname - event class name or &quot;*&quot; indicating all events. All events must use namespace, ex.: ''\plugintype_pluginname\event\something_happened''.<br /> * callback - PHP callable type.<br /> * includefile - optional. File to be included before calling the observer. Path relative to dirroot.<br /> * priority - optional. Defaults to 0. Observers with higher priority are notified first.<br /> * internal - optional. Defaults to true. Non-internal observers are not called during database transactions, but instead after a successful commit of the transaction.<br /> <br /> &lt;code php&gt;<br /> <br /> $observers = array(<br /> <br /> array(<br /> 'eventname' =&gt; '\core\event\sample_executed',<br /> 'callback' =&gt; 'core_event_sample_observer::observe_one',<br /> ),<br /> <br /> array(<br /> 'eventname' =&gt; '\core\event\sample_executed',<br /> 'callback' =&gt; 'core_event_sample_observer::external_observer',<br /> 'priority' =&gt; 200,<br /> 'internal' =&gt; false,<br /> ),<br /> <br /> array(<br /> 'eventname' =&gt; '*',<br /> 'callback' =&gt; 'core_event_sample_observer::observe_all',<br /> 'includefile' =&gt; null,<br /> 'internal' =&gt; true,<br /> 'priority' =&gt; 9999,<br /> ),<br /> <br /> );<br /> <br /> &lt;/code&gt;<br /> <br /> === Event dispatching ===<br /> <br /> A list of available observers is constructed on the fly directly from all available events.php files. Previously handlers were installed only during installation and upgrade. There is no risk of performance regression because the list is already cached in MUC. Observers get events before installation or any upgrade, however observers are not notified during the initial installation of moodle core tables.<br /> <br /> Developers of observers must make sure that execution does not end with a fatal error under any condition (before install, before upgrade or normal operation). Exceptions are automatically captured, logged in the PHP error log, and notification of other observers continues. Current handlers must not throw any exceptions at any time.<br /> <br /> Observers are notified sequentially in the same order in which events were triggered. This means that events triggered in observers are queued in FIFO buffer and are processed after all observers are notified.<br /> <br /> === Differences from old event handling ===<br /> <br /> # New events contain a lot more structured information.<br /> # New event data must not contain any PHP classes.<br /> # There is separate context cache which may be used when deleting data or for observer performance improvements.<br /> # No database access in new event dispatching code.<br /> # There is no support for cron execution - this eliminates performance problems, simplifies events dispatching and prevents abuse of cron events.<br /> # Events triggered in observers are processed in a different order.<br /> # External events are buffered when a transaction is in progress, instead of being sent to the cron queue.<br /> # It is possible to define multiple observers for one event in one events.php file.<br /> # It is possible to subscribe an observer to all events.<br /> # The new event manager is using frankenstyle autoloading - smaller memory footprint when events are not used on the current page.<br /> <br /> == Triggering events ==<br /> <br /> * All event descriptions are objects extending the \core\event\base class.<br /> * Events are triggered by creating a new instance of the class event and executing $event-&gt;trigger().<br /> * Each event class name is a unique identifier of the event.<br /> * Class names and namespace follow the identifier scheme \'''frankenstyle_component'''\event\'''some_object_action'''. Core events have prefix 'core_'.<br /> * Plugins define each event class in a separate file. File name and location must match the class name, for example: '''plugindir'''/classes/event/'''something_happened'''.php<br /> * The event identifier suffix has the form ''some_object_action'' ('''something_happened''' in the example above) and should follow our standard naming convention. The last word after underscore is automatically parsed as action, the rest of words is object.<br /> <br /> Decision:[[#Verb_list| Recommended verb list]]<br /> <br /> Examples: \core\event\course_completed, \mod_assign\event\submission_commented, \mod_forum\event\post_shared, \mod_forum\event\post_responded, etc.<br /> <br /> * Ideally, it should be possible to trigger an event without gathering additional information for the event. To reduce the cost of data gathering, specifically the cost of database reads, at least the minimal values needed to trigger an event should be already available in variables.<br /> <br /> An example of triggering an event:<br /> &lt;code php&gt;<br /> $event = \mod_myplugin\event\something_happened::create(array('context' =&gt; $context, 'objectid' =&gt; YYY, 'other' =&gt; ZZZ));<br /> // ... code that may add some record snapshots<br /> $event-&gt;trigger();<br /> &lt;/code&gt;<br /> <br /> <br /> === Use of php autoloading ===<br /> <br /> All new OOP APIs in Moodle 2.6 are going to use class auto loading - see [[Automatic class loading]]. New events use PHP strictly defined namespaces which concentrate all events classes in classes/event/ subdirectory.<br /> <br /> === Why separate classes? ===<br /> There were two alternatives proposed on how to define the event structure. The first is a separate class for each event (extending the base class), the other being each event is based on a generic event instance of the base class.<br /> &lt;pre&gt;<br /> Decision: Use separate class for each event.<br /> &lt;/pre&gt;<br /> '''Each plugin creates its own event class for each event'''<br /> <br /> Pros<br /> * Maintainability - It is much easier to review, debug, integrate.<br /> * Self documenting, behaviour is combined with definition.<br /> * It is extremely flexible for plugin developers and core devs too.<br /> * Automatically lists events without being installed - PHPDocs as events documentation.<br /> * It is included only when needed using autoloading.<br /> * Self-validating data structure (by PHP).<br /> * Some developers will find it easier to copy whole class files as templates.<br /> Cons<br /> * Big learning curve for developers without OOP skills (all other new subsystems in Moodle already use OOP, you can not code without these skills any more).<br /> * Some developers may find it harder to copy-and-paste examples because they will need to create new class first and use it afterwards (this can be viewed as a benefit because it forces developers to think more about events).<br /> <br /> <br /> '''Each plugin defines events in a list based on a generic object'''<br /> <br /> Pros<br /> * Easier for some developers (this can be eliminated with developer documentation).<br /> * Some developers think it gives more control of event structure in core (we can easily solve that with private access and validation in the base class).<br /> Cons<br /> * It is not flexible enough. PHP code gives developers more freedom.<br /> * It would not be possible to implement any performance hacks in custom methods. All data would have to be calculated even if it is not used.<br /> * It would be necessary to define access control callbacks in other code.<br /> * It would be harder and slower to integrate legacy logging.<br /> * It would be harder and slower to implement support for legacy events.<br /> * Event observers could not use event class names as reliable identifiers.<br /> * Event object and action could not be parsed from class name, it would have to be stored in event properties every time you trigger event.<br /> * Requires upgrade/install to register an event in DB table with MUC cache. Events could not be triggered earlier.<br /> * The localised descriptions and names would have to be stored as properties, it would not be possible to store them in any definition.<br /> * The implementation of an events infrastructure would be significantly more complex and error prone.<br /> <br /> == Information contained in events ==<br /> <br /> Events have to contain as much information as they can, but this should not affect the performance. That's why part of the information is available in properties, and the rest via methods. This allows for delaying the computation of the data at the time it is really needed, if it ever is.<br /> <br /> === Properties ===<br /> <br /> List of properties that the developer has to pass to the event upon creation, or automatically generated when possible and cost free. Some of those properties not mandatory.<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Property name<br /> ! Title<br /> ! Type<br /> ! Comment<br /> |-<br /> | ''eventname''<br /> | Event name<br /> | ''static, automatic from class name''<br /> | Automatically computed by copying class name<br /> |-<br /> | ''component''<br /> | Component<br /> | ''static, automatic from top namespace''<br /> | Component declaring the event, automatically computed from class name.<br /> |-<br /> | ''action''<br /> | Action<br /> | ''static, automatic from last word in class name''<br /> | Can be automatically computed from class name.<br /> |-<br /> | ''target''<br /> | target of action<br /> | ''static, automatic from class name''<br /> | Target on which the action is taken, can be automatically computed from class name.<br /> |-<br /> | objecttable<br /> | Database table name<br /> |<br /> | optional database table name where is/was the object stored. Never use a relationship table here.<br /> |-<br /> | objectid<br /> | Object ID<br /> |<br /> | optional id of the object record from objecttable<br /> |-<br /> | '''''crud'''''<br /> | Transaction type<br /> | ''static mandatory''<br /> | One of [crud] letters. Statically declared in the event class method init().<br /> |-<br /> | '''''level''''' / '''''edulevel'''''<br /> | Level<br /> | ''static mandatory''<br /> | Level of educational value of the event. Statically declared in the event class method init(). Changed from '''''level''''' to '''''edulevel''''' in Moodle 2.7 (See below for more details)<br /> |-<br /> | contextid<br /> | Context ID<br /> | mandatory<br /> | <br /> |-<br /> | contextlevel<br /> | Context level<br /> | automatic from context<br /> | This tells you if it was a course, activity, course category, etc.<br /> |-<br /> | contextinstanceid<br /> | Context instanceid<br /> | automatic from context<br /> | Based on context level this may be course id , course module id, course category, etc.<br /> |-<br /> | userid<br /> | User ID<br /> | defaults to current user<br /> | User ID, or 0 when not logged in, or -1 when other (System, CLI, Cron, ...)<br /> |-<br /> | courseid<br /> | Affected course<br /> | defaults to course context from context<br /> | This is used only for contexts at and bellow course level - this can be used to filter events by course (includes all course activities)<br /> |-<br /> | relateduserid<br /> | Affected user<br /> |<br /> | Is this action related to some user? This could be used for some personal timeline view.<br /> |-<br /> | other<br /> | All other data<br /> |<br /> | Any other fields needed for event description - scalars or arrays, must be serialisable using json_encode()<br /> |-<br /> | timecreated<br /> | Time of the event<br /> | automatic<br /> |<br /> |}<br /> <br /> * ''static'': It is the same for all event instances of this class.<br /> * '''mandatory''': Is required in order to trigger the event.<br /> <br /> ==== Level property ====<br /> <br /> The edulevel property helps defining the educational value of the event. It is intentional that the list is limited to only 3 different constants, having too many options would make it harder for developers to pick the right one(s). We also have to keep in mind that this is not supposed to answer all the questions about a particular event, other event properties like the courseid, the context, the component name can be used with the level to get more granular reports.<br /> <br /> Remember that this is event based. If the user that has triggered the event is not really &quot;participating&quot; because he is an admin, or a manager, then it is the job of the report to filter those. The event itself has a static educational level.<br /> <br /> '''Teaching''' (LEVEL_TEACHING: 1)<br /> <br /> Any event/action that is performed by someone (typically a teacher) and has a teaching value (anything that is affecting the learning experience/environment of the students). This should not be combined with &quot;Participating&quot; events.<br /> <br /> Valid events:<br /> <br /> * A teacher grading a student<br /> * A teacher modifying the course settings<br /> * A teacher adding a new section to the course page<br /> * A teacher modifying a module settings<br /> * A teacher adding a page to course<br /> * A teacher leaving a feedback<br /> <br /> INVALID events:<br /> <br /> * A teacher posting in a forum (it might affect the learning experience, but not necessarily, so the teacher is just participating)<br /> <br /> '''Participating''' (LEVEL_PARTICIPATING: 2)<br /> <br /> Any event/action that is performed by a user, that is related (or could be related) to his learning experience.<br /> <br /> Valid events:<br /> <br /> * A user posting to a forum<br /> * A user submitting an assignment<br /> * A user blogging<br /> * A user reading someone's blog<br /> * A user posting a comment<br /> * A user chatting on a chat activity<br /> * A user viewing the course page<br /> * A user deletes a blog post<br /> <br /> INVALID events:<br /> <br /> * A user updating his profile<br /> * A user visiting someone's profile<br /> * A user viewing his /my/ page<br /> * A user sending a message to another one<br /> <br /> '''Other''' (LEVEL_OTHER: 0)<br /> <br /> Any other action, whether they are related to the site administration, or are specific to user. They do not have any educational value.<br /> <br /> === Methods ===<br /> <br /> The computation of this data is not required by default, but can be accessed by any event observer if need be.<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Method<br /> ! Comment<br /> |-<br /> | get_name()<br /> | Returns localised name of the event, it is the same for all instances.<br /> |-<br /> | get_description()<br /> | Returns localised description of one particular event.<br /> |-<br /> | can_view($user)<br /> | Can the specified user view the event?<br /> |-<br /> | get_url()<br /> | Returns Moodle URL where the event can be observed afterwards.<br /> |-<br /> | get_legacy_eventname()<br /> | Information necessary for event BC.<br /> |-<br /> | get_legacy_eventdata()<br /> | Information necessary for event BC.<br /> |-<br /> | get_legacy_logdata()<br /> | Information necessary for logging BC.<br /> |}<br /> <br /> ===Record caching===<br /> <br /> The standard event data may not contain all the information observers need. The built-in record snapshot support in events allows developers to attach more auxiliary information when triggering events, it may be for example course record, some record that was just deleted, etc. The snapshot is meant to be a full database record, as it will be automatically fetched from get_record_snapshot() if not set previously and assuming the property ''objecttable'' is set. Please be aware that the snapshots are not stored in the event, and cannot be restored.<br /> <br /> &lt;code php&gt;<br /> $event = \core\event\role_assigned::create(<br /> array('context'=&gt;$context, 'objectid'=&gt;$ra-&gt;roleid, 'relateduserid'=&gt;$ra-&gt;userid,<br /> 'other'=&gt;array('id'=&gt;$ra-&gt;id, 'component'=&gt;$ra-&gt;component, 'itemid'=&gt;$ra-&gt;itemid)));<br /> $event-&gt;add_record_snapshot('role_assignments', $ra);<br /> $event-&gt;trigger();<br /> &lt;/code&gt;<br /> <br /> &lt;code php&gt;<br /> $event = \core\event\role_unassigned::create(<br /> array('context'=&gt;$context, 'objectid'=&gt;$ra-&gt;roleid, 'relateduserid'=&gt;$ra-&gt;userid,<br /> 'other'=&gt;array('id'=&gt;$ra-&gt;id, 'component'=&gt;$ra-&gt;component, 'itemid'=&gt;$ra-&gt;itemid)));<br /> $event-&gt;add_record_snapshot('role_assignments', $ra);<br /> $event-&gt;trigger();<br /> &lt;/code&gt;<br /> <br /> The related methods are:<br /> * public function add_record_snapshot($tablename, $record)<br /> * public function get_record_snapshot($tablename, $id)<br /> <br /> === Rejected properties and methods ===<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Property<br /> ! Title<br /> ! Why<br /> |-<br /> | URL<br /> | relevant page URL<br /> | These URLs can be constructed on the fly from other data, external log plugins may use get_url() method.<br /> |-<br /> | version<br /> | Event specification number<br /> | The event specification should never change<br /> |-<br /> | type<br /> | Type of event (action, error, ...)<br /> | Event are not intended for error logging or debugging.<br /> |-<br /> | actor<br /> | Whether current execution is cron, cli, user, ...<br /> | Impossible to track down at a low level<br /> |-<br /> | severity<br /> | Severity following [http://tools.ietf.org/html/rfc5424#section-6.2.1 logging standards]<br /> | Our logging does not match this, as we will not (at present) log errors<br /> |-<br /> | coursecatname<br /> | Category name<br /> | Might be costly to retrieve for little gain<br /> |-<br /> | coursename<br /> | Course name<br /> | Might be costly to retrieve for little gain<br /> |-<br /> | cmname<br /> | Course module name<br /> | Might be costly to retrieve for little gain<br /> |-<br /> | categoryid <br /> | Course category id<br /> | Categories are a tree structure, we can not identify them by one integer. It would have to be a path.<br /> |-<br /> | cmid <br /> | Course module id<br /> | Can be derived from contextlevel and contextinstanceid<br /> |-<br /> | associatedobject<br /> | Associated object<br /> | Object associated to the main object. Ie: The user to whom a message is sent.<br /> |-<br /> | associatedobjectid<br /> | Associated object ID<br /> | Identifier of the associated object<br /> |-<br /> | realuserid<br /> | Real User ID<br /> | Will be tracked by log plugins only - user who &quot;logged in as&quot;, stores the real user ID<br /> |-<br /> | origin<br /> | Origin of the event<br /> | Will be tracked by log plugins only - CLI, cron, Webservice, ... (optionally with IP address)<br /> |}<br /> <br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Method<br /> ! Comment<br /> ! Why<br /> |-<br /> | get_all_affected_users()<br /> | Returns all the users affected by this event<br /> | It is expensive to fetch all users and it changes in time, so it would be unreliable too. For now we store only one user who is related to each event.<br /> |-<br /> | get_objecturl()<br /> | Returns the URL to view the object<br /> | There is usually only one URL where event changes may be observed. The URL may depend on current user capabilities too.<br /> |-<br /> | get_associatedobjecturl()<br /> | Returns the URL to view the associated object<br /> | No associated user property is present.<br /> |-<br /> | get_currenturl()<br /> | Returns the current URL, uses $PAGE.<br /> | This information may be added by logger, current page info is not part of events data.<br /> |-<br /> | get_useripaddress()<br /> | Returns the User IP address<br /> | Page access method is not part of events API, this should be implemented as logdata properties in loggers.<br /> |}<br /> <br /> == Events naming convention ==<br /> <br /> Clear event names help developers when reading what events are triggered, and defining the events properties when defining the event class.<br /> <br /> Decision: \&lt;component&gt;\event\&lt;some_object&gt;_&lt;verb&gt;<br /> <br /> === Existing events ===<br /> <br /> List of existing events in Moodle code base, along with their 2.5 couterparts.<br /> <br /> This list is out of date. For a full list of events check out the [https://docs.moodle.org/en/Event_list_report Event list report] which is located in &quot;Site administration &gt; Reports &gt; Event list&quot; of your Moodle installation (2.7+).<br /> <br /> {| class=&quot;nicetable&quot;<br /> |-<br /> ! Fully qualified event name<br /> ! 2.5 name<br /> ! Component<br /> ! Object<br /> ! Action (Verb)<br /> ! Comment<br /> |-<br /> | '''assignsubmission_comments\event\comment_created'''<br /> | -<br /> | assignsubmission_comments<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''assignsubmission_comments\event\comment_deleted'''<br /> | -<br /> | assignsubmission_comments<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''assignsubmission_file\event\assessable_uploaded'''<br /> | assessable_file_uploaded<br /> | assignsubmission_file<br /> | assessable<br /> | uploaded<br /> | To be deprecated MDL-35197<br /> |- <br /> | '''assignsubmission_file\event\submission_created'''<br /> | -<br /> | assignsubmission_file<br /> | submission<br /> | created<br /> | <br /> |- <br /> | '''assignsubmission_file\event\submission_updated'''<br /> | -<br /> | assignsubmission_file<br /> | submission<br /> | updated<br /> | <br /> |- <br /> | '''assignsubmission_onlinetext\event\assessable_uploaded'''<br /> | assessable_content_uploaded<br /> | assignsubmission_onlinetext<br /> | assessable<br /> | uploaded<br /> | <br /> |- <br /> | '''assignsubmission_onlinetext\event\submission_created'''<br /> | -<br /> | assignsubmission_onlinetext<br /> | submission<br /> | created<br /> | <br /> |- <br /> | '''assignsubmission_onlinetext\event\submission_updated'''<br /> | -<br /> | assignsubmission_onlinetext<br /> | submission<br /> | updated<br /> | <br /> |- <br /> | '''block_comments\event\comment_created'''<br /> | -<br /> | block_comments<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''block_comments\event\comment_deleted'''<br /> | -<br /> | block_comments<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''booktool_exportimscp\event\book_exported'''<br /> | -<br /> | booktool_exportimscp<br /> | book<br /> | exported<br /> | <br /> |- <br /> | '''booktool_print\event\book_printed'''<br /> | -<br /> | booktool_print<br /> | book<br /> | printed<br /> | <br /> |- <br /> | '''booktool_print\event\chapter_printed'''<br /> | -<br /> | booktool_print<br /> | chapter<br /> | printed<br /> | <br /> |- <br /> | '''core\event\assessable_submitted'''<br /> | -<br /> | core<br /> | assessable<br /> | submitted<br /> | Abstract class <br /> |- <br /> | '''core\event\assessable_uploaded'''<br /> | -<br /> | core<br /> | assessable<br /> | uploaded<br /> | Abstract class <br /> |- <br /> | '''core\event\base'''<br /> | -<br /> | core<br /> | base<br /> | -<br /> | Abstract class <br /> |- <br /> | '''core\event\blog_association_created'''<br /> | -<br /> | core<br /> | blog_association<br /> | created<br /> | <br /> |- <br /> | '''core\event\blog_comment_created'''<br /> | -<br /> | core<br /> | blog_comment<br /> | created<br /> | <br /> |- <br /> | '''core\event\blog_comment_deleted'''<br /> | -<br /> | core<br /> | blog_comment<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\blog_entries_viewed'''<br /> | -<br /> | core<br /> | blog_entries<br /> | viewed<br /> | <br /> |- <br /> | '''core\event\blog_entry_created'''<br /> | blog_entry_added<br /> | core<br /> | blog_entry<br /> | created<br /> | <br /> |- <br /> | '''core\event\blog_entry_deleted'''<br /> | blog_entry_deleted<br /> | core<br /> | blog_entry<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\blog_entry_updated'''<br /> | blog_entry_edited<br /> | core<br /> | blog_entry<br /> | updated<br /> | <br /> |- <br /> | '''core\event\cohort_created'''<br /> | cohort_added<br /> | core<br /> | cohort<br /> | created<br /> | <br /> |- <br /> | '''core\event\cohort_deleted'''<br /> | cohort_deleted<br /> | core<br /> | cohort<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\cohort_member_added'''<br /> | cohort_member_added<br /> | core<br /> | cohort_member<br /> | added<br /> | <br /> |- <br /> | '''core\event\cohort_member_removed'''<br /> | cohort_member_removed<br /> | core<br /> | cohort_member<br /> | removed<br /> | <br /> |- <br /> | '''core\event\cohort_updated'''<br /> | cohort_updated<br /> | core<br /> | cohort<br /> | updated<br /> | <br /> |- <br /> | '''core\event\comment_created'''<br /> | -<br /> | core<br /> | comment<br /> | created<br /> | Abstract class <br /> |- <br /> | '''core\event\comment_deleted'''<br /> | -<br /> | core<br /> | comment<br /> | deleted<br /> | Abstract class <br /> |- <br /> | '''core\event\comments_viewed'''<br /> | -<br /> | core<br /> | comments<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\content_viewed'''<br /> | -<br /> | core<br /> | content<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\course_category_created'''<br /> | -<br /> | core<br /> | course_category<br /> | created<br /> | <br /> |- <br /> | '''core\event\course_category_deleted'''<br /> | course_category_deleted<br /> | core<br /> | course_category<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\course_category_updated'''<br /> | -<br /> | core<br /> | course_category<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_completed'''<br /> | course_completed<br /> | core<br /> | course<br /> | completed<br /> | <br /> |- <br /> | '''core\event\course_completion_updated'''<br /> | -<br /> | core<br /> | course_completion<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_content_deleted'''<br /> | course_content_removed<br /> | core<br /> | course_content<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\course_created'''<br /> | course_created<br /> | core<br /> | course<br /> | created<br /> | <br /> |- <br /> | '''core\event\course_deleted'''<br /> | course_deleted<br /> | core<br /> | course<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\course_module_completion_updated'''<br /> | activity_completion_changed<br /> | core<br /> | course_module_completion<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_module_created'''<br /> | mod_created<br /> | core<br /> | course_module<br /> | created<br /> | <br /> |- <br /> | '''core\event\course_module_deleted'''<br /> | mod_deleted<br /> | core<br /> | course_module<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\course_module_instance_list_viewed'''<br /> | -<br /> | core<br /> | course_module_instance_list<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\course_module_instances_list_viewed'''<br /> | -<br /> | core<br /> | course_module_instances_list<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\course_module_updated'''<br /> | mod_updated<br /> | core<br /> | course_module<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_module_viewed'''<br /> | -<br /> | core<br /> | course_module<br /> | viewed<br /> | Abstract class <br /> |- <br /> | '''core\event\course_reset_ended'''<br /> | -<br /> | core<br /> | course_reset<br /> | ended<br /> | <br /> |- <br /> | '''core\event\course_reset_started'''<br /> | -<br /> | core<br /> | course_reset<br /> | started<br /> | <br /> |- <br /> | '''core\event\course_restored'''<br /> | course_restored<br /> | core<br /> | course<br /> | restored<br /> | <br /> |- <br /> | '''core\event\course_section_updated'''<br /> | -<br /> | core<br /> | course_section<br /> | updated<br /> | <br /> |- <br /> | '''core\event\course_updated'''<br /> | course_updated<br /> | core<br /> | course<br /> | updated<br /> | <br /> |- <br /> | '''core\event\email_failed'''<br /> | -<br /> | core<br /> | email<br /> | failed<br /> | <br /> |- <br /> | '''core\event\group_created'''<br /> | groups_group_created<br /> | core<br /> | group<br /> | created<br /> | <br /> |- <br /> | '''core\event\group_deleted'''<br /> | groups_group_deleted<br /> | core<br /> | group<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\group_member_added'''<br /> | groups_member_added<br /> | core<br /> | group_member<br /> | added<br /> | <br /> |- <br /> | '''core\event\group_member_removed'''<br /> | groups_member_removed<br /> | core<br /> | group_member<br /> | removed<br /> | <br /> |- <br /> | '''core\event\group_updated'''<br /> | groups_group_updated<br /> | core<br /> | group<br /> | updated<br /> | <br /> |- <br /> | '''core\event\grouping_created'''<br /> | groups_grouping_created<br /> | core<br /> | grouping<br /> | created<br /> | <br /> |- <br /> | '''core\event\grouping_deleted'''<br /> | groups_grouping_deleted<br /> | core<br /> | grouping<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\grouping_updated'''<br /> | groups_grouping_updated<br /> | core<br /> | grouping<br /> | updated<br /> | <br /> |- <br /> | '''core\event\manager'''<br /> | -<br /> | core<br /> | manager<br /> | anager<br /> | <br /> |- <br /> | '''core\event\mnet_access_control_created'''<br /> | -<br /> | core<br /> | mnet_access_control<br /> | created<br /> | <br /> |- <br /> | '''core\event\mnet_access_control_updated'''<br /> | -<br /> | core<br /> | mnet_access_control<br /> | updated<br /> | <br /> |- <br /> | '''core\event\note_created'''<br /> | -<br /> | core<br /> | note<br /> | created<br /> | <br /> |- <br /> | '''core\event\note_deleted'''<br /> | -<br /> | core<br /> | note<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\note_updated'''<br /> | -<br /> | core<br /> | note<br /> | updated<br /> | <br /> |- <br /> | '''core\event\notes_viewed'''<br /> | -<br /> | core<br /> | notes<br /> | viewed<br /> | <br /> |- <br /> | '''core\event\role_allow_assign_updated'''<br /> | -<br /> | core<br /> | role_allow_assign<br /> | updated<br /> | <br /> |- <br /> | '''core\event\role_allow_override_updated'''<br /> | -<br /> | core<br /> | role_allow_override<br /> | updated<br /> | <br /> |- <br /> | '''core\event\role_allow_switch_updated'''<br /> | -<br /> | core<br /> | role_allow_switch<br /> | updated<br /> | <br /> |- <br /> | '''core\event\role_assigned'''<br /> | role_assigned<br /> | core<br /> | role<br /> | assigned<br /> | <br /> |- <br /> | '''core\event\role_capabilities_updated'''<br /> | -<br /> | core<br /> | role_capabilities<br /> | updated<br /> | <br /> |- <br /> | '''core\event\role_deleted'''<br /> | -<br /> | core<br /> | role<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\role_unassigned'''<br /> | role_unassigned<br /> | core<br /> | role<br /> | unassigned<br /> | <br /> |- <br /> | '''core\event\user_created'''<br /> | user_created<br /> | core<br /> | user<br /> | created<br /> | <br /> |- <br /> | '''core\event\user_deleted'''<br /> | user_deleted<br /> | core<br /> | user<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\user_enrolment_created'''<br /> | user_enrolled<br /> | core<br /> | user_enrolment<br /> | created<br /> | <br /> |- <br /> | '''core\event\user_enrolment_deleted'''<br /> | user_unenrolled<br /> | core<br /> | user_enrolment<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\user_enrolment_updated'''<br /> | user_enrol_modified<br /> | core<br /> | user_enrolment<br /> | updated<br /> | <br /> |- <br /> | '''core\event\user_list_viewed'''<br /> | -<br /> | core<br /> | user_list<br /> | viewed<br /> | <br /> |- <br /> | '''core\event\user_loggedin'''<br /> | -<br /> | core<br /> | user<br /> | loggedin<br /> | <br /> |- <br /> | '''core\event\user_loggedinas'''<br /> | -<br /> | core<br /> | user<br /> | loggedinas<br /> | <br /> |- <br /> | '''core\event\user_loggedout'''<br /> | user_logout<br /> | core<br /> | user<br /> | loggedout<br /> | <br /> |- <br /> | '''core\event\user_login_failed'''<br /> | -<br /> | core<br /> | user_login<br /> | failed<br /> | <br /> |- <br /> | '''core\event\user_profile_viewed'''<br /> | -<br /> | core<br /> | user_profile<br /> | viewed<br /> | <br /> |- <br /> | '''core\event\user_updated'''<br /> | user_updated<br /> | core<br /> | user<br /> | updated<br /> | <br /> |- <br /> | '''core\event\webservice_function_called'''<br /> | -<br /> | core<br /> | webservice_function<br /> | called<br /> | <br /> |- <br /> | '''core\event\webservice_login_failed'''<br /> | -<br /> | core<br /> | webservice_login<br /> | failed<br /> | <br /> |- <br /> | '''core\event\webservice_service_created'''<br /> | -<br /> | core<br /> | webservice_service<br /> | created<br /> | <br /> |- <br /> | '''core\event\webservice_service_deleted'''<br /> | -<br /> | core<br /> | webservice_service<br /> | deleted<br /> | <br /> |- <br /> | '''core\event\webservice_service_updated'''<br /> | -<br /> | core<br /> | webservice_service<br /> | updated<br /> | <br /> |- <br /> | '''core\event\webservice_service_user_added'''<br /> | -<br /> | core<br /> | webservice_service_user<br /> | added<br /> | <br /> |- <br /> | '''core\event\webservice_service_user_removed'''<br /> | -<br /> | core<br /> | webservice_service_user<br /> | removed<br /> | <br /> |- <br /> | '''core\event\webservice_token_created'''<br /> | -<br /> | core<br /> | webservice_token<br /> | created<br /> | <br /> |- <br /> | '''core\event\webservice_token_sent'''<br /> | -<br /> | core<br /> | webservice_token<br /> | sent<br /> | <br /> |- <br /> | '''logstore_legacy\event\legacy_logged'''<br /> | -<br /> | logstore_legacy<br /> | legacy<br /> | logged<br /> | <br /> |- <br /> | '''mod_assign\event\all_submissions_downloaded'''<br /> | -<br /> | mod_assign<br /> | all_submissions<br /> | downloaded<br /> | <br /> |- <br /> | '''mod_assign\event\assessable_submitted'''<br /> | assessable_submitted<br /> | mod_assign<br /> | assessable<br /> | submitted<br /> | <br /> |- <br /> | '''mod_assign\event\extension_granted'''<br /> | -<br /> | mod_assign<br /> | extension<br /> | granted<br /> | <br /> |- <br /> | '''mod_assign\event\identities_revealed'''<br /> | -<br /> | mod_assign<br /> | identities<br /> | revealed<br /> | <br /> |- <br /> | '''mod_assign\event\marker_updated'''<br /> | -<br /> | mod_assign<br /> | marker<br /> | updated<br /> | <br /> |- <br /> | '''mod_assign\event\statement_accepted'''<br /> | -<br /> | mod_assign<br /> | statement<br /> | accepted<br /> | <br /> |- <br /> | '''mod_assign\event\submission_created'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | created<br /> | Abstract class <br /> |- <br /> | '''mod_assign\event\submission_duplicated'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | duplicated<br /> | <br /> |- <br /> | '''mod_assign\event\submission_graded'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | graded<br /> | <br /> |- <br /> | '''mod_assign\event\submission_locked'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | locked<br /> | <br /> |- <br /> | '''mod_assign\event\submission_status_updated'''<br /> | -<br /> | mod_assign<br /> | submission_status<br /> | updated<br /> | <br /> |- <br /> | '''mod_assign\event\submission_unlocked'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | unlocked<br /> | <br /> |- <br /> | '''mod_assign\event\submission_updated'''<br /> | -<br /> | mod_assign<br /> | submission<br /> | updated<br /> | Abstract class <br /> |- <br /> | '''mod_assign\event\workflow_state_updated'''<br /> | -<br /> | mod_assign<br /> | workflow_state<br /> | updated<br /> | <br /> |- <br /> | '''mod_book\event\chapter_created'''<br /> | -<br /> | mod_book<br /> | chapter<br /> | created<br /> | <br /> |- <br /> | '''mod_book\event\chapter_deleted'''<br /> | -<br /> | mod_book<br /> | chapter<br /> | deleted<br /> | <br /> |- <br /> | '''mod_book\event\chapter_updated'''<br /> | -<br /> | mod_book<br /> | chapter<br /> | updated<br /> | <br /> |- <br /> | '''mod_book\event\chapter_viewed'''<br /> | -<br /> | mod_book<br /> | chapter<br /> | viewed<br /> | <br /> |- <br /> | '''mod_book\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_book<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_book\event\course_module_viewed'''<br /> | -<br /> | mod_book<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_chat\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_chat<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_chat\event\message_sent'''<br /> | -<br /> | mod_chat<br /> | message<br /> | sent<br /> | <br /> |- <br /> | '''mod_chat\event\sessions_viewed'''<br /> | -<br /> | mod_chat<br /> | sessions<br /> | viewed<br /> | <br /> |- <br /> | '''mod_choice\event\answer_submitted'''<br /> | -<br /> | mod_choice<br /> | answer<br /> | submitted<br /> | <br /> |- <br /> | '''mod_choice\event\answer_updated'''<br /> | -<br /> | mod_choice<br /> | answer<br /> | updated<br /> | <br /> |- <br /> | '''mod_choice\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_choice<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_choice\event\course_module_viewed'''<br /> | -<br /> | mod_choice<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_choice\event\report_viewed'''<br /> | -<br /> | mod_choice<br /> | report<br /> | viewed<br /> | <br /> |- <br /> | '''mod_data\event\comment_created'''<br /> | -<br /> | mod_data<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''mod_data\event\comment_deleted'''<br /> | -<br /> | mod_data<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''mod_data\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_data<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_data\event\course_module_viewed'''<br /> | -<br /> | mod_data<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_data\event\field_created'''<br /> | -<br /> | mod_data<br /> | field<br /> | created<br /> | <br /> |- <br /> | '''mod_data\event\field_deleted'''<br /> | -<br /> | mod_data<br /> | field<br /> | deleted<br /> | <br /> |- <br /> | '''mod_data\event\field_updated'''<br /> | -<br /> | mod_data<br /> | field<br /> | updated<br /> | <br /> |- <br /> | '''mod_data\event\record_created'''<br /> | -<br /> | mod_data<br /> | record<br /> | created<br /> | <br /> |- <br /> | '''mod_data\event\record_deleted'''<br /> | -<br /> | mod_data<br /> | record<br /> | deleted<br /> | <br /> |- <br /> | '''mod_data\event\record_updated'''<br /> | -<br /> | mod_data<br /> | record<br /> | updated<br /> | <br /> |- <br /> | '''mod_data\event\template_updated'''<br /> | -<br /> | mod_data<br /> | template<br /> | updated<br /> | <br /> |- <br /> | '''mod_data\event\template_viewed'''<br /> | -<br /> | mod_data<br /> | template<br /> | viewed<br /> | <br /> |- <br /> | '''mod_feedback\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_feedback<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_feedback\event\course_module_viewed'''<br /> | -<br /> | mod_feedback<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_feedback\event\response_deleted'''<br /> | -<br /> | mod_feedback<br /> | response<br /> | deleted<br /> | <br /> |- <br /> | '''mod_feedback\event\response_submitted'''<br /> | -<br /> | mod_feedback<br /> | response<br /> | submitted<br /> | <br /> |- <br /> | '''mod_folder\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_folder<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_folder\event\course_module_viewed'''<br /> | -<br /> | mod_folder<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_folder\event\folder_updated'''<br /> | -<br /> | mod_folder<br /> | folder<br /> | updated<br /> | <br /> |- <br /> | '''mod_forum\event\assessable_uploaded'''<br /> | assessable_content_uploaded<br /> | mod_forum<br /> | assessable<br /> | uploaded<br /> | <br /> |- <br /> | '''mod_forum\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_forum<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_forum\event\course_searched'''<br /> | -<br /> | mod_forum<br /> | course<br /> | searched<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_created'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | created<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_deleted'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | deleted<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_moved'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | moved<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_updated'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | updated<br /> | <br /> |- <br /> | '''mod_forum\event\discussion_viewed'''<br /> | -<br /> | mod_forum<br /> | discussion<br /> | viewed<br /> | <br /> |- <br /> | '''mod_forum\event\forum_viewed'''<br /> | -<br /> | mod_forum<br /> | forum<br /> | viewed<br /> | <br /> |- <br /> | '''mod_forum\event\post_created'''<br /> | -<br /> | mod_forum<br /> | post<br /> | created<br /> | <br /> |- <br /> | '''mod_forum\event\post_deleted'''<br /> | -<br /> | mod_forum<br /> | post<br /> | deleted<br /> | <br /> |- <br /> | '''mod_forum\event\post_updated'''<br /> | -<br /> | mod_forum<br /> | post<br /> | updated<br /> | <br /> |- <br /> | '''mod_forum\event\readtracking_disabled'''<br /> | -<br /> | mod_forum<br /> | readtracking<br /> | disabled<br /> | <br /> |- <br /> | '''mod_forum\event\readtracking_enabled'''<br /> | -<br /> | mod_forum<br /> | readtracking<br /> | enabled<br /> | <br /> |- <br /> | '''mod_forum\event\subscribers_viewed'''<br /> | -<br /> | mod_forum<br /> | subscribers<br /> | viewed<br /> | <br /> |- <br /> | '''mod_forum\event\subscription_created'''<br /> | -<br /> | mod_forum<br /> | subscription<br /> | created<br /> | <br /> |- <br /> | '''mod_forum\event\subscription_deleted'''<br /> | -<br /> | mod_forum<br /> | subscription<br /> | deleted<br /> | <br /> |- <br /> | '''mod_forum\event\userreport_viewed'''<br /> | -<br /> | mod_forum<br /> | userreport<br /> | viewed<br /> | <br /> |- <br /> | '''mod_glossary\event\comment_created'''<br /> | -<br /> | mod_glossary<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''mod_glossary\event\comment_deleted'''<br /> | -<br /> | mod_glossary<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''mod_lesson\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_lesson<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lesson\event\course_module_viewed'''<br /> | -<br /> | mod_lesson<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lesson\event\essay_assessed'''<br /> | -<br /> | mod_lesson<br /> | essay<br /> | assessed<br /> | <br /> |- <br /> | '''mod_lesson\event\essay_attempt_viewed'''<br /> | -<br /> | mod_lesson<br /> | essay_attempt<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lesson\event\highscore_added'''<br /> | -<br /> | mod_lesson<br /> | highscore<br /> | added<br /> | <br /> |- <br /> | '''mod_lesson\event\highscores_viewed'''<br /> | -<br /> | mod_lesson<br /> | highscores<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lesson\event\lesson_ended'''<br /> | -<br /> | mod_lesson<br /> | lesson<br /> | ended<br /> | <br /> |- <br /> | '''mod_lesson\event\lesson_started'''<br /> | -<br /> | mod_lesson<br /> | lesson<br /> | started<br /> | <br /> |- <br /> | '''mod_lti\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_lti<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lti\event\course_module_viewed'''<br /> | -<br /> | mod_lti<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_lti\event\unknown_service_api_called'''<br /> | lti_unknown_service_api_call<br /> | mod_lti<br /> | unknown_service_api<br /> | called<br /> | <br /> |- <br /> | '''mod_page\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_page<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_page\event\course_module_viewed'''<br /> | -<br /> | mod_page<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_quiz\event\attempt_abandoned'''<br /> | quiz_attempt_abandoned<br /> | mod_quiz<br /> | attempt<br /> | abandoned<br /> | <br /> |- <br /> | '''mod_quiz\event\attempt_becameoverdue'''<br /> | quiz_attempt_overdue<br /> | mod_quiz<br /> | attempt<br /> | becameoverdue<br /> | <br /> |- <br /> | '''mod_quiz\event\attempt_started'''<br /> | quiz_attempt_started<br /> | mod_quiz<br /> | attempt<br /> | started<br /> | <br /> |- <br /> | '''mod_quiz\event\attempt_submitted'''<br /> | quiz_attempt_submitted<br /> | mod_quiz<br /> | attempt<br /> | submitted<br /> | <br /> |- <br /> | '''mod_resource\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_resource<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_resource\event\course_module_viewed'''<br /> | -<br /> | mod_resource<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\attempt_deleted'''<br /> | -<br /> | mod_scorm<br /> | attempt<br /> | deleted<br /> | <br /> |- <br /> | '''mod_scorm\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_scorm<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\course_module_viewed'''<br /> | -<br /> | mod_scorm<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\interactions_viewed'''<br /> | -<br /> | mod_scorm<br /> | interactions<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\report_viewed'''<br /> | -<br /> | mod_scorm<br /> | report<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\sco_launched'''<br /> | -<br /> | mod_scorm<br /> | sco<br /> | launched<br /> | <br /> |- <br /> | '''mod_scorm\event\tracks_viewed'''<br /> | -<br /> | mod_scorm<br /> | tracks<br /> | viewed<br /> | <br /> |- <br /> | '''mod_scorm\event\user_report_viewed'''<br /> | -<br /> | mod_scorm<br /> | user_report<br /> | viewed<br /> | <br /> |- <br /> | '''mod_url\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_url<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_url\event\course_module_viewed'''<br /> | -<br /> | mod_url<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\comment_created'''<br /> | -<br /> | mod_wiki<br /> | comment<br /> | created<br /> | <br /> |- <br /> | '''mod_wiki\event\comment_deleted'''<br /> | -<br /> | mod_wiki<br /> | comment<br /> | deleted<br /> | <br /> |- <br /> | '''mod_wiki\event\comments_viewed'''<br /> | -<br /> | mod_wiki<br /> | comments<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\course_module_instance_list_viewed'''<br /> | -<br /> | mod_wiki<br /> | course_module_instance_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\course_module_viewed'''<br /> | -<br /> | mod_wiki<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_created'''<br /> | -<br /> | mod_wiki<br /> | page<br /> | created<br /> | <br /> |- <br /> | '''mod_wiki\event\page_deleted'''<br /> | -<br /> | mod_wiki<br /> | page<br /> | deleted<br /> | <br /> |- <br /> | '''mod_wiki\event\page_diff_viewed'''<br /> | -<br /> | mod_wiki<br /> | page_diff<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_history_viewed'''<br /> | -<br /> | mod_wiki<br /> | page_history<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_locks_deleted'''<br /> | -<br /> | mod_wiki<br /> | page_locks<br /> | deleted<br /> | <br /> |- <br /> | '''mod_wiki\event\page_map_viewed'''<br /> | -<br /> | mod_wiki<br /> | page_map<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_updated'''<br /> | -<br /> | mod_wiki<br /> | page<br /> | updated<br /> | <br /> |- <br /> | '''mod_wiki\event\page_version_deleted'''<br /> | -<br /> | mod_wiki<br /> | page_version<br /> | deleted<br /> | <br /> |- <br /> | '''mod_wiki\event\page_version_restored'''<br /> | -<br /> | mod_wiki<br /> | page_version<br /> | restored<br /> | <br /> |- <br /> | '''mod_wiki\event\page_version_viewed'''<br /> | -<br /> | mod_wiki<br /> | page_version<br /> | viewed<br /> | <br /> |- <br /> | '''mod_wiki\event\page_viewed'''<br /> | -<br /> | mod_wiki<br /> | page<br /> | viewed<br /> | <br /> |- <br /> | '''mod_workshop\event\assessable_uploaded'''<br /> | assessable_content_uploaded<br /> | mod_workshop<br /> | assessable<br /> | uploaded<br /> | <br /> |- <br /> | '''mod_workshop\event\assessment_evaluated'''<br /> | -<br /> | mod_workshop<br /> | assessment<br /> | evaluated<br /> | <br /> |- <br /> | '''mod_workshop\event\assessment_evaluations_reset'''<br /> | -<br /> | mod_workshop<br /> | assessment_evaluations<br /> | reset<br /> | <br /> |- <br /> | '''mod_workshop\event\assessment_reevaluated'''<br /> | -<br /> | mod_workshop<br /> | assessment<br /> | reevaluated<br /> | <br /> |- <br /> | '''mod_workshop\event\course_module_viewed'''<br /> | workshop_viewed<br /> | mod_workshop<br /> | course_module<br /> | viewed<br /> | <br /> |- <br /> | '''mod_workshop\event\instances_list_viewed'''<br /> | -<br /> | mod_workshop<br /> | instances_list<br /> | viewed<br /> | <br /> |- <br /> | '''mod_workshop\event\phase_switched'''<br /> | -<br /> | mod_workshop<br /> | phase<br /> | switched<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_assessed'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | assessed<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_created'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | created<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_reassessed'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | reassessed<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_updated'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | updated<br /> | <br /> |- <br /> | '''mod_workshop\event\submission_viewed'''<br /> | -<br /> | mod_workshop<br /> | submission<br /> | viewed<br /> | <br /> |- <br /> | '''report_log\event\content_viewed'''<br /> | -<br /> | report_log<br /> | content<br /> | viewed<br /> | <br /> |- <br /> | '''report_loglive\event\content_viewed'''<br /> | -<br /> | report_loglive<br /> | content<br /> | viewed<br /> | <br /> |- <br /> | '''report_outline\event\content_viewed'''<br /> | -<br /> | report_outline<br /> | content<br /> | viewed<br /> | <br /> |- <br /> | '''report_participation\event\content_viewed'''<br /> | -<br /> | report_participation<br /> | content<br /> | viewed<br /> | <br /> |- <br /> | '''report_stats\event\content_viewed'''<br /> | -<br /> | report_stats<br /> | content<br /> | viewed<br /> | <br /> |- <br /> |}<br /> <br /> === Verb list ===<br /> All events must use a verb from this list. New verbs should be added to this list if required.<br /> {| class=&quot;nicetable&quot;<br /> |-<br /> !verb<br /> !Explanation<br /> !Source<br /> |-<br /> |abandoned<br /> |When a attempt is abandoned by user (Quiz attempt)<br /> |Moodle<br /> |-<br /> |accepted<br /> |Example: Accepting a statement when submitting an assignment.<br /> |Moodle<br /> |-<br /> |added<br /> | Used to represent &quot;something that already exists is now part of/bound to another entity&quot;. Examples: &quot;Admin added role to user X&quot;, &quot;Admin added user X to group A&quot;. Wrong example: &quot;User added course in category&quot; because it is a 'move' action, except if a course can be part of multiple categories. The good examples work because: A user can have multiple roles, a user can be in multiple groups.<br /> |Moodle<br /> |-<br /> |answered<br /> | Indicates the actor responded to a Question<br /> |Tincan<br /> |-<br /> |assessed<br /> | Some submitted material has been assessed<br /> |Moodle<br /> |-<br /> |assigned<br /> | Assign some privilege or role to user.<br /> |Moodle<br /> |-<br /> |attempted<br /> | Trying to do an activity. Example: attempting a Math class.<br /> |Tincan<br /> |-<br /> |awarded<br /> | ex:-teacher awarded student a badge.<br /> |Moodle<br /> |-<br /> |backedup<br /> | When a backup has been performed.<br /> |Moodle <br /> |-<br /> |becomeoverdue<br /> | When an activity is overdue Example: Quiz attempt is overdue<br /> |Moodle <br /> |-<br /> |called<br /> | When a call to something is made like an API @see unknown_service_api_called.php<br /> |Moodle<br /> |-<br /> |commented<br /> |Offered an opinion or written experience of the activity. Can be used with the learner as the actor or a system as an actor. Comments can be sent from either party with the idea that the other will read and react to the content.<br /> |Tincan<br /> |-<br /> |completed<br /> |To experience the activity in its entirety. Used to affirm the completion of content. This can be simply experiencing all the content, be tied to objectives or interactions, or determined in any other way. Any content that has been initialized, but not yet completed, should be considered incomplete. There is no verb to 'incomplete' an activity, one would void the statement which completes the activity.&quot;<br /> |Tincan<br /> |-<br /> |created<br /> |Used to represent &quot;something new has been created&quot;.<br /> |Moodle<br /> |-<br /> |deleted<br /> |Used to indicate the object in context was deleted.<br /> |Moodle<br /> |-<br /> |disabled<br /> |When an activity is disabled. Example: forum read tracking disabled.<br /> |Moodle<br /> |-<br /> |downloaded<br /> |When a user download file from user. Example submission/report downloaded.<br /> |Moodle<br /> |-<br /> |duplicated<br /> |For something that has been copied.<br /> |Moodle<br /> |-<br /> |enabled<br /> |When some setting is enabled. Example: forum read tracking enabled.<br /> |Moodle<br /> |-<br /> |ended<br /> |When a process ends. Example: Lesson ended or course reset ended.<br /> |Moodle<br /> |-<br /> |evaluated<br /> |Material has been evaluated.<br /> |Moodle<br /> |-<br /> |exported<br /> |When a report is exported in certain format.<br /> |Moodle<br /> |-<br /> |failed<br /> |Learner did not perform the activity to a level of pre-determined satisfaction. Used to affirm the lack of success a learner experienced within the learning content in relation to a threshold. If the user performed below the minimum to the level of this threshold, the content is 'failed'. The opposite of 'passed'. This is also used in case when message sending is failed.<br /> |Tincan<br /> |-<br /> |graded<br /> |Used to represent an activity was graded.<br /> |Moodle<br /> |-<br /> |granted<br /> |User is granted some extension or capability. Example: extension granted for submission.<br /> |Moodle<br /> |-<br /> |imported<br /> |The act of moving an object into another location or system.<br /> |Tincan<br /> |-<br /> |launched<br /> |When an external object is launched. Try consider started if there is related stopped event.<br /> |Moodle<br /> |-<br /> |locked<br /> |When an activity is locked. Should have a related unlocked event.<br /> |Moodle<br /> |-<br /> |loggedin/loggedout<br /> | For login and logout.<br /> |Moodle<br /> |-<br /> |loggedinas<br /> | If user is logged in as different user. This is used by only one event (user_loggedinas). Adding this verb makes event name more clear, then using loggedin verb.<br /> |Moodle<br /> |-<br /> |locked<br /> |<br /> |Moodle<br /> |-<br /> |moved<br /> | Used to indicate the object in context was moved.<br /> |Moodle<br /> |-<br /> |passed<br /> |Used to affirm the success a learner experienced within the learning content in relation to a threshold. If the user performed at a minimum to the level of this threshold, the content is 'passed'. The opposite of 'failed'.<br /> |Tincan<br /> |-<br /> |printed<br /> |Something is printed.<br /> |Moodle<br /> |-<br /> |reassessed<br /> |Submitted material has been assessed again.<br /> |Moodle<br /> |-<br /> |reevaluated<br /> |Material has been evaluated again.<br /> |Moodle<br /> |-<br /> |removed<br /> |By opposition to &quot;Added&quot;. This does not mean that the object has been deleted, but removed from the entity, or not bound to it any more.<br /> |Moodle<br /> |-<br /> |reset<br /> |Sets one or more properties back to the default value.<br /> |Moodle<br /> |-<br /> |restored<br /> |When restoring a backup. Rolling back to a previous state.<br /> |Moodle<br /> |-<br /> |revealed<br /> |Some identity is revealed. Example: Identities revealed after blind marking.<br /> |Moodle<br /> |-<br /> |searched<br /> |Something is searched. Example: searched in course.<br /> |Moodle<br /> |-<br /> |sent<br /> |Message sent.<br /> |Moodle<br /> |-<br /> |started<br /> |Some activity started<br /> |Moodle<br /> |-<br /> |submitted<br /> |This is very close to &quot;Attempted&quot;. Depends on context which one should be used. For example:- &quot;Admin submitted a form. Student attempted a quiz.&quot; is correct, however some cases might not be as clear as the previous example. We can say both &quot;Student submitted an assignment&quot; or &quot;student attempted an assignment&quot;. We need to make the difference clear.<br /> |Moodle<br /> |-<br /> |suspended<br /> | Suspend something. (example a user)<br /> | Tincan (However the context is different)<br /> |-<br /> |switched<br /> |Something has been switched. For example:- The workshop phase has been switched to assessment&quot;<br /> |Moodle<br /> |-<br /> |unassigned<br /> |As opposed to assigned. When some role is unassigned.<br /> |Moodle<br /> |-<br /> |unlocked<br /> |<br /> |Moodle<br /> |-<br /> |upgraded<br /> |Something was upgraded, some module probably<br /> |Moodle<br /> |-<br /> |updated<br /> |Used to indicate the object in context was updated. Simple example is &quot;Admin updated course xyz&quot;.<br /> |Moodle<br /> |-<br /> |uploaded<br /> |When an assignment is uploaded.<br /> |Moodle<br /> |-<br /> |viewed<br /> |Something has been viewed. For example:- &quot;Student viewed chapter 1 of book 1.&quot;<br /> |Moodle<br /> |-<br /> |}<br /> <br /> === Rules ===<br /> <br /> ==== Use singular ====<br /> <br /> Plurals must be used on objects when it's a ''One to Many'' relationship. Ex: bulk import, mass deletion, ... In any other case, use the singular.<br /> <br /> ==== Ends with a verb ====<br /> <br /> The last word (after the last underscore) must be a verb.<br /> <br /> === Deprecated events ===<br /> Following are the events that were supported in 2.5, but deprecated in 2.6 or later<br /> <br /> groups_groupings_deleted (see MDL-41312)<br /> <br /> groups_groupings_groups_removed (see MDL-41312)<br /> <br /> groups_groups_deleted (see MDL-41312)<br /> <br /> groups_members_removed (see MDL-41312)<br /> <br /> == Shared events ==<br /> <br /> Decision: Not supported at this stage.<br /> <br /> In Moodle 2.5 we have a good example of a shared event: 'assessable_content_uploaded' which is triggered in ''forum'', 'assignment'' and ''workshop''.<br /> <br /> The problem with shared events is that we cannot easily track what component triggered them. Of course we could add a new property to the event to keep track of that, but we would soon need more information and more properties. Also, in the case of a logger, the event received would be unique, where in fact it should be considered different depending on the component firing it.<br /> <br /> In our first implementation, we will create one specific event per module. This flexibility does not prevent any observer from capturing them, but still makes sure that the consistency and specificity of each event is maintained.<br /> <br /> It could happen that some events are defined in core and shared, but this should not really happen as low-level APIs should trigger the event, and a module should call that low API instead of doing the job itself.<br /> <br /> == One to many ==<br /> <br /> Decision: Each event should have a one to one relationship. We can reconsider this at a later stage, if the performance hit is extremely high.<br /> <br /> In 2.5, some events are triggered when an action happens on multiple objects. We have to decide whether we want to keep supporting ''One to Many'' events or not.<br /> <br /> Keeping a list of all changes for multiple actions may be problematic because you would have to keep them all in memory until all things are processed. This might also result in the order of events being incorrect. The only correct solution seems to be to trigger each item individually and then many things at the end. Performance needs to be improved elsewhere...<br /> <br /> === Accuracy ===<br /> <br /> When uploading a bunch of users using the CSV upload feature, if only one event is triggered, it means that the observers of ''user_created'' won't be triggered. And so some functionality can be lost as, as a plugin developer, I expect this ''user_created'' to be triggered regardless of the way they have been uploaded. Of course, the developer could observe the event ''bulk_user_imported'', but that means that he could miss some relevant observers.<br /> <br /> This applies to existing events.<br /> <br /> === Performance ===<br /> <br /> Triggering one event is cheaper then repeating the same events x number of times...<br /> <br /> === Information tracking ===<br /> <br /> A ''bulk'' event, might not be verbose enough to allow for proper logging afterwards. Though this is the responsibility of the logger, we probably want to make it easy to store relevant information.<br /> <br /> === Double event ===<br /> <br /> In the case of a bulk user import, if we were to trigger an event per user created, we probably want to trigger one event 'user_bulk_upload_started' when the action starts.<br /> <br /> == Unit Testing ==<br /> <br /> With unit testing for this system we want to assert the following:<br /> <br /> * That event strict validation and custom validation works.<br /> * Missing event data is auto filled with accurate data.<br /> * Typos in properties passed to ::create() are captured (if we decide to validate).<br /> * The legacy methods return the expected values (use assertEventLegacyData() and assertEventLegacyData())<br /> * The class properties are correctly overridden (crud, level, action, object, ...).<br /> * The properties automatically generated (component, name, ...) are correct.<br /> * Events are dispatched to the corresponding observers.<br /> * Events are dispatched to the corresponding legacy handlers.<br /> * Events are dispatched to the * observers.<br /> * Events perform an add_to_log() if it has legacy log data.<br /> * 'Events restore' restored the whole event data, and does not miss any information.<br /> * 'Events restore' does not generate any extra information.<br /> * Event methods should check context object or avoid using it, as context might not be valid at time of event restore (use assertEventContextNotUsed())<br /> <br /> = PHP dpcs ==<br /> * All events php docs must include @since parameter, indicating when the event was first included in standard Moodle distribution.<br /> * All events must declare the $other properties using mark down in the php docs.<br /> <br /> = Example events =<br /> <br /> == Assignment ==<br /> <br /> Assumption: Course contains groups with students in each group.<br /> <br /> '''1.''' Teacher creates an assignment with group mode set to 'Separate groups' and Feedback type set to comments and files.<br /> *Event: User 'Teacher' has created assignment 'B' in course 'C101'.<br /> '''2.''' A student views the assignment.<br /> *Event: User 'Student' has viewed assignment 'B' in course 'C101'.<br /> '''3.''' A member from one of the groups submits an assignment<br /> *Event: User 'Student' has added a submission for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: Email sent to the teacher and all students in that group.<br /> '''4.''' User 'Adrian' adds some changes to the assignment and updates it.<br /> *Event: User 'Adrian' has updated the submission for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: Email sent to the teacher and all students in that group.<br /> '''5.''' Teacher views the assignment.<br /> *Event: User 'Teacher' has viewed assignment 'B' in course 'C101'.<br /> '''6.''' Teacher clicks on 'View/grade all submissions'<br /> *Event: User 'Teacher' has viewed the assignment 'B' grade area in course 'C101'.<br /> '''7.''' Teacher clicks to grade the student's submission.<br /> *Event: User 'Teacher' has viewed the submission for user 'student' for assignment 'B' in course 'C101'.<br /> '''8.''' Teacher marks the assignment with the setting 'Apply grades and feedback to entire group' set to 'Yes' leaving a comment and a file.<br /> *Event: User 'Teacher' has marked assignment 'B' for group 'C' in course 'C101'.<br /> *Event: User 'Teacher' has left a comment for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: User 'Teacher' has uploaded a feedback file for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: User 'Teacher' has uploaded a file to the course 'C101'.<br /> *Event: Email sent to user 'Student' notifying them their submission for assignment 'B' has been marked. - This is done for all users in the group.<br /> '''9.''' User 'Adrian' views the feedback.<br /> *Event: User 'Adrian' has viewed assignment 'B' in course 'C101'.<br /> '''10.''' User 'Adrian' opens the feedback file.<br /> *Event: User 'Adrian' has viewed the file 'A' for assignment 'B' in course 'C101'.<br /> '''11.''' User 'Adrian' adds some changes to the assignment insulting the teachers marking and updates it.<br /> *Event: User 'Adrian' has updated the submission for assignment 'B' for group 'C' in course 'C101'.<br /> *Event: Email sent to user 'Teacher' notifying them that user 'Adrian' has updated the submission for assignment 'B'.<br /> *Event: Email sent to user 'Student' notifying them their submission for assignment 'B' has been updated. - This is done for all users in the group.<br /> '''12.''' The teacher clicks directly on the link in the email to be taken to the grading page.<br /> *Event: User 'Teacher' has viewed the submission for user 'student' for assignment 'B' in course 'C101'.<br /> '''13.''' The teacher is upset due to the harsh comments and decides to mark Adrian down, but not the rest of the group by setting 'Apply grades and feedback to entire group' set to 'No'.<br /> *Event: User 'Teacher' has marked assignment 'B' for user 'Adrian' in course 'C101'.<br /> *Event: User 'Teacher' has left a comment for assignment 'B' for user 'Adrian' in course 'C101'.<br /> *Event: User 'Teacher' has uploaded a feedback file for assignment 'B' for user 'Adrian' in course 'C101'.<br /> *Event: Email sent to user 'Adrian' notifying them their submission for assignment 'B' has been marked.<br /> <br /> = FAQs =<br /> <br /> ; Why not use create events in core subsystems? : Because we could not see all core events in one place, it would create problems when naming event classes and finally subsystems are incomplete, we would have to add more now because we could not move the events in the future.<br /> <br /> = Development stages =<br /> <br /> == Stage 1 ==<br /> <br /> * Finish class loader spec and implement basic Frankenstyle class loader.<br /> * Describe new observer definition - just few new flags in current db/events.php<br /> * Describe new event dispatcher.<br /> * Describe core_event_base class.<br /> * Current (= legacy) events triggering:<br /> ** Re-factor current event handling code to new self-contained class - do not change functionality, keep events_trigger().<br /> ** Create new event handler management class that deals with installation and upgrades of both legacy and new handlers.<br /> * New events:<br /> ** Create new core_event_base class.<br /> ** Create new self-contained event dispatcher class with '*' handler support.<br /> ** In function core_event_base::trigger() check if the event has property 'legacyeventname' execute events_trigger($this-&gt;legacyeventname, $this-&gt;legacyeventdata) after triggering new event.<br /> ** Write unit tests for all new events code.<br /> * No changes to be made to the current logging system yet.<br /> <br /> After completing this stage everything should continue to work as it did before and we can start parallel work on further stages.<br /> <br /> == Stage 2 (requires completion of Stage 1) ==<br /> <br /> * Create event classes and replace existing calls to events_trigger() and with new event classes containing legacy information properties.<br /> * Add more events throughout the standard Moodle package in places where we have add_to_log(). Implement some_event::get_legacy_log_data() which returns original parameters of add_to_log() and remove it. Old add_to_log() function is called in core_event_base::trigger() automatically with original parameters.<br /> * Add even more new events all over the place.<br /> <br /> The difficult part is defining the new event classes properly because we must not change them after the 2.6 release.<br /> <br /> == Stage 3 (requires partial completion of Stage 2) ==<br /> <br /> * Migrate current legacy event handlers to new handlers with one event class instance parameter, ex.: enrol plugins.<br /> <br /> == Stage 4 (requires partial completion of Stage 2) ==<br /> <br /> * Implement an event logging handler.<br /> * Implement logging storage plugins.<br /> * Define logging apis.<br /> * Create new reports.<br /> * Switch to new logging everywhere after Stage 2 has been completed and new reports are usable.<br /> <br /> See [[Logging 2]]<br /> <br /> == Stage 5 ==<br /> <br /> * Decide how much backwards compatibility we want for old log tables. Most probably they will get only legacy log data.<br /> * Implement some BC solution for old code that reads log tables directly.<br /> <br /> See [[Logging 2]]<br /> <br /> == Stage 6 (requires completion of Stage 4 and 5) ==<br /> <br /> Moodle 2.8dev? This is the ultimate end of old logging via the ''log'' table.<br /> <br /> * Deprecate the add_to_log() function with a debug message and do nothing inside.<br /> * Remove all legacy logging from event classes.<br /> <br /> See [[Logging 2]]<br /> <br /> = See Also =<br /> [[Logging 2]] <br /> <br /> [[Tin Can]]</div>

Ankitfrenz https://docs.moodle.org/dev/index.php?title=Reports&diff=44520 2014-04-24T08:06:58Z

<p>Ankitfrenz: /* report_myreport_supports_logstore */</p> <hr /> <div>{{Moodle 2.2}}<br /> <br /> In Moodle 2.2 the [[Course reports]] and [[Admin reports]] were combined into one Reports directory (/report) that serves both needs.<br /> <br /> <br /> ==Overview==<br /> <br /> A report is a folder of code under /report. For example, you might make a folder in there called '''myreport'''.<br /> <br /> In there, the only code you are required to have is an index.php file. This will normally display a simple HTML form for controlling the report, and, the code for displaying the report. You will probably also want a language file, which would be called lang/en/report_myreport.php following the example above. <br /> <br /> In addition, you can add any other PHP code you like, and then link people to it from index.php.<br /> <br /> So, the minimal code layout is:<br /> <br /> report/<br /> backups/<br /> completion/<br /> ...<br /> myreport/<br /> lang/<br /> en/<br /> report_myreport.php<br /> index.php<br /> version.php<br /> ...<br /> <br /> ==What to do in index.php==<br /> <br /> The simplest way to work this out is by example. You should look at some of the reports that ship with Moodle. [https://github.com/moodle/moodle/blob/master/report/configlog/index.php report/log] is a good one to start with. Let us go through that example to see what is there (I will put into italics the bits that are more advanced):<br /> <br /> # Require some libraries.<br /> # Check the user is logged in and has appropriate permissions - all external admin pages use admin_externalpage_setup() which by default requires 'moodle/site:config' capability<br /> # Get the parameters from the URL that control the report, and clean them up a bit.<br /> # Print the page header. Since this is an administration page, we need to do this using the admin_externalpage... functions. <br /> # Display a table with data and paging controls<br /> # Print the footer<br /> <br /> ==How your report gets included in the navigation ==<br /> <br /> Reports can present itself in different contexts:<br /> * system level - controlled by settings.php<br /> * at user level - controlled by *_extend_navigation_user() callbacks<br /> * at course level - controlled by *_extend_navigation_course() callbacks<br /> * at module level - controlled by *_extend_navigation_module() callbacks<br /> <br /> In our example the configlog report is usable only at the system level, the admin tree integration is done through settings.php file<br /> &lt;code php&gt;<br /> $ADMIN-&gt;add('reports', new admin_externalpage('reportconfiglog', get_string('configlog', 'report_configlog'), &quot;$CFG-&gt;wwwroot/report/configlog/index.php&quot;));<br /> $settings = null;<br /> &lt;/code&gt;<br /> The &lt;code&gt;$settings = null&lt;/code&gt; tells moodle that plugin does not have any settings and only want to display link to external admin page.<br /> <br /> If you want to include your report in course navigation for example you need to create lib.php file and add following function:<br /> <br /> &lt;code php&gt;<br /> function report_myreport_extend_navigation_course($navigation, $course, $context) {<br /> if (has_capability('report/myreport:view', $context)) {<br /> $url = new moodle_url('/report/myreport/index.php', array('id'=&gt;$course-&gt;id));<br /> $navigation-&gt;add(get_string('pluginname', 'report_myreport'), $url, navigation_node::TYPE_SETTING, null, null, new pix_icon('i/report', ''));<br /> }<br /> }<br /> &lt;/code&gt;<br /> <br /> You will also need access.php file with definition of 'report/myreport:view' capability.<br /> <br /> == Callbacks ==<br /> This section includes the callbacks that a report should define. callbacks are normally defined in lib.php of the report.<br /> <br /> === report_myreport_supports_logstore ===<br /> {{Moodle 2.7}}<br /> <br /> You need to define this callback only if your report uses logstores to fetch information. This function takes a store instance as an argument and returns boolean true/false depending on if your report supports this store or not. This callback is used in various managment interfaces to let admins know the dependencies of your report on logstores.<br /> <br /> See [[Migrating log access in reports]] for further details on how to use logstores in reports.<br /> Example:-<br /> &lt;code php&gt;<br /> <br /> /**<br /> * Callback to verify if the given instance of store is supported by this report or not.<br /> *<br /> * @param string $instance store instance.<br /> *<br /> * @return bool returns true if the store is supported by the report, false otherwise.<br /> */<br /> function report_myreport_supports_logstore($instance) {<br /> if ($instance instanceof \core\log\sql_select_reader) {<br /> return true;<br /> }<br /> return false;<br /> }<br /> &lt;/code&gt;<br /> <br /> ==Strings you must define in you lang/en/report_''myreport''.php==<br /> <br /> You just need to define<br /> &lt;code php&gt;<br /> $string['pluginname'] = 'What my report is called';<br /> &lt;/code&gt;<br /> <br /> to make the report show up properly in the admin tree, but if your report does anything interesting, you will almost certainly need more.<br /> <br /> ==See also==<br /> <br /> * [http://moodle.org/mod/data/view.php?d=13&amp;rid=913 System images report] this is another very simple report, in contrib. Might be a good one to look at.<br /> * [[General report plugins]] - new reports in 2.2+<br /> <br /> <br /> [[Category:Plugins]]</div>

Ankitfrenz