* Extended set_config()
* Implemented get_config() which takes over $CFG loading in setup.php
* admin/auth.php has special handling if post vars starting in pluginconfig_
* admin/auth.php print_auth_lock_options() prints a form fragment -- being called from most plugins now
* user/edit.php follows the new convention when locking down fields, both javascript UI and on POST.
* admin/auth: More solid checking for auth GET/POST var.
* admin/auth: print_auth_lock_options() now handles user field mapping options for LDAP and similar modules
* admin/auth: user mapping options have moved to config_plugins table
* auth/ldap module has migrated to using new field mapping vars -- simplified config.html a lot
* auth settings migration to config_plugins
some double backslashes present yet. This method doesn't addslashes()
automatically like the old one (so kses_stripslashes() is not needed).
All we have to to is to stripslashes() before calling kses and addslashes()
after it. Only in clean_param(), because params arrive always slashed
to Moodle. This seems to be the correct approach documented in:
http://sourceforge.net/project/shownotes.php?group_id=81853&release_id=302996
1. When user was using "Server's local time", and the server was set up to
use DST, generated timestamps must have been wrong in DST periods (I
haven't backtracked to test this, but the code reads this way).
2. On Eloy's Mac (let's not generalize without data), passing is_dst = 0 to
gmmktime caused it to return WRONG results!
The PHP docs clearly state that in_dst does NOT affect the return value,
which is true for me but in Eloy's case it was a lie. Obviously PHP bug here.
Also, moved the if($applydst) check into the else branch because it would do
nothing at all if (abs($timezone) > 13) in any case.
I hope Eloy keeps finding more bugs because he promised me a beer for this fix ;-)
Since we 're at it, fixed another bug: automatic recalculation of DST table
without having to logout if the user changes his timezone now works correctly.
2. usertime: I think that the way Moodle is written, if this compensates for DST lots
of things are going to break. I found a few myself and decided to revert the behavior
until such time as a proper code review can be made.
user's effective timezone correctly using get_user_timezone(). It also remembers
which timezone was in effect when it cached its calculations, so if the user's
effective timezone changes for any reason the table is automatically re-computed.
******
NOTICE
******
From this point onward, DST support should be working again, and there are no more
visible hurdles in the way. This means it should STAY working correctly until 1.5.
mjollnir_