Where Moodle sites had a path in their wwwroot, the MNET function that
forced remote users to go via their identity provider (to make sure they
were logged in) previously directed the user back to a URL like
contentprovider.com/moodle/moodle/mod/forum/view.php?f=7 where there
should only be one /moodle in the middle of the URL.
Added new sessioncookiedomain setting to session handling section.
* allows you to change the domain that the Moodle cookies are available
from. This is useful for Moodle customisations (i.e. Squirrelmail SSO
or enrolment plugins) that need to share Moodle session information
with a web application on another subdomain.
* Will NOT work if the moodle host does not have a domain - i.e. just a
hostname, e.g. 'localhost' or 'myhostname'. Needs a FQDN
* Currently the setting is set to PARAM_TEXT length 50 since PARAM_HOST
does not allow a leading dot e.g. '.mydomain.com'
* TODO: do we make up a new PARAM_COOKIEDOMAIN which is the same as
PARAM_HOST but allows leading dots? Using PARAM_HOST and prepending a
dot may not always be desirable.
* Added support for CHAP and MSCHAP authentication schemes
contributed by Stanislav Tsymbalov http://www.tsymbalov.net/
original code at http://sourceforge.net/projects/moodleradius/
* Tweak the detection of PHP RADIUS extension and Pear code
* Update the warning notices to use more Moodly CSS classes
lib/pear: Add RADIUS and CHAP PEAR libs
* Add PEAR Auth_RADIUS and Crypt_CHAP packages to lib/pear
Author: Jonathan Harker <jonathan@catalyst.net.nz>
MDL-15315 The previous fix for this issue with wildcard answers in the item analysis report caused the following two regressions. This patch fixes it properly.
MDL-17247 This is basiclly pointing out the weridness in the previous fix and gave some useful clues as to a proper solution. Thanks Oleg.
MDL-17610 This was a report of a problem with each attempt builds on last, with a shortanswer question, where the sutdent's response contains a '.
Also, lots of unit tests to try to ensure the new code is right.
That was becuase not enough information was being passed in for the blocks editing controls to construct the right URL to reload the page.
It is also now possible for admin external pages to add some UI next to the turn blocks editing on/off button. For example, when you are editing the list of course catgories, the turn editing off button is now in the right place.
This was visible when, for example, unusual role definitions meant that someone could access a forum without being enrolled in a course.
Note that one of the places that was previously broken was front page forums. Since subscribers.php does not do paging at all, the fact that I have fixed this bug makes this page dangerous on large sites. A proper solution will have to wait until bug 17550 is fixed in HEAD.
This also fixes a minor problem introduced by MDL-12979.
