OK Marc, here comes the solution...
Unfortunately that block seems to be a little more complicated than
strictly necessary (it seems that it wasn't quite clear that on many
occasions you can just benefit from the default code base instead of
overriding it, I hope that's going to change now with the available
docs) and that's why my quick fixes didn't work.
To just get the block working, you need to:
- Open blocks/rssfeed/block_rssfeed.php
- Find this code snippet (it's near the beginning) and DELETE ALL OF IT:
function print_config() {
global $CFG, $THEME;
print_simple_box_start('center', '', $THEME->cellheading);
include($CFG->dirroot.'/blocks/'.$this->name().'/config.php');
print_simple_box_end();
return true;
}
function handle_config($config) {
foreach ($config as $name => $value) {
set_config($name, $value);
}
return true;
}
- Now, rename blocks/rssfeed/config.php to blocks/rssfeed/config.html
- After renaming, add the line with $GLOBALS['USER'] as I describe above
This should get everything working!
Also, please do not feel uneasy about deleting that snippet. As long as you rename the config.php file to its "recommended name", Moodle will automatically recognize it. There is no danger of making things
worse.
And then there's also the compatibility issue... well, to be frank, if you had upgraded to Moodle 1.5.2 from 1.5, then you wouldn't ever have had this problem, for one (incidentally, it was caused by the security improvements associated with sesskey and not by Blocks changes). I 'm saying this to point out that frankly, the Blocks system which dates back to pre-1.3 was something of a toy project which met with unexpectedly high demand; the sesskey incident is a consequence of that; and that the new Blocks in 1.5 (while breaking compatibility) are indeed much more able to scale and meet future requirements (no more sesskey incidents in the future).
Actually Martin they might last beyond 2050 but I think that by then people will be more interested in faster-than-light travel than in Blocks
-