MoodleDocs - User contributions [en]

Running acceptance test

2022-06-22T00:13:23Z

Mwithheld: /* Troubleshooting */ Add note about This is not a behat test site

Moodle uses [https://behat.org Behat], a php framework for automated functional testing, as part of a suite of testing tools.

Behat takes a set of Features, Scenarios, and Steps, and uses these to step through actions and test results using a real web browser. This is possible thanks to a protocol implemented in most modern web browsers called Webdriver.

This documentation covers how to run Behat tests within Moodle, including requirements, setup, useful tips and tricks, and basic troubleshooting.
== Requirements ==
# Any recent OS with [[Releases|supported version of Moodle]] installed
# A recent browser (We support Firefox, Chrome as standard, but other browsers are possible)
# The WebDriver implementation for your browser
# A recent version of Selenium (Optional, but recommended)
# A recent Java Runtime Environment (Required if using Selenium)
=== Recommended extras ===
Some extra software is also recommended for testing with Behat.
==== Pre-configured browser profiles: moodle-browser-config ====
Available for [[Releases|all supported versions of Moodle]], the [https://github.com/andrewnicols/moodle-browser-config moodle-browser-config] is a recommended inclusion for Behat. This configuration tooling provides a range of standard browser profiles for testing.

Note: In future, the <tt>moodle-browser-config</tt> tool may be included as composer dependency to Moodle but this is currently not the case.
===== Installation =====
# Check out the moodle-browser-config repository:
// Change directory to your git root, for example:
$ cd ~/git
// Clone the moodle-browser-config repository
git clone https://github.com/andrewnicols/moodle-browser-config
# Open your Moodle installation's <tt>config.php</tt> in your preferred editor, and require the tool's init.php:
require_once('/path/to/your/git/dir/moodle-browser-config/init.php');
===== Provided profiles =====
The full list of profiles which are included with <tt>moodle-browser-config</tt> are provided in its [https://github.com/andrewnicols/moodle-browser-config own documentation].

The following is a summary of the profiles that most users may be interested in.

You can also provide your own custom profiles, including for remote services such as Browserstack, and Saucelabs, as
well as for other browsers supporting the W3C Webdriver specification.

Please note that <tt>Safari</tt> and <tt>Safaridriver</tt> are not currently supported as they do not meet the W3C WebDriver specification.
{| class="wikitable" border="1"
|-
! Profile name
! Description
! Uses Selenium?
! Displays GUI?
|-
| firefox
| Use Firefox via Selenium
| Yes
| Yes
|-
| headlessfirefox
| Use Firefox via Selenium, without displaying the GUI
| Yes
| No
|-
| geckodriver
| Use Firefox with Geckodriver directly
| No
| Yes
|-
| headlessgeckodriver
| Use Firefox with Geckodriver directly, without displaying the GUI
| No
| No
|-
| chrome
| Use Chrome via Selenium
| Yes
| Yes
|-
| headlesschrome
| Use Chrome via Selenium, without displaying the GUI
| Yes
| No
|-
| chromedriver
| Use Chrome with Chromedriver directly
| No
| Yes
|-
| headlesschromedriver
| Use Chrome with Chromedriver directly, without displaying the GUI
| No
| No
|-
| edge
| Use Edge via Selenium
| Yes
| Yes
|-
| headlessedge
| Use Edge via Selenium, without displaying the GUI
| Yes
| No
|-
| edgedriver
| Use Edge with Edgedriver directly
| No
| Yes
|-
| headlessedgedriver
| Use Edge with Edgedriver directly, without displaying the GUI
| No
| No
|}
==== chromedriver-wrapper ====
When using Google Chrome, you must use the correct version of the <tt>chromedriver</tt> browser driver for the version of Chrome that you use.

Since Google Chrome automatically updates on a regular basis, you will need to regularly upgrade your driver to match the version of Chrome that you are using.

To make this easier, a <tt>chromedriver-wrapper</tt> utility has been written. This inspects the version of Chrome that is in your path, and downloads the correct version of <tt>chromedriver</tt> for that version, before starting it.

Installation instructinos can be found at [https://github.com/andrewnicols/chromedriver-wrapper https://github.com/andrewnicols/chromedriver-wrapper].
== Getting started (basic) ==
This is a quick walk through to get Behat running for the first time.
=== Setting up ===
There are a number of ways of configuring Behat on Moodle. This is one of the simplest.

These notes assume that you have already installed a supported Java Runtime Environment, and the [[Running_acceptance_test#Pre-configured_browser_profiles:_moodle-browser-config]] tool.
==== Setting up Selenium ====
Generally we recommend use of Selenium, though this is not a fixed requirement. You can use the browser's driver implementation directly but this is harder to setup for the first time.

Selenium is written in Java, and requires a recent version of the JRE to run. Please ensure that you have this installed prior to starting.

Since Moodle 3.9.5 / 3.10.2 / 3.11.0 Moodle will work with any modern version of Selenium. At time of writing that is <tt>3.141.59</tt>, and 4.1.0. '''Note:''' There appears to be an issue with the version 4 jars - particually in 4.1.0 that generates a '''"Could not open connection: Capability value must be set”''' error which appears to be an issue between Selenium and the MInkExtension for JavaScript tests - see https://githubmemory.com/repo/Behat/MinkExtension/activity for more information. The quick work around is to use the earlier version (3.141.59).
# Download the Selenium Server (Grid) from [https://www.selenium.dev/downloads/ https://www.selenium.dev/downloads/]. This is a single JAR file, put it anywhere handy.
# Start Selenium
# Version 3.141.59:
$ java -jar selenium-server-standalone-3.141.59.jar

# Version 4.0.0 and later:
$ java -jar selenium-server-4.0.0-beta-3.jar standalone
You can optionally specify a number of settings, depending on the version of Selenium that you are using, including the port to run on.
See the help for the version of Selenium that you are using.
==== Setting up your browsers ====
Selenium is just an intelligient wrapper to start, and manage your browser sessions. It doesn't actually include any web browsers itself.

Moodle HQ run all behat tests against both Firefox and Chrome multiple times per day. Other combinations, including Microsoft Edge, are also supported.

To use Behat, you will need a recent version of your preferred browser, as well as a <tt>driver</tt> for that browser. The driver is responsible for communication between Selenium (or Moodle directly) and the browser.

Both the browser, and its driver, must be placed inside your <tt>$PATH</tt> - this may be somewhere like <tt>/usr/bin</tt>, <tt>/usr/local/bin</tt>, or perhaps a user bin directory like <tt>~/bin</tt> which is present in your <tt>$PATH</tt>
===== Chrome =====
You can download Google Chrome from [https://www.google.com.au/chrome https://www.google.com.au/chrome].

You will need the [https://chromedriver.chromium.org/downloads correct version of the chromedriver] as per the
documentation. Alternatively you can make use of the [[Running_acceptance_test#chromedriver-wrapper|chromedriver-wrapper utility]] noted in the Recommended extras sections.

Either the <tt>chromedriver</tt> binary must be in a directory in your <tt>$PATH</tt>, or the <tt>chromedriver-wrapper/bin</tt> folder must be in your <tt>$PATH</tt>.
===== Firefox =====
You can download Mozilla Firefox from [https://www.mozilla.org/en-US/firefox/new/ https://www.mozilla.org/en-US/firefox/new/].

You will need the [https://github.com/mozilla/geckodriver/releases correct version of geckodriver] as per the [https://firefox-source-docs.mozilla.org/testing/geckodriver/Support.html documentation].

The <tt>geckodriver</tt> binary must be in a directory in your <tt>$PATH</tt>.
==== Set up Moodle ====
# Create a new 'dataroot' area for files especially for behat
# Set the following in your Moodle <tt>config.php</tt>:
$CFG->behat_dataroot = '/path/to/the/dataroot/you/created';
$CFG->behat_wwwroot = 'http://127.0.0.1/path/to/your/site';
$CFG->behat_prefix = 'beh_';
# We recommend that you also include the <tt>behat-browser-config</tt> if you have not done so already.
require_once('/path/to/moodle-browser-config/init.php');
===== Notes about the behat_wwwroot =====
You will need to set the <tt>behat_wwwroot</tt> to your Moodle site, but it ''must'' use a different value to your <tt>$CFG->wwwroot</tt>.

One common way to do this is to use <tt>127.0.0.1</tt> for behat, but <tt>localhost</tt> for standard use. Alternatively you can add an additional hostname in your <tt>/etc/hosts</tt> file and use this instead.

If you use Docker, then you may be able to use <tt>host.docker.internal</tt> where your site is hosted on the docker host
==== Configure Behat for Moodle ====
After setting your configuration, you can simply initialise behat:
$ php admin/tool/behat/cli/init.php
This will install all required Composer dependencies, install a new Moodle site, and put configuration in place

When it finishes it will give advice on how to run Behat.
==== Run Behat tests ====
Before running behat, ensure that your Selenium server is running.

The easiest way to run behat, and test that everything works is by simply running it using the command provided when you
initialised Behat. If you didn't make a note of it, you can just run the initialisation again.
$ php admin/tool/behat/cli/init.php
This will give you a command which you can then run. This command will run every behat scenario, which will take a considerable amount of time. This command will look a bit like this:
$ vendor/bin/behat --config /Users/nicols/Sites/moodles/sm/moodledata_behat/behatrun/behat/behat.yml
To make this more useful you an combine it with flags, for example to only run certain <tt>tags</tt> or for a specific Behat Feature file, or Scenario.

To run all features/scenarios which are tagged with <tt>mod_forum</tt>:
$ vendor/bin/behat --config /Users/nicols/Sites/moodles/sm/moodledata_behat/behatrun/behat/behat.yml --tags=@mod_forum
To run one specific feature file:
$ vendor/bin/behat --config /Users/nicols/Sites/moodles/sm/moodledata_behat/behatrun/behat/behat.yml `pwd`/mod/forum/tests/behat/private_replies.feature
To run one specific scenario within a feature file:
# To run the Scenario on line 38 of the file:
$ vendor/bin/behat --config /Users/nicols/Sites/moodles/sm/moodledata_behat/behatrun/behat/behat.yml `pwd`/mod/forum/tests/behat/private_replies.feature:38
To run one specific scenario by name:
$ vendor/bin/behat --config /Users/nicols/Sites/moodles/sm/moodledata_behat/behatrun/behat/behat.yml --name="As a teacher I can see my own response"
See the upstream documentation on Behat, and Gherkin filters for more information.
===== Running using a different browser =====
The default browser in Behat is <tt>Firefox</tt>. To specify a different browser profile, you can add the <tt>--profile</tt> argument. For example, to use Chrome in Headless mode:
$ vendor/bin/behat --config /Users/nicols/Sites/moodles/sm/moodledata_behat/behatrun/behat/behat.yml --profile=headlesschrome
If you are using the <tt>moodle-browser-config</tt> utility, then you can use any profile listed in [[Running_acceptance_test#Pre-configured_browser_profiles:_moodle-browser-config|moodle-browser-config]]. Otherwise you can write your own browser profile configuration.
=== Advanced testing ===
==== Run tests without Selenium (chromedriver, geckodriver) ====
Historically, Behat required Selenium server, however browsers now make use of their own automation layer. For example, Firefox uses <tt>Geckodriver</tt> and Chrome uses <tt>Chromedriver</tt>. As a result the use of Selenium itself is now optional.

The moodle-browser-config tool includes standard profiles to use these drivers directly and without the use of Selenium.

To use the drivers directly, you must run the driver itself, for example to run <tt>chromedriver</tt>:
$ chromedriver
To run <tt>geckodriver</tt>:
$ geckodriver
Note: geckodriver runs on port 4444 by default. You cannot geckodriver at the same time as selenium.

After starting your preferred browser, you can then run behat and specify an alternative profile, for example:
$ vendor/bin/behat --config /Users/nicols/Sites/moodles/sm/moodledata_behat/behatrun/behat/behat.yml --profile=geckodriver
==== Headless browsers ====
There are a number of reasons that you may prefer to use a headless browser. It can be particularly helpful if you are running the tests on a remote system, for example over SSH, or if you do not want to be interrupted by browsers popping up on your machine.

The following headless profiles are some of those provided in the moodle-browser-config tool as standard:
# <tt>headlessfirefox</tt> Use Firefox via Selenium, without displaying the GUI
# <tt>headlessgeckodriver</tt> Use Firefox with Geckodriver directly, without displaying the GUI
# <tt>headlesschrome</tt> Use Chrome via Selenium, without displaying the GUI
# <tt>headlesschromedriver</tt> Use Chrome with Chromedriver directly, without displaying the GUI
These can be provided to the <tt>--profile</tt> argument to behat:
$ vendor/bin/behat --config /Users/nicols/Sites/moodles/sm/moodledata_behat/behatrun/behat/behat.yml --profile=headlesschrome
==== Parallel runs ====
Out-of-the-box, Moodle will configure Behat to run a single Moodle installation with all tests run in series. This is great for developer use where you are running a single test. or a small suite of tests. However this can be quite slow. A lot of time is spent waiting in Behat for things to happen. This may be for a page to load, for additional content to load, or even explicit waits because some interactions must be deliberately slowed down. As a result, a system running behat will not have a particularly high load most of the time.

If you want to run a large suite of tests then it is possible to take advantage of the relatively low resource consumption by running several behat runners in parallel. This is commonly referred to as a '''Parallel run'''.

A parallel run of behat takes the same codebase and creates several installations rather than just a single Moodle installation. The behat Feature files are then grouped and allocated between each of the separate installations.

To support this, each of the parallels runs needs its own:
* <tt>behat_wwwroot</tt>
* <tt>behat_dataroot</tt>
* database
Rather than using an entirely separate database, the same database is actually used, but a different <tt>behat_prefix</tt> is used to prefix the table names in the database differently.
===== Installation =====
The Behat initialisation command is responsible for preparing Moodle to run a standard run. You'll have used this before when installing for a standard run:
$ php admin/tool/behat/cli/init.php
The same command can be used to prepare Moodle for a parallel run by specifying the <tt>--parallel</tt> or <tt>-j</tt> parameter:
// Below command will initialise moodle to run 3 parallel tests.
$ php admin/tool/behat/cli/init.php --parallel=3
This can be combined with the <tt>--add-core-features-to-theme</tt> or <tt>-a</tt> flag to prepare Behat to run with all installed themes.

A number of advanced options are also available but you are unlikely to need these:
# <tt>-m=<number></tt> or <tt>--maxruns=<number></tt> Max parallel site which should be initialised at one time. If your system is slow, then you can initialise sites in chucks.
# <tt>--fromrun=<number></tt> Initialise site to run specified run from. Used for running acceptance tests on different vms
# <tt>--torun=<number></tt> Initialise site to run specified run till. Used for running acceptance tests on different vms
# <tt>-o</tt> or <tt>--optimize-runs</tt> This option will split features with specified tags in all parallel runs, so they are executed first when parallel run gets executed.
You can view details of all of these using the <tt>--help</tt> flag to <tt>admin/tool/behat/cli/init.php</tt>
===== Running Parallel tests =====
You can use the Moodle behat runner to run all tests, including Standard runs. It is an intelligient wrapper around the standard <tt>./vendor/bin/behat</tt> command which specifies the configuration file, and other required features.
$ php admin/tool/behat/cli/run.php
Many of the standard options and parameters that can be passed to <tt>./vendor/bin/behat</tt> can also be passed to the Moodle runner, for example:
# <tt>--tags</tt> Run tests which match the specified tags
# <tt>--name="Scenario name"</tt> Run a test matching the supplied scenario name
# <tt>--feature="/path/to/test.feature"</tt> Run a specific feature file.
# <tt>--suite</tt> Features for specified theme will be executed.
The runner also includes a number of custom parameters relating to parallel runs:
# <tt>--replace</tt> Replace args string with run process number, useful for output and reruns.
# <tt>--fromrun</tt> Execute run starting from (Used for parallel runs on different vms)
# <tt>--torun</tt> Execute run till (Used for parallel runs on different vms)
The <tt>--replace</tt> feature is particularly useful and can be used to replace a string in the command with the run number. This is useful when specifying output formats, and rerun files as noted below.

The following example demonstrates how Behat might be initialised with three parallel runs, to run on all themes:
$ php admin/tool/behat/cli/init.php --parallel=3 --add-core-features-to-theme
And then to run all tests matching the <tt>@tool_myplugin</tt> tag, against the <tt>classic</tt> theme:
$ php admin/tool/behat/cli/run.php --tags="@tool_myplugin" --suite="classic"
===== Custom parameters for parallel runs =====
You can set following custom config options for parallel runs via $CFG->behat_parallel_run. It's an array of options where 1st array is for 1st run and so on.
$CFG->behat_parallel_run = [
[
'dbtype' => 'mysqli',
'dblibrary' => 'native',
'dbhost' => 'localhost',
'dbname' => 'moodletest',
'dbuser' => 'moodle',
'dbpass' => 'moodle',
'behat_prefix' => 'mdl_',
'wd_host' => 'http://127.0.0.1:4444/wd/hub',
'behat_wwwroot' => 'http://127.0.0.1/moodle',
'behat_dataroot' => '/home/example/bht_moodledata'
],
// ...
],
To set different selenium servers for parallel runs, you can use following. NOTE: Running parallel (headless) runs on different selenium servers avoid random focus failures.
$CFG->behat_parallel_run = [
['wd_host' => 'http://127.0.0.1:4444/wd/hub'],
['wd_host' => 'http://127.0.0.1:4445/wd/hub'],
['wd_host' => 'http://127.0.0.1:4446/wd/hub'],
];
==== Tests filters ====
With the <tt>--tags</tt> or the <tt>-name</tt> Behat options you can filter which tests are going to run or which ones are going to be skipped. There are a few tags that you might be interested in:
* <tt>@javascript</tt>: All the tests that runs in a browser using Javascript; they require Selenium or the browser's own automation layer, as per [[Running acceptance test#Run%20tests%20without%20Selenium%20.28chromedriver.2C%20geckodriver.29|Running acceptance test#Run tests without Selenium .28chromedriver.2C geckodriver.29,]] to be running, otherwise an exception will be thrown.
* <tt>@_file_upload</tt>: All the tests that involves file uploading or any OS feature that is not 100% part of the browser. They should only be executed when Selenium is running in the same machine where the tests are running.
* <tt>@_alert</tt>: All the tests that involves Javascript dialogs (alerts, confirms...) are using a feature that is OS-dependant and out of the browser scope, so they should be tag appropriately as not all browsers manage them properly.
* <tt>@_switch_window</tt>: All the tests that are using the <tt>I switch to "NAME" window</tt> step should be tagged as not all browsers manage them properly.
* <tt>@_switch_iframe</tt>: All the tests that are using the <tt>I switch to "NAME" iframe</tt> steps should be tagged as it is an advanced feature and some browsers may have problems dealing with them
* <tt>@_cross_browser</tt>: All the tests that should run against multiple combinations of browsers + OS in a regular basis. The features that are sensitive to different combinations of OS and browsers should be tagges as @_cross_browser.
* <tt>@componentname</tt>: Moodle features uses the [https://docs.moodle.org/dev/Frankenstyle Frankenstyle] component name to tag the features according to the Moodle subsystem they belong to.
==== Output formats ====
Behat is able to output in a number of different formats, and to different locations as required.

This can be achieved by specifying the <tt>--format</tt>, and <tt>--out</tt> parameters when running behat, for example:
// Run behat, using the 'pretty' format and outputting the value to /tmp/pretty.txt
$ vendor/bin/behat --config /Users/nicols/Sites/moodles/sm/moodledata_behat/behatrun/behat/behat.yml \
--format=pretty --out=/tmp/pretty.txt
It is also possible to output to multiple formats simultaneously by repeating the arguments, for example:

Since Moodle 3.1 option for output is:
$ vendor/bin/behat --config /Users/nicols/Sites/moodles/sm/moodledata_behat/behatrun/behat/behat.yml \
--format=pretty --out=/tmp/pretty.txt \
--format=moodle_progress --out=std
The following output formats are supported:
# <tt>progress</tt>: Prints one character per step.
# <tt>pretty</tt>: Prints the feature as is.
# <tt>junit</tt>: Outputs the failures in JUnit compatible files.
# <tt>moodle_progress</tt>: Prints Moodle branch information and dots for each step.
# <tt>moodle_list</tt>: List all scenarios.
# <tt>moodle_stepcount</tt>: List all features with total steps in each feature file. Used for parallel run.
# <tt>moodle_screenshot</tt>: Take screenshot and core dump of each step. With following options you can dump either or both.
## <tt>--format-settings '{"formats": "image"}'</tt>: will dump image only
## <tt>--format-settings '{"formats": "html"}'</tt>: will dump html only.
## <tt>--format-settings '{"formats": "html,image"}'</tt>: will dump both.
## <tt>--format-settings '{"formats": "html", "dir_permissions": "0777"}'</tt>
Note: If you want to see the failures immediately (rather than waiting ~3 hours for all the tests to finish) then either use the -v option to output a bit more information, or change the output format using --format. Format 'pretty' ('''-f pretty''') is sufficient for most cases, as it outputs each step outcomes in the command line making easier to see the progress.

When working with parallel runs, you may wish to have an output for each run. If you were to specify a standard path for this then each of the parallel runs would overwrite the others file. The <tt>--replace</tt> option allows this to be handled:
$ admin/tool/behat/cli/run.php \
--replace="{runprocess}" \
--format=pretty --out=/tmp/pretty_{runprocess}.txt \
--format=moodle_progress --out=std
In this example, the <tt>--replace</tt> argument is provided with a value of <tt>{runprocess}</tt>. Anywhere that <tt>{runprocess}</tt> appears in the command it will be replaced with the run number. The above command will generate a set of commands like:
$ vendor/bin/behat --config /Users/nicols/Sites/moodles/sm/moodledata_behat/behatrun1/behat/behat.yml \
--format=pretty --out=/tmp/pretty_1.txt \
--format=moodle_progress --out=std

$ vendor/bin/behat --config /Users/nicols/Sites/moodles/sm/moodledata_behat/behatrun2/behat/behat.yml \
--format=pretty --out=/tmp/pretty_2.txt \
--format=moodle_progress --out=std

$ vendor/bin/behat --config /Users/nicols/Sites/moodles/sm/moodledata_behat/behatrun3/behat/behat.yml \
--format=pretty --out=/tmp/pretty_3.txt \
--format=moodle_progress --out=std
==== Rerun failed scenarios ====
With slow systems or parallel run you may experience see some random failures. These may happen when your system is too slow, when it is too fast, or where a page depends on external dependencies.

To help with this it is possible to rerun any failed scenarios using the <tt>--rerun</tt> option to Behat.

The following example runs Behat with the rerun option:
$ vendor/bin/behat --config /Users/nicols/Sites/moodles/sm/moodledata_behat/behatrun/behat/behat.yml \
--format=pretty --out=/tmp/pretty.txt \
--format=moodle_progress --out=std \
--rerun
If any single test fails then the command will return a non-zero exit code. Running the same command again will mean that only failed scenarios are run.

For a parallel run it can be called as follows:
$ admin/tool/behat/cli/run.php \
--replace="{runprocess}" \
--format=pretty --out=/tmp/pretty_{runprocess}.txt \
--format=moodle_progress --out=std \
--rerun
The Moodle behat runner also includes an <tt>--auto-rerun</tt> option which will automatically rerun failed scenarios exactly once.
==== Running behat with specified theme ====
Behat can be run with any installed theme, but it must be initialised with the <tt>-a</tt> or <tt>--add-core-features-to-theme</tt> option first.

After configuring the theme can be specified using the <tt>--suite</tt> parameter.

Note: The default theme in Moodle (boost) has the suite name <tt>default</tt>.
// Initialise Behat for all themes:
$ php admin/tool/behat/cli/init.php --add-core-features-to-theme

// Run Behat against all initalised themes:
$ vendor/bin/behat --config /Users/nicols/Sites/moodles/sm/moodledata_behat/behatrun/behat/behat.yml

// Run Behat against just the default theme when all themes were initialised:
$ vendor/bin/behat --config /Users/nicols/Sites/moodles/sm/moodledata_behat/behatrun/behat/behat.yml --suite=default

// Run Behat against just the 'classic' theme when all themes were initialised:
$ vendor/bin/behat --config /Users/nicols/Sites/moodles/sm/moodledata_behat/behatrun/behat/behat.yml --suite=classic
==== Using Docker to start selenium server ====
There are a wide range of docker images available which contain a browser with Selenium. You will probably be using the official SeleniumHQ images unless you have a specific reason not to.

The complete list of available SeleniumHQ images is available at [https://hub.docker.com/u/selenium/ https://hub.docker.com/u/selenium/].

Moodle uses the ''standalone'' version and any recent version with version 3.141.59 or higher is supported.

For any test which uploads files, for example when interacting with the filepicker, you must also ensure that the Moodle directory is mounted as on your local filesystem.

An example usage is:
$ docker run -d -p 4444:4444 -v `pwd`:`pwd` selenium/standalone-firefox:latest
==== Change config.php file ====
In the Moodle <tt>config.php</tt> file you must change the <tt>$CFG->behat_wwwroot</tt> to an address that can be reached from within the docker image.

You cannot use <tt>localhost</tt> or <tt>127.0.0.1</tt> as this will be the IP address of the docker container itself.

On some more recent versions of Docker you can use <tt>http://host.docker.internal/</tt>, for example if my site is located at <tt>/sm</tt> on my development machine, I can set the following:
$CFG->behat_wwwroot = 'http://host.docker.internal/sm';

==== Manually configuring other browsers =====
If you would prefer not to use the <tt>moodle-browser-config</tt> tool but still wish to specify different browsers then you can do so using the <tt>$CFG->behat_profiles</tt> array. Each key/value pair contains a profile name, and the configuration for that profile. For example:
$CFG->behat_profiles = [
'chrome' => [
'browser' => 'chrome',
'tags' => '@javascript',
],
];
[[Acceptance_testing/Browsers|More info about alternative browsers]]
== Troubleshooting ==
=== Increasing timeouts ===
You may see errors such as:
<syntaxhighlight lang="php">
Javascript code and/or AJAX requests are not ready after 10 seconds.
There is a Javascript error or the code is extremely slow.
</syntaxhighlight>
Sometimes this indicates a genuine problem with the code, but if you are using a slow computer, it may just mean that your browser did not finish generating parts of the UI before behat tried was finished.

If you find that this happens regularly on different scenarios then you may want to increase the timeout:
$CFG->behat_increasetimeout = 2;
This will increase all the timeouts by a factor of 2; if that isn't sufficient, you could use 3.

Increasing timeouts will make tests run a bit slower (because there are points where Behat waits up to a timeout to make sure something doesn't happen) so don't do this unless you need to.

Note: This is usually an indicator that your development machine is not well tuned. A better option would be to find out where the bottleneck is. This is usually the database configuration.

=== New step definitions or features are not executed ===
If you are adding new tests or steps definitions update the tests list
<syntaxhighlight lang="php">
php admin/tool/behat/cli/util.php --enable
</syntaxhighlight>
''' For parallel runs, all options for initialising parallel runs are valid '''
=== Tests are failing ===
If you followed all the steps and you receive an unknown weird error probably your browser version is not compatible with the Selenium version you are running. Please refer Working combinations to ensure you have correct [[Acceptance_testing/Browsers#Working_combinations_of_OS.2BBrowser.2Bselenium]] of them to run acceptance test.
=== The tests are failing, and the error message is completely useless ===
For example, it just says "Error writing to database" with no stack trace.

Add -vv command-line option to get very verbose output.
=== Errors during setup (before test are launched) ===
Typical errors are:
* Behat requirement not satisfied: http://127.0.0.1/m/stable_master is not available, ensure you specified correct url and that the server is set up and started.
* init.php or util.php complain that "Unknown error 1 This is not a behat test site!". Delete the behat wwwroot (look in config.php for $CFG->behat_dataroot) and drop the behat DB tables (look in config.php for $CFG->behat_prefix). Then try again.
* Behat is configured but not enabled on this test site.
In order to fix those errors please check that: the behat_dataroot has correct write permissions and that the $CFG->behat* variables are placed before the lib/setup.php include:
require_once(__DIR__ . '/lib/setup.php');
=== Selenium server is not running ===
==== Chrome specific ====
If you are using chrome, you need to ensure that the driver matches the version of the installed chrome browser – which may change on OS updates/upgrades. Moodle or Selenium will not give the appropriate message – see [https://tracker.moodle.org/browse/MDL-67659/ MDL-67659]. One solution is the one suggested in the issue and use Andrew Nicols’ [https://github.com/andrewnicols/chromedriver-wrapper/ Chromedriver Wrapper] which will ensure you have the appropriate driver before running the tests.

== External links ==
* Vagrant profile with Moodle and Behat preconfigured: https://github.com/mackensen/moodle-hat
* Docker containers for Moodle Developers and Behat: https://github.com/moodlehq/moodle-docker
* Docker environment with Behat preconfigured : https://github.com/tobiga/docker_moodle_environment

== Examples ==
=== Quick setup and testing using moodle-docker ===
This is a quick guide to help locally pass tests for your developments, before submitting them:
# Set up a default Moodle install using [https://github.com/moodlehq/moodle-docker moodle-docker], with the database and Moodle version of your choice. See its README for more details. This will start some docker containers.
# Initialize behat to start testing with this command, from the webserver container: <syntaxhighlight lang="php">php admin/tool/behat/cli/init.php</syntaxhighlight>
# Run the behat test of your choice, from the webserver container. For instance: <syntaxhighlight lang="php">vendor/bin/behat --config /var/www/behatdata/behatrun/behat/behat.yml --tags tool_task</syntaxhighlight>
And you'll see something like:
<syntaxhighlight lang="php">
Moodle 4.0dev (Build: 20210507), 0b47ea0a44a092f9000729ca7b15fff23111538b
Php: 7.3.26, mysqli: 5.7.21, OS: Linux 5.4.0-66-generic x86_64
Run optional tests:

Accessibility: No
Server OS "Linux", Browser: "firefox"
Started at 09-05-2021, 06:00
...................................................................... 70
...............................
12 scenarios (12 passed)
101 steps (101 passed)
2m53.27s (47.61Mb)
</syntaxhighlight>
== See also ==
* [[Acceptance testing for the mobile app]]
[[Category:Quality Assurance]][[Category:Behat]]

== Information to re-home ==
==== Override behat core context for theme suite ====
Note: This documentation needs to be rehomed to a location related to writing Behat tests.

To override behat step definitions so as to run behat with specified theme, you should create a contexts within '''/theme/{MYTHEME}/tests/behat/''' with prefix behat_theme_{MYTHEME}_ and suffixed with the context being overridden. For example, if you want to override behat_mod_forum context, then you should create a class /theme/{MYTHEME}/tests/behat/mod_forum/behat_theme_{MYTHEME}_behat_mod_forum.php
==== Disable behat context or features to run in theme suite ====
Note: This documentation needs to be rehomed to a location related to writing Behat tests.

To disable specific contexts and features from being executed by a specific theme/suite you can create a <tt>/theme/{MYTHEME}/tests/behat/blacklist.json</tt> file with following format.
<syntaxhighlight lang="php">
{
"contexts": [
"behat_grade",
"behat_navigation",
],
"features": [
"auth/tests/behat/login.feature",
"grade/tests/behat/grade_hidden_items.feature",
]
}
</syntaxhighlight>
The above will:
# disable the use of step_definitions from <tt>behat_grade</tt> and <tt>behat_navigation</tt> while running theme suite; and
# disable running of scenarios in <tt>auth/tests/behat/login.feature</tt> and <tt>grade/tests/behat/grade_hidden_items.feature</tt>.
==== Override core behat selectors ====
Note: This documentation needs to be rehomed to a location related to writing Behat tests.

To override behat selectors in specific theme, you should create a class behat_theme_{MYTHEME}_behat_selectors in /theme/{MYTHEME}/tests/behat/behat_theme_{MYTHEME}_behat_selectors.php extending behat_selectors.
==== Write new tests and behat methods ====
Note: This documentation needs to be rehomed to a location related to writing Behat tests.

If you want to write tests for your own integration, you can do so by creating new tests with format .feature. Follow instructions in [[Writing_acceptance_tests|this page]] to write new tests.

It is also possible to add new steps the moodle behat integration. In order to do so, you will have to create a new .php class with the prefix '''behat_'''. Copy the format from '''lib\behat\behat_base.php''', but set your class to extend the behat_base class instead of the MinkExtension. You can define new behat steps by declaring functions with the appropriate heading.

You will not be able to use these steps and features right away. Check [[Running_acceptance_test#New_step_definitions_or_features_are_not_executed|this section]] for instructions on how to update the behat integration.

For further information on how to create new steps definitions, check [[Acceptance testing/Custom acceptance steps]].

Grunt

2020-04-09T23:06:24Z

Mwithheld: Add link to bitbucket pipeline for YUI

{{Moodle 2.9}}

Grunt is a command line tool used to prepare our javascript and less-generated css for production usage. After making any change to javascript or less files in Moodle, you must run grunt to lint, minify and package the javascript/css properly so that it can be served by Moodle.

== Install grunt ==
The Javascript modules (AMD and YUI) and less css in Moodle must be processed by some build tools before they will be visible to your web browser. We use "[http://gruntjs.com/ grunt]" as a build tool to wrap our different processes. Grunt is a build tool written in Javascript that runs in the "[http://nodejs.org/ nodejs]" environment. This means you first have to install nodejs - and it's package manager "[https://www.npmjs.com/ npm]". The details of how to install those packages will vary by operating system, but on Linux it's likely to be:
apt-get install nodejs npm
See also: [http://askubuntu.com/questions/594656/how-to-install-the-latest-versions-of-nodejs-and-npm-for-ubuntu-14-04-lts/711976 how to install the latest version of nodejs and npm for ubuntu 14.04]

There are downloadable packages for other operating systems here: http://nodejs.org/download/.

Once this is done, cd into your Moodle directory and run the command:
npm install
to install all of the required tools.

You also need to install the grunt-cli package globally in order to have a "grunt" command in your path. To do this run:
npm install -g grunt-cli

== Running grunt ==
Typical commands:

grunt amd # Short-cut for grunt jshint uglify, rebuild all AMD modules.
grunt shifter # Run shifter
grunt js # Short-cut for grunt amd shifter

grunt css # Run less
grunt # Try to do the right thing:
# * If you are in a folder called amd, do grunt amd
# * If you are in a folder called yui/src/something, do grunt shifter
# * Otherwise build everything (grunt css js).

grunt watch # Watch for changes and re-run grunt tasks depending on what file changes
grunt eslint --show-lint-warnings # Show pedantic lint warnings for JS

On Linux/Mac it will build everything in the current folder and below. You need to cd into the amd folder of your module root, i.e. <tt>dirroot/blocks/foo/amd</tt> before running <tt>grunt amd</tt> - this will compile only your plugins AMD source files. You can make output more verbose by adding <tt>-v</tt> parameter, if used with <tt>grunt shifter</tt> this will actually show what your lint errors are. On Windows, you need to specify the path on the command line like <tt>--root=admin/tool/templatelibrary</tt>.

== Using Grunt in additional plugins ==

You may want to use Grunt for performing tasks in your custom Moodle plugins. For building AMD and YUI modules in your plugin, the standard configuration Gruntfile.js located in the Moodle root should work well. For building CSS files from LESS templates, you will have to set up a separate Grunt installation in the root of your plugin.

If you do not have it yet, create the package.json file in the root of your plugin:

{
"name": "moodle-plugintype_pluginname"
}

Install grunt, grunt less and grunt watch modules. Note that you should put the folder node_modules into your plugin's .gitignore file, too.

$ cd /path/to/your/plugin/root
$ npm install --save-dev grunt grunt-contrib-less grunt-contrib-watch grunt-load-gruntfile

Create a Gruntfile.js in the root of your plugin and configure the task for building CSS files from LESS:

<code javascript>
"use strict";

module.exports = function (grunt) {

// We need to include the core Moodle grunt file too, otherwise we can't run tasks like "amd".
require("grunt-load-gruntfile")(grunt);
grunt.loadGruntfile("../../Gruntfile.js");

// Load all grunt tasks.
grunt.loadNpmTasks("grunt-contrib-less");
grunt.loadNpmTasks("grunt-contrib-watch");
grunt.loadNpmTasks("grunt-contrib-clean");

grunt.initConfig({
watch: {
// If any .less file changes in directory "less" then run the "less" task.
files: "less/*.less",
tasks: ["less"]
},
less: {
// Production config is also available.
development: {
options: {
// Specifies directories to scan for @import directives when parsing.
// Default value is the directory of the source, which is probably what you want.
paths: ["less/"],
compress: true
},
files: {
"styles.css": "less/styles.less"
}
},
}
});
// The default task (running "grunt" in console).
grunt.registerTask("default", ["less"]);
};
</code>

Now running "grunt" or "grunt less" in your plugin root folder will compile the file less/styles.less and saves it as styles.css. Running "grunt watch" will watch the less/*.less files and if some is changed, it will immediately rebuild the CSS file.

If you are working on a custom theme, you may have multiple less/*.less files that you want to compile to their style/*.css counterparts. You can either define an explicit list all such file pairs, or let that list be created for you by making use of [http://gruntjs.com/configuring-tasks#building-the-files-object-dynamically expand:true feature] of gruntfile.js:

<code javascript>
// This dynamically creates the list of files to be processed.
files: [
{
expand: true,
cwd: "less/",
src: "*.less",
dest: "style/",
ext: ".css"
}
]
</code>

== See also ==
* [[YUI/Shifter]]
* [[Javascript Modules]]
* [[LESS]]
* [https://moodle.org/mod/forum/discuss.php?d=400229#p1614743 Bitbucket pipeline to build YUI JS]

[[Category:AJAX]]
[[Category:Javascript]]

Git for developers

2014-09-18T00:04:36Z

Mwithheld: Add external link to Tim's docs

This document is for helping you get started on Moodle development with Git. For further details of Git, see [[:Category:Git]].

== General workflow ==

'''A reasonable knowledge of the Git basics is a good idea before you start to use it for development. If you are new to Git, you are encouraged to go to 'See also' for some more general reading.'''

[[image:git-pushpull-model.png|right|thumb|400px|Moodle development workflow with Git]]
In short, the Moodle development with Git looks like this:

* You as the contributor commit changes into your personal repository at your computer
* You push the changes into your public repository and publish links to your changes in the Moodle Tracker
* You may ask for a peer review of your code from another developer (preferred but optional)
* When you are confident of your code you should submit it for integration (Integration request, also sometimes known as a pull request)
* Moodle integrators pull the changes from your public repository and if they like them, they put them into Moodle integration repository
* The integrated change is tested and finally pushed into Moodle production repository
* You update your local repository with all changes from the production repository and the next cycle may start again

This workflow runs in roughly weekly cycles. The integration happens on Monday and the testing on Tuesday. On Wednesday, the production repository moodle.git is usually updated with changes from the last development week.

Most Moodle developers have their public repositories hosted at [http://github.com/ Github]. Alternatively you may want to try [http://gitorious.org Gitorious] or the legendary [http://repo.or.cz repo.or.cz]. In the examples in this guide we assume you'll set up your public repository at Github.

If you'd like to be added to the developers group in the tracker (which allows you to assign issues to yourself), please send an email to michaeld@moodle.com with your tracker username and a link to an issue where you have contributed a patch.

== Installing Git on your computer ==

Install Git on your computer. Most Linux distributions have Git available as a package to install. If you are on Mac, [http://code.google.com/p/git-osx-installer/ git-osx-installer] installs it in a few clicks.

Immediately after the installation, set your name and contact e-mail. The name and e-mail will become part of your commits and they can't be changed later once your commits are accepted into the Moodle code. Therefore we ask contributors to use their real names written in capital letters, eg "John Smith" and not "john smith" or even "john5677".

git config --global user.name "Your Name"
git config --global user.email yourmail@domain.tld

Unless you are the repository maintainer, it is wise to set your Git to not push changes in file permissions:

git config --global core.filemode false

== Setting-up the public repository ==

1. Go to [http://github.com/ Github] and create an account.

2. Go to the [http://github.com/moodle/moodle official Moodle Github repository] and click on the Fork button. You now have your own Github Moodle repository.

3. Now you need to set up your SSH public key, so you can push to your Github Moodle repository from your local Moodle repository. On Mac you can go on this [http://help.github.com/mac-key-setup/ Github help page]. If you are on another system, go to your Github administration page, to the section SSH Public Keys, and you should see a link to a help page. Done? Good! That was the most difficult part!

== Setting-up the local repository at your computer ==

Create a local clone repository of your Github repository. In a terminal:

git clone git://github.com/YOUR_GITHUB_USERNAME/moodle.git LOCALDIR

(or: git clone git@github.com:YOUR_GITHUB_USERNAME/moodle.git LOCALDIR)

This command does several jobs for you. It creates a new folder, initializes an empty Git repository in it, sets your Github repository as the remote repository called 'origin' and makes a local checkout of the branch 'master' from it. The important point to remember now is that your Github repository is aliased as 'origin' for your local clone.

Note that the format of the URL here is important. In the first example, the URL starts "git://github.com" and this will give read-only access to the repository at github.com. If you use this URL, the "git push origin" command that appears later in this document will not work. Therefore, if you want to be able to update the "origin" repository, you should use the URL that starts "git@github.com", i.e. the second of the two "git clone" commands given above. This will give you read and write access to the repository on github.com.

== Keeping your public repository up-to-date ==

[[image:git-sync-github.png|right|thumb|400px|Fetching changes from upstream and pushing them to github]]
Your fork at Github is not updated automatically. To keep it synced with the upstream Moodle repository, you have to fetch the recent changes from the official moodle.git and push them to your public repository. To avoid problems with this it is strongly recommended that you never modify the standard Moodle branches. ''Remember: never commit directly into master and MOODLE_xx_STABLE branches.'' In other words, always create topic branches to work on. In Gitspeak, the master branch and MOODLE_xx_STABLE branches should be always fast-forwardable.

To keep your public repository up-to-date, we will register remote repository git://git.moodle.org/moodle.git under 'upstream' alias. Then we create a script to be run regularly that fetches changes from the upstream repository and pushes them to your public repository. Note that this procedure will not affect your local working directory.

To register the upstream remote:

cd moodle
git remote add upstream git://git.moodle.org/moodle.git

The following commands can be used to keep the standard Moodle branches at your Github repository synced with the upstream repository. You may wish to store them in a script so that you can run it every week after the upstream repository is updated.

#!/bin/sh
git fetch upstream
for BRANCH in MOODLE_{19..27}_STABLE master; do
git push origin refs/remotes/upstream/$BRANCH:$BRANCH
done

=== How it works ===

The git-fetch command does not modify your current working dir (your checkout). It just downloads all recent changes from a remote repository and stores them into so called remote-tracking branches. The git-push command takes these remote-tracking branches from upstream and pushes them to Github under the same name. Understanding this fully requires a bit knowledge of Git internals - see gitrevisions(7) man page.

Note there is no need to switch the local branch during this. You can even execute this via cron at your machine. Just note that the upstream repository updates typically just once a week.

=== New branches ===

Occasionally, moodle.org will create a new branch that does not exist in your public (e.g. Github.com) repository. If you try to push this new branch, you will see an error such as the following:

error: unable to push to unqualified destination: MOODLE_99_STABLE
The destination refspec neither matches an existing ref on the remote
nor begins with refs/, and we are unable to guess a prefix based on the source ref.
error: failed to push some refs to 'git@github.com:YOUR_GITHUB_USERNAME/moodle.git'

In the above example, "MOODLE_99_STABLE", is the name of the new branch that does not exist in your public repository. To fix the error, you need to create the new branch on your public repository, using the following commands, replacing "MOODLE_99_STABLE" with the name of the new branch you wish to create:

git checkout MOODLE_99_STABLE
git push origin MOODLE_99_STABLE:MOODLE_99_STABLE

The above code will create a new copy of the "MOODLE_99_STABLE" branch in your local repository. If you do not need to keep a local copy of the new branch - and probably you do not need it, you then can remove it from your local repository as follows:

git checkout master
git branch -D MOODLE_99_STABLE

== Preparing a patch ==

As said earlier at this page, you never work on standard Moodle branches directly. Every time you are going to edit something, switch to a local branch. Fork the local branch off the standard branch you think it should be merged to. So if you are working on a patch for 1.9 or 2.0, fork the branch off MOODLE_19_STABLE or MOODLE_20_STABLE, respectively. Patches for the next [[Moodle versions|major version]] should be based on the master branch.

git checkout -b MDL-xxxxx-nasty-bug origin/master

Note that if you forget to specify the starting point, the branch is based on the currently checked-out branch. It may not be what you want. It is recommended to always specify the starting point.

To check the current branch, run

git branch

The current branch is highlighted.

Now go and fix the issue with your favorite IDE. Check the status of the files, view the change to be committed and finally commit the change:

vim filename.php
git status
git diff
git commit -a

Note that this is safe as the commit is recorded just locally, nothing is sent to any server yet (as it would in CVS). To see history of the commits, use

git log

Once your local branch contains the change (note that it may consists of several patches) and you are happy with it, publish the branch at your public repository:

git push MDL-xxxxx-nasty-bug

Because we did not specify explicit remote repository, the 'origin' is used. Because we did not specify the branch to push, the Git will use the current branch and push it to the remote repository under the same name (by default, this is a subject of your configuration. See push.default config variable).

Now as your branch is published, you can ask Moodle core developers to review it and eventually integrate it into the standard Moodle repository.

=== Checking if a branch has already been merged ===

After some time contributing to Moodle you would have a lot of branches both in your local repository and in your public repository. To prune their list and delete those that were accepted by upstream, use the following

git fetch upstream (1)
git branch --merged upstream/master (2)
git branch --merged upstream/MOODLE_20_STABLE (3)

The command (1) fetches the changes from your upstream repository at git.moodle.org (remember that git-fetch does not modify your working dir so it is safe to run it whenever). Command (2) and (3) print all branches that are merged into the upstream master branch and MOODLE_20_STABLE branch, respectively. To delete these local branches, use

git branch -d MDL-xxxxx-accepted-branch

The similar approach can be used to check the branches published at your origin repository at github.com

git fetch origin (1)
git fetch upstream
git branch -r --merged upstream/master (2)
git branch -r --merged upstream/MOODLE_20_STABLE (3)

The command (1) makes sure that you have all your branches from github.com recorded as the remote tracking branch locally. Commands (2) and (3) work the same as in the previous example but they list remote tracking branches only ([http://www.kernel.org/pub/software/scm/git/docs/git-branch.html see -r param]). To delete a branch at github.com, use

git push origin :MDL-xxxx-branch-to-delete

This syntax may look weird to you. However it is pretty logical. The general syntax of the git-push command is

git push <repository> <source ref>:<target ref>

so deleting a remote branch can be understood as pushing an "empty (null) reference" to it.

== Peer-reviewing someone else's code ==

To review a branch that someone else pushed into their public repository, you do not need to register a new remote (unless you work with such repository frequently, of course). Let us imagine your friend Alice pushed a work-in-progress branch called 'wip-feature' into her Github repository and asked you to review it. You need to know the read-only address of the repository and the name of the branch.

git fetch git://github.com/alice/moodle.git wip-feature

This will download all required data and will keep the pointer to the tip of the wip-feature branch in a local symbolic reference FETCH_HEAD. To see what's there on that branch, use

git log -p FETCH_HEAD

To see how a particular file looks at Alice's branch

git show FETCH_HEAD:admin/blocks.php

To create a new local branch called 'alice-wip-feature' containing the work by Alice, use

git checkout -b alice-wip-feature FETCH_HEAD

To merge Alice's work into your current branch:

git merge FETCH_HEAD

To see what would be merged into the current branch without actually modifying anything:

git diff ...FETCH_HEAD

Once you are all set and reviewing code, this [[Peer_reviewing_checklist|checklist]] should prove to be useful.

== Rebasing a branch ==

Rebasing is a process when you cut off the branch from its current start point and transplant it to another point. Let us assume the following history exists:

A---B---C topic
/
D---E---F---G master

From this point, the result of the command:

git rebase master topic

would be:

A'--B'--C' topic
/
D---E---F---G master

and would end with 'topic' being your current branch.

You may be asked to rebase your branch submitted for the integration if the submitted branch was based on an outdated commit. The typical case is if you create a new branch as a fork off the upstream master branch on Tuesday. Then on Wednesday, the upstream master branch grows as all changes from the last integration cycle are merged to it. To make diff easy on Github for next weekly pull request review, you want to rebase your branch against the updated master.

git rebase master MDL-xxxxx-topic-branch

Note that rebasing effectively rewrites the history of the branch. '''Do not rebase the branch if there is a chance that somebody has already forked it and based their own branch on it.''' For this reason, many Git tutorials discourage from rebasing any branch that has been published. However in Moodle, all branches submitted for integration are potential subject of rebase (even though we try to not to do it often) and you should not base your own branches on them.

=== Conflicts during rebase ===

During the rebase procedure, conflicts may appear. git-status commands reports the conflicted files. Explore them carefully and fix them in your editor (like you would do with CVS). Then add the files with 'git add' command and continue.

vim conflicted.php
git add conflicted.php
git rebase --continue

== Applying changes from one branch to another ==

Most bugs are fixed at a stable branch (like MOODLE_20_STABLE) and the fix must be prepared for other branches, too (like MOODLE_21_STABLE and the main development branch - master). In Moodle, we do not merge stable branches into the master one. So usually the contributor prepares at least two branches - with the fix for the stable branch(es) and with the fix for the master branch.

If you have a patch prepared on a local branch (let us say MDL-xxxx-topic_20_STABLE), it is possible to re-apply it to another branch.

=== Cherry-picking a single commit ===

Let us have two local Git repositories ~/public_html/moodle21 containing local installation of Moodle 2.1 and ~/public_html/moodledev with the local installation of most recent development version of Moodle. They both use your public repository at github.com as the origin. You have a branch in moodle21 called MDL-xxxx-topic_21_STABLE that was forked off MOODLE_21_STABLE. It contains one commit. Now you want to re-apply this commit to a branch MDL-xxxx-topic in moodledev.

cd ~/public_html/moodledev
git checkout -b MDL-xxxx-topic origin/master (1)
git fetch ../moodle21 MDL-xxxx-topic_21_STABLE (2)
git cherry-pick FETCH_HEAD (3)

The command (1) creates new local branch forked off the CONTHERE The command (1) fetches all data needed to re-apply the topic branch and stores the pointer to the tip of that branch to FETCH_HEAD symbolic reference. The command (2) picks the tip of the branch (the top-most commit on it) and tries to apply it on the current branch.
There is also a variant of the cherry-pick command that supports multiple commits, shortly (see its man page for details): <code bash>$ git cherry-pick A^..B</code> if you want to include from A - see '''^''' - to B, A should be older than B. We will use another approach for cherry-picking multiple commits.

=== Applying a set of patches ===

If the branch MDL-xxxx-topic_21_STABLE from the previous example consists of several commits, it may be easier to use git-format-patch and git-am combo to re-apply the whole set of patches (aka patchset). Firstly you will export all commits from the topic branch to files.

cd ~/public_html/moodle21
mkdir .patches
git format-patch -o .patches MOODLE_21_STABLE..MDL-xxxx-topic_21_STABLE (1)

The command (1) takes all commits from the topic branch that are not in MOODLE_21_STABLE and exports them one by one to the output directory .patches. Look at the generated files. They contain the patch itself (in diff format) and additional information about the commit. You could eg send these files by email to a friend of yours for peer-review. We will use them in another repository.

cd ~/public_html/moodledev
git checkout -b MDL-xxxx-topic origin/master
git am -3 ../moodle21/.patches/* (1)

The command (1) applies all the files from the .patches directory. When a patch does not apply cleanly, the command tries fall back on 3-way merge (see the -3 parameter). If conflicts occur during the procedure, you can either deal with them and then use `git am --continue` or abort the whole procedure with `git am --abort`.

== See also ==

; Moodle forum discussions
* [http://moodle.org/mod/forum/discuss.php?d=168094 GIT help needed]
* [http://moodle.org/mod/forum/discuss.php?d=165236 Best way to manage CONTRIB code with GIT]
* [http://moodle.org/mod/forum/discuss.php?d=167063 Handy Git tip for tracking 3rd-party modules and plugins]
* [http://moodle.org/mod/forum/discuss.php?d=167730 Moodle Git repositories]
* [http://moodle.org/mod/forum/discuss.php?d=183409 Git help!! I don't understand rebase enough...]
* [http://moodle.org/mod/forum/discuss.php?d=217617 add MOODLE_24_STABLE to github.com repository]

; External resources
* [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT With 20 Commands Or So]
* [http://gitref.org/ Git Reference]
* [http://progit.org/book/ Pro Git book]
* [http://vimeo.com/14629850 Getting git by Scott Chacon] - an recording of an excellent 1-hour presentation that introducing git, including a simple introduction to what is going on under the hood.
* [http://tjhunt.blogspot.co.uk/2012/03/fixing-bug-in-moodle-core-mechanics.html Tim Hunt's blog: Fixing a bug in Moodle core: the mechanics]

[[Category:Git]]

[[ja:開発者用Git]]

Moodle 2.7 release notes

2014-04-04T04:54:48Z

Mwithheld: Add tracker ticket for Logging

[[Releases]] > {{FULLPAGENAME}}

Release date: Expected in May 2014

==Server Requirements==

These are just minimums. We recommend keeping all your software updated.

* Moodle upgrade: Moodle 2.2 or later (if upgrading from earlier versions, you must upgrade to 2.2.11 as a first step)
* Minimum Database versions:
** PostgreSQL 9.1
** MySQL 5.5.31
** MariaDB 5.5.31
** MSSQL 2008, or
** Oracle 10.2
* 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/)
*Ghostscript should be installed for pdf annotation.

==Browser requirements==

* Recent Google Chrome, recent Mozilla Firefox, Safari 6, Internet Explorer 9 (IE 10 required for drag and drop of files from outside the browser into Moodle)

==Before you upgrade==

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 going to the [[:en:Environment]] check page. This check is at the bottom of the page.

Several core themes have been removed prior to the release of Moodle 2.7.
If you use and wish to continue using one of the following themes you will be required to reinstall it *BEFORE* running the upgrade.

* After burner [https://moodle.org/plugins/view.php?plugin=theme_afterburner plugins db] [https://github.com/moodlehq/moodle-theme_afterburner github]
* Anomaly [https://moodle.org/plugins/view.php?plugin=theme_anomaly plugins db] [https://github.com/moodlehq/moodle-theme_anomaly github]
* Arialist [https://moodle.org/plugins/view.php?plugin=theme_arialist plugins db] [https://github.com/moodlehq/moodle-theme_arialist github]
* Binarius [https://moodle.org/plugins/view.php?plugin=theme_binarius plugins db] [https://github.com/moodlehq/moodle-theme_binarius github]
* Boxxie [https://moodle.org/plugins/view.php?plugin=theme_boxxie plugins db] [https://github.com/moodlehq/moodle-theme_boxxie github]
* Brick [https://moodle.org/plugins/view.php?plugin=theme_brick plugins db] [https://github.com/moodlehq/moodle-theme_brick github]
* Formal_white [https://moodle.org/plugins/view.php?plugin=theme_formal_white plugins db] [https://github.com/andreabix/moodle-theme_formal_white github]
* Form factor [https://moodle.org/plugins/view.php?plugin=theme_formfactor plugins db] [https://github.com/moodlehq/moodle-theme_formfactor github]
* Fusion [https://moodle.org/plugins/view.php?plugin=theme_fusion plugins db] [https://github.com/moodlehq/moodle-theme_fusion github]
* Leatherbound [https://moodle.org/plugins/view.php?plugin=theme_leatherbound plugins db] [https://github.com/moodlehq/moodle-theme_leatherbound github]
* Magazine [https://moodle.org/plugins/view.php?plugin=theme_magazine plugins db] [https://github.com/moodlehq/moodle-theme_magazine github]
* Nimble [https://moodle.org/plugins/view.php?plugin=theme_nimble plugins db] [https://github.com/moodlehq/moodle-theme_nimble github]
* Nonzero [https://moodle.org/plugins/view.php?plugin=theme_nonzero plugins db] [https://github.com/moodlehq/moodle-theme_nonzero github]
* Overlay [https://moodle.org/plugins/view.php?plugin=theme_overlay plugins db] [https://github.com/moodlehq/moodle-theme_overlay github]
* Serenity [https://moodle.org/plugins/view.php?plugin=theme_serenity plugins db] [https://github.com/moodlehq/moodle-theme_serenity github]
* Sky high [https://moodle.org/plugins/view.php?plugin=theme_sky_high plugins db] [https://github.com/moodlehq/moodle-theme_sky_high github]
* Splash [https://moodle.org/plugins/view.php?plugin=theme_splash plugins db] [https://github.com/moodlehq/moodle-theme_splash github]
* Standard [https://moodle.org/plugins/view.php?plugin=theme_standard plugins db] [https://github.com/moodlehq/moodle-theme_standard github]
* Standard old [https://moodle.org/plugins/view.php?plugin=theme_standardold plugins db] [https://github.com/moodlehq/moodle-theme_standardold github]

For more information about the removal of these themes see MDL-43784.

==Headline core features==

===Interface===
* Atto - our new Moodle editor, tightly integrated in Moodle and focussing on usability and accessibility (TinyMCE still available as an option)
* Themes clean-up - Moodle now uses Bootstrap by default. Clean is now the default theme and most other old themes have been removed from core (still available from Plugins database).
* More - a completely new theme called More that provides easy configuration though the UI while retaining the power of LESS and Bootstrap.

===Platform===
* 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
* Performance - many improvements that improve overall performance in most cases
* Tasks - an improved scheduling system (like Unix cron) that allows precise scheduling of tasks even on complex clustered servers

===Long-term support (LTS) until June 2017===

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 dataloss fixes''''.

If you are stuck on an old version then this might be the perfect time to upgrade!

==Details==

===Quiz & Question bank===

* Quiz reports improved. MDL-41727
** Responses from all tries are avaiable for analysis when using or "Adaptive", "Interactive with multiple tries" or similar behaviours.
** Break-down by question variant, for question types like Calculated, STACK and Variable-numeric, which one question can have different random variants.
** Progress bar during long calculations to prevent time-outs.
** Low-level calculation code moved into the question component, where it could potentially be reused by other activities.
** Much more automated testing of this complex area of code.
* Some minor improvements to the usability of the question bank - Some of MDL-40987
** To duplicate a question, you now start by clicking the x2 icon, like for activities. MDL-33653
** The various different ways to move questions in the question bank have been rationalised. MDL-33839
** 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
* New plugin point, so that plugins can add columns to the question bank, or new search conditions. MDL-40313 & MDL-40457
* Essay questions can now require an attachment, with the text optional, rather than the other way around. MDL-39756
* Random short-answer matching question type brought back from the dead. (This was in stable branches, but worht mentioning again.) MDL-27414

===Assignment===

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.

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.

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.

If you really, really need to keep using the old module, you should update the code to Moodle 2.7, and then replace the "mod/assignment" folder with the one from the plugins database before completing the upgrade.

===Cron===

Cron has received a major update and now has support for both scheduled and adhoc tasks - MDL-25499.
The benefits of these changes are:
* The schedule for every task can be configured by the admin
* Tasks can run in parallel
* Cron processes use locking to prevent the same task running at the same time by different processes

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.

[[fr:Notes de mise à jour de Moodle 2.7]]

Moodle 2.4 release notes

2012-11-19T18:45:45Z

Mwithheld: /* Performance improvements */

[[Releases]] > {{FULLPAGENAME}}

Release date: December 2012

Here is [http://tracker.moodle.org/secure/IssueNavigator!executeAdvanced.jspa?jqlQuery=project+%3D+mdl+AND+resolution+%3D+fixed+AND+fixVersion+in+%28%222.4%22%29+ORDER+BY+priority+DESC&runQuery=true&clear=true the full list of fixed issues in 2.4].

Many thanks to [http://moodle.org/dev/contributions.php?version=2.4.x everyone that worked on the new features in this release]

A special thanks to our incredible ''''Integration Team'''' from Moodle HQ who worked tirelessly with all developers to review, test and help finish code for inclusion in Moodle core:

* Eloy Lafuente
* Sam Hemelryk
* Dan Poltawski
* Aparup Bannerjee

Finally, thanks to all our testers both within Moodle HQ and from the whole community, who have contributed to producing our most exciting and stable release yet!

===Requirements===

* Recommended minimum browser: Firefox 4, Internet Explorer 8 (IE 10 required for drag and drop of files from outside the browser into Moodle), Safari 5, Google Chrome 11, Opera 9
* Moodle upgrade: Moodle 2.2 or later (if upgrading from earlier versions, you must upgrade to 2.2 as a first step)
* Minimum DB versions: Postgres 8.3, MySQL 5.1.33 (MDL-33984), MSSQL 2005 or Oracle 10.2
* Minimum PHP version: PHP 5.3.2

NOTE: We will probably drop support for IE8 in Moodle 2.5 (June 2013)

===Major new features===

====Performance improvements====

A variety of improvements have been made under the hood to improve performance in a number of ways. Some of require configuration by the admin to take advantage of them but used properly they can allow you to make better use of your hardware for faster speed and more students.

* MDL-33018 - New context index to substantially improve system performance on large PostgreSQL installations.
* MDL-30643 - Improved daily statistics performance.
* MDL-33017 - Significant size reduction of navigation widget.
* MDL-25290 - MUC Stage 1: Implement some core caching architecture (MUC).
* MDL-34343 - Database meta information caching.
* MDL-34399 - Question related caching.

''''((NOTE: We need performance graphs here comparing 2.4 to 2.3))''''
* [http://www.iteachwithmoodle.com/2012/11/17/moodle-2-4-beta-performance-test-comparison-with-moodle-2-3/ Moodle 2.4 Beta performance test – comparison with Moodle 2.3]

====Plugin updating from within Moodle====

* MDL-35238 - Not only will Moodle tell you when one of your plugins is out-of-date, but you can also now update it via the web interface.

====Course format plugins====

Moodle has always supported pluggable course formats, but now we've given developers even more flexibility than before. Course formats can now provide their own settings for courses and sections, and they can also have a lot more control of all the pages in a course.

* MDL-35218 - Course formats re-factoring

We're looking forward to seeing some exciting course formats from the community in future. (Note that in 2.4 the standard course formats have not been changed).

====Themes====

* MDL-22955 - Support for SVG icons.
* MDL-34299 - All pages are now served HTML5 doctype by default. This allows us to improve usability, add new features, developers can use reliable iframe tag instead of broken object embedding, data attributes may simplify JavaScript code, etc.
* MDL-36487, MDL-36481 - Improved compatibility with Internet Explorer 8-10.
* MDL-34915 - SimpleYUI enables similar coding style to JQuery, it is intended especially for theme designers.
* Multiple RTL fixes and improvements.
* MDL-34080 - Complete overhaul of all icons. The default icons used for activities and editing actions have been updated for the first time since Moodle 1.0. Not only are they a little bigger and more colourful but they are SVG format and support full scaling on all devices, so they always look good. (Developers, see [[Moodle icons 2.4]])

====Improved TinyMCE editor integration====

The integration of TinyMCE editor was significantly improved:

* MDL-33041 - Support for fully configurable add-on plugins extending standard TinyMCE.
* MDL-35172 - New TinyMCE editor settings allowing an admin to customise the toolbar, enable/disable icons such as insert equation and insert emoticon.
* MDL-35955 - Support for built-in browser spell checking.
* MDL-34875 - Other minor fixes and improvements.

(Developers, see [[TinyMCE plugins]])

====Enrolment related improvements====

* MDL-35071 - Completely reworked support for enrolment restore, fully implemented in manual, self, cohort and database plugins.
* MDL-35064 - Option to move users to manual enrolment method when uninstalling other enrolment plugins.
* MDL-35062, MDL-35063 - New configurable expiration action in self and manual enrolment plugins.
* MDL-28980, MDL-35843 - Pending unenrolment notification in self and manual enrolment plugins.
* MDL-23875 - Self enrolment can be restricted to cohort members.
* MDL-31437 - Consistent synchronisation between cohorts, enrolments and groups.
* MDLSITE-1912 - New add-on plugin for cohort-group sync.
* MDL-35061 - More custom fields into enrol table.
* MDL-34696 - Other minor enrolment fixes and improvements.

====Integration of external calendars====

The most-voted feature request in the tracker has been fixed!

* MDL-16660 - You can now stream your external calendars (such as Google Calendar, or a calendar from another Moodle site) into Moodle's calendar via the iCal standard.

====Full support for Unicode file names in Zip archives====

* MDL-33710 - Moodle creates valid Zip archives with Unicode file names.
* MDL-33753 - Moodle now extracts most Zip archives with Unicode file names.

Please note that the built-in Windows zip/unzip is not Unicode compatible. It is possible to extra the windows zips if you set the same language in Moodle and in Windows, but Windows can not extract any valid Zip archives with Unicode file names. Please use other tools such as 7-Zip, WinZip or WinRar.

====Assignment enhancements====

A number of significant - and very welcome - enhancements to the assignment module have been made:

* MDL-31284 - Group assignments - It will now be possible to set an assignment which a group can work on collaboratively -and receive a common (or individual) grade.
* MDL-31291 - Blind marking i.e. not knowing the identity of students when grading. Students' names will be replaced by randomly generated Participant numbers.
* MDL-31295 - Submission date extensions - Teachers can set a cut-off date (and time) beyond which submissions will no longer be accepted. They can also grant extensions for those who miss the deadline.
* MDL-31288 - Submission statement - It will be possible to set a submission statement so students have to check a box promising their work is original before submitting it.

===Other highlights===

==== Workshop module enhancements ====

* MDL-36135 Full support for alternative grading evaluation methods.
* MDL-26349 Final grades are displayed to workshop participants when the activity is closed.
* MDL-35421 Ability to define a conclusion text to be displayed to workshop participants when the activity is closed.
* MDL-36209 Teachers can assess submissions in the grading evaluation phase without the need to switch to the assessment phase.

====Miscellaneous====

* MDL-8249 - Localised standard role names and descriptions.
* MDL-19430 - Users can set the order and number of courses displayed on their My home page.
* MDL-34088 - Students can now see the content of advanced grading forms on their assignment page before they submit.
* MDL-29538 - Activities and topics can be restricted according to user profile fields.

===Security issues===

All security issues that were fixed in 2.3.x and 2.2.x were also fixed in 2.4.

===For developers: API changes===

Abbreviated descriptions of API changes are always kept up to date in the "upgrade.txt" within each plugin area. We do this so that the information is always exactly right for the version of Moodle you are using. Changes in this release:

;Core: http://git.moodle.org/gw?p=moodle.git;a=blob;f=lib/upgrade.txt;hb=master
;Blocks: http://git.moodle.org/gw?p=moodle.git;a=blob;f=blocks/upgrade.txt;hb=master
;Course formats: http://git.moodle.org/gw?p=moodle.git;a=blob;f=course/format/upgrade.txt;hb=master
;Enrolment plugins: http://git.moodle.org/gw?p=moodle.git;a=blob;f=enrol/upgrade.txt;hb=master
;Filters: http://git.moodle.org/gw?p=moodle.git;a=blob;f=filter/upgrade.txt;hb=master
;Activity modules: http://git.moodle.org/gw?p=moodle.git;a=blob;f=mod/upgrade.txt;hb=master See also [[Moodle_icons_2.4]] for information on the new icons.
;Quiz access rules: http://git.moodle.org/gw?p=moodle.git;a=blob;f=mod/quiz/accessrule/upgrade.txt;hb=master
;Quiz reports: http://git.moodle.org/gw?p=moodle.git;a=blob;f=mod/quiz/report/upgrade.txt;hb=master
;Portfolio plugins: http://git.moodle.org/gw?p=moodle.git;a=blob;f=portfolio/upgrade.txt;hb=master
;Question behaviour plugins: http://git.moodle.org/gw?p=moodle.git;a=blob;f=question/behaviour/upgrade.txt;hb=master
;Question behaviour plugins: http://git.moodle.org/gw?p=moodle.git;a=blob;f=question/format/upgrade.txt;hb=master
;Question types: http://git.moodle.org/gw?p=moodle.git;a=blob;f=question/type/upgrade.txt;hb=master
;Repository plugins: http://git.moodle.org/gw?p=moodle.git;a=blob;f=repository/upgrade.txt;hb=master
;Themes: http://git.moodle.org/gw?p=moodle.git;a=blob;f=theme/upgrade.txt;hb=master

====Core API changes====

* MDL-36145 - Latest YUI 3.7.3 imported, includes full IE 10 compatibility.
* MDL-34741 - Custom integration of YUI2 was replaced by 2in3. All legacy code needs to be updated to use new YUI3 modules, 2in3 dependency or SimpleYUI.
* MDL-31973 - Component field in group_members table. Group membership can be linked to other plugins.
* MDL-8249 - Improved API for customised role names.
* MDL-34960 - Dropped support for Google Maps V2 API, use V3 instead.
* MDL-35218 - Improved course-related functions.
* Latest versions of 3rd party libraries - ADOdb 5.17, Flowplayer 3.2.14, phpMailer 5.2.1, TCPDF 5.9.181.

====Plugin API changes====
* MDL-34270 - The ability to add blocks to My Moodle and to courses is now controlled by capabilities.

====Unit tests====
Unit tests are now required in most pull requests.

* MDL-33180 - SimpleTest support was removed, use PHPUnit instead.
* MDL-35479 - New debugging support in PHPUnit tests - simplified testing of code that uses debugging().
* MDL-36031 - Message redirection in PHPUnit tests - simplified testing of code that sends messages.
* More unit tests for cohorts, enrolments and other areas.

====Authentication plugins====
* MDL-34685 Auth plugins may provide custom user signup forms.

<noinclude>==See also==

* [https://docs.moodle.org/24/en/Category:New_features User documentation of new features in Moodle 2.4]
* [https://docs.moodle.org/24/en/Upgrading_to_Moodle_2.4 Upgrading to Moodle 2.4] - information for admins who are upgrading from earlier versions
*[[Moodle 2.3 release notes]]
* [[2.4_Test_Plan]] - Moodle 2.4 test plan.

[[Category:Release notes]]
[[Category:Moodle 2.4]]

[[fr:Notes de mise à jour de Moodle 2.4]]
</noinclude>

Talk:Logging stage2

2012-09-25T22:21:09Z

Mwithheld:

Please dump your thoughts here about additional things Moodle could be logging In a future new log system.

See also: [http://moodle.org/mod/forum/view.php?id=8044 Forum on analytics and reporting]

From Clive Holtham City University following Moodle Research Conference Session 5 on Learning Analytics

We need to capture every link clicked in Moodle. A click from a URL simply embedded in a page does not create an entry in Moodle Logs (for us anyway). So we have to create a hidden section with the URL's in their own right, which is captured by the logs, then point to that URL from the place where the original embedding was situated. It would be useful to have a table which reconciles the differing number of hits shown through different Moodle log reports.

Again for us anyway, activity in OUwiki is not showing up in the Moodle logs; OU told us today that the activity should show up.

It was interesting to hear about the privacy legislation in Germany and Switzerland which limit what personal detail can be shown out of Moodle. Even as in the UK where we can legally use the detail, I have reservations about displaying (for example) the time of day a click was made. So there needs to be a series of filters which will deliberately limit data which can be retrieved by an average user, whether for legal or other reasons.

When I create the most detailed actvity spreadsheet, there is very little filtering possible. I would, for example,, like to include only students in the main spreadsheet (exclude faculty and administrators).

On a separate issue, I have been concerned about the grown of use of Google Analytics, not least for data protection reasons, which in part derives from the very limited features and unattractive interface of Moodle logs/reports. GA cannot replace Moodle logs/reports; it can of course provide additional data than currently available. I would like an upgraded Moodle logs/reports to replace the need to use GA. Certainly the emphasis needs to shift to presenting the Moodle reports with a look and feel much more like Google Analytics.

One key point that came through at the conference is that the needs of individual teachers, management broadly defined, and students are all quite different. I would be anxious to see that whatever happens, the priority order for improvement should be
Teachers
Students
Management
The need for teachers and students does not relate to Big Data. It actually relates to Small Data- how can we gain insights from the fewest pieces of data. The very term Learning Analytics is associated with the Big Data movement, which is primarily related to managerial rather than teacher concerns.

From Alice Kaerast at Webanywhere:

I would very much like a nice control panel controlling what is logged. This is particularly important for sites with heavy traffic where I probably don't care about most activity, and systems like Google Analytics or Kissmetrics are better for this amount of traffic. I'd also like the ability to control where logs are saved, for very heavy traffic sites I might prefer to have logs streamed to somewhere other than my main database. Syslog would be great, a second external database would be nice, a message queueing system might be useful, a third-party cloud based logging system could be good - why not create an api to control where logs are sent?

From Mark van Hoek at University of Victoria:

The current logs are at once way too much info, yet not enough useful info. What I'd like: Log every click, every pageview, every submission, every delete, every redirect, for every user (including admins). Context info should include: course, module, url, request type, Moodle's response, response level (error, info, warning, fatal). Add powerful filtering on top: by user, by group, by course, by time period, by action (add, update, delete, click, submit, etc). Enhance ability to filter and follow a single users actions. Add an analytics UI layer for higher-level queries, with a UI to build new reports. Something like PiWik may be leveraged here.

Don't rely on module authors to write logging code -- centralize the logging (e.g. via a central controller class + output handler). Add better ability to delete log records and archive them out of the DB and into a file. The export be optionally excel or should comply to some standard that sysadmins can parse (e.g. log4java, syslog, ...), and that there are standard log readers/handlers for.

Relational integrity + ACID (consistency) is not so important for logging, and reading is less time-sensitive than writing -- this opens options to prevent logging from being a performance issue (e.g. NoSQL, write to a file, async logging, logging queues, whatever).

+1 for Alice's request for controlling what is logged.

Talk:Logging stage2

2012-09-25T22:04:48Z

Mwithheld:

Please dump your thoughts here about additional things Moodle could be logging In a future new log system.

From Clive Holtham City University following Moodle Research Conference Session 5 on Learning Analytics

We need to capture every link clicked in Moodle. A click from a URL simply embedded in a page does not create an entry in Moodle Logs (for us anyway). So we have to create a hidden section with the URL's in their own right, which is captured by the logs, then point to that URL from the place where the original embedding was situated. It would be useful to have a table which reconciles the differing number of hits shown through different Moodle log reports.

Again for us anyway, activity in OUwiki is not showing up in the Moodle logs; OU told us today that the activity should show up.

It was interesting to hear about the privacy legislation in Germany and Switzerland which limit what personal detail can be shown out of Moodle. Even as in the UK where we can legally use the detail, I have reservations about displaying (for example) the time of day a click was made. So there needs to be a series of filters which will deliberately limit data which can be retrieved by an average user, whether for legal or other reasons.

When I create the most detailed actvity spreadsheet, there is very little filtering possible. I would, for example,, like to include only students in the main spreadsheet (exclude faculty and administrators).

On a separate issue, I have been concerned about the grown of use of Google Analytics, not least for data protection reasons, which in part derives from the very limited features and unattractive interface of Moodle logs/reports. GA cannot replace Moodle logs/reports; it can of course provide additional data than currently available. I would like an upgraded Moodle logs/reports to replace the need to use GA. Certainly the emphasis needs to shift to presenting the Moodle reports with a look and feel much more like Google Analytics.

One key point that came through at the conference is that the needs of individual teachers, management broadly defined, and students are all quite different. I would be anxious to see that whatever happens, the priority order for improvement should be
Teachers
Students
Management
The need for teachers and students does not relate to Big Data. It actually relates to Small Data- how can we gain insights from the fewest pieces of data. The very term Learning Analytics is associated with the Big Data movement, which is primarily related to managerial rather than teacher concerns.

From Alice Kaerast at Webanywhere:

I would very much like a nice control panel controlling what is logged. This is particularly important for sites with heavy traffic where I probably don't care about most activity, and systems like Google Analytics or Kissmetrics are better for this amount of traffic. I'd also like the ability to control where logs are saved, for very heavy traffic sites I might prefer to have logs streamed to somewhere other than my main database. Syslog would be great, a second external database would be nice, a message queueing system might be useful, a third-party cloud based logging system could be good - why not create an api to control where logs are sent?

From Mark van Hoek at University of Victoria:

The current logs are at once way too much info, yet not enough useful info. What I'd like: Log every click, every pageview, every submission, every delete, every redirect, for every user (including admins). Context info should include: course, module, url, request type, Moodle's response, response level (error, info, warning, fatal). Add powerful filtering on top: by user, by group, by course, by time period, by action (add, update, delete, click, submit, etc). Enhance ability to filter and follow a single users actions. Add an analytics UI layer for higher-level queries, with a UI to build new reports. Something like PiWik may be leveraged here.

Don't rely on module authors to write logging code -- centralize the logging (e.g. via a central controller class + output handler). Add better ability to delete log records and archive them out of the DB and into a file. The export be optionally excel or should comply to some standard that sysadmins can parse (e.g. log4java, syslog, ...), and that there are standard log readers/handlers for.

Relational integrity + ACID (consistency) is not so important for logging, and reading is less time-sensitive than writing -- this opens options to prevent logging from being a performance issue (e.g. NoSQL, write to a file, async logging, logging queues, whatever).

+1 for Alice's request for controlling what is logged.