This reverses the references used for global $USER and $SESSION,
the reason is that PHP does not allow references to references.
$USER is a reference to $GLOBALS['USER'] which means we cannot
put any references to it. Solution is to store the current user and session
objects in $GLOBALS['USER'] and $GLOBALS['SESSIOn'] are reference
them in $_SESSION.
This patch makes the session code behave the same way in CLI,
phpunit and normal web requests - this allows use to finally
unit test most aspects of the session code in Moodle.
For stores where there is a very high rate of sets compared to gets, it
is beneficial to retrieve from the local server, skipping the network
overhead, at the expense of having to set many severs when a key is set.
This patch adds a memcache option to enable clustering. When on, only
one "server" is allowed, which will be where fetches are from, while
sets/updates/deletes/purges will occur to the all the servers in the
"set server" list.
To run unit tests, define TEST_CACHESTORE_MEMCACHE_TESTSERVERS with
multiple (return delimited) servers.
For stores where there is a very high rate of sets compared to gets, it
is beneficial to retrieve from the local server, skipping the network
overhead, at the expense of having to set many severs when a key is set.
This patch adds a memcached option to enable clustering. When on, only
one "server" is allowed, which will be where fetches are from, while
sets/updates/deletes/purges will occur to the all the servers in the
"set server" list.
To run unit tests, define TEST_CACHESTORE_MEMCACHED_TESTSERVERS with
multiple (return delimited) servers.
Allows plugins to add columns to the question bank view by extending core_question\bank\column_base
Columns to display are set in $CFG->questionbankcolumns. Columns are namespaced and autoloaded to support this.
user_updated event was being triggred while
setting password, which is not correct. It now
trigger user_password_updated event. Few more
modifications done:
1. Correct event is being triggred.
2. Event is only triggred when password is chnaged.
3. Password is updated via single api.
4. Updated unit test
On some pages full user data is not stored before user_created/
user_updated event is triggred. So giving option to trigger that
manually, so it can be triggred after all data is saved
Using mismatches from the submissions/grades tables does not make much sense, we
should always only consider only the maxattempt from the submissions table.