I 've come across a problem where:
1. You have an "old" (say 1.3.5?) Moodle installation.
2. You are logged in as admin.
3. You suddenly switch to using a 1.5+ codebase with
the SAME database, WITHOUT LOGGING OUT FIRST.
In this situation, I was presented with a deadlock. I could not do
anything because "my session had expired", and I could not even
log OUT to clear my session. In fact it was just reloading the
"session expired page" all the time.
If it weren't for debug = On which causes a notice in these
circumstances, it would be fracking difficult to understand what
was going on.
With this small addition, you can at least visit your login page
and log in anew, so problem fixed.
I believe this was talked about in the forums lately? Not sure.
- 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.
I 've come across a problem where:
1. You have an "old" (say 1.3.5?) Moodle installation.
2. You are logged in as admin.
3. You suddenly switch to using a 1.5+ codebase with
the SAME database, WITHOUT LOGGING OUT FIRST.
In this situation, I was presented with a deadlock. I could not do
anything because "my session had expired", and I could not even
log OUT to clear my session. In fact it was just reloading the
"session expired page" all the time.
If it weren't for debug = On which causes a notice in these
circumstances, it would be fracking difficult to understand what
was going on.
With this small addition, you can at least visit your login page
and log in anew, so problem fixed.
I believe this was talked about in the forums lately? Not sure.
(Also merging Martin's theme standard -> standardwhite change)
* 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
martinlanghoff