Howard Miller

I'm running out of ideas. I guess the next thing I would do is to write a one-line PHP script to see if that function executes outside of Moodle - i.e. just in case Moodle IS doing something weird to block the function.

Firstly, the core\ namespace seems to be spurious - that identifies the legitimate call to the reset function.

Please go to Site administration > Server > PHP Info. Show us...

* The logo at the top that confirms the PHP version.
* The lines in the core table for 'disabled_classes' and 'disabled_functions'

Effectively, I am asking you to prove beyond doubt that you are running the appropriate version of Moodle and that the function hasn't been blocked. One of those, is the only reasonable explanation I can think of.

In any case, it's 99% that this is not Moodle - it's your setup at fault.

That's still not the complete trace. We need to establish where this function is being called from.

block_recent_activity does NOT call the function but that does not 100% prove that it isn't calling something else that does.

What threw me was the core\ in front of the function call. It's like the code is trying to call something other than the actual PHP function. Although, I may be overthinking it.

Did you try it with 4.5? Just because it hasn't been marked as compatible (yet) doesn't mean it isn't.