Howard Miller

I don't think you can. The underlying ADODB library has affected_rows() but the Moodle layer on top doesn't appear to expose it.

You would need to do a separate count_records() or similar.

I am now waiting to be corrected

It's not recommended to run Moodle on a site with open_basedir restrictions. If you have the ability to do so, I strongly recommend disabling those restrictions.

If you cannot, then unoconv HAS to be within the "allowed paths".

The other point is that I don't think unoconv is supported any more. So are you using that intentionally?

You don't say which versions of Moodle you are talking about. However, the security patches are all mentioned in each new version's release notes. (For example, here is 5.0.1, which has a few - https://moodledev.io/general/releases/5.0/5.0.1). They reference the security announcements forum, here https://moodle.org/mod/forum/view.php?id=7128. You shouldn't need a "compelling" reason to update Moodle. Do you patch the servers on which Moodle runs?

I'm not sure what to say if you can't find config.php. It's in the 'root' directory of your Moodle installation. It's not a bad move to see what the database is doing if Moodle 'stops'. It's a start, anyway.

The error would imply that something is looking for the open_lms (optional) plugin. I don't know anything much about them - but are you using these plugins?

Hide the calendar block in Site admin > Plugins > Manage blocks?

BTW... you don't usually need prevent and prohibit. Jst Not set should do the job.