search

drachels / moodle-mod_mootyper

4 stars 18 forks source link

Fatal Error since update to 3.9.13: Declaration of mod_mootyper\privacy\provider::get_metadata #106

Closed abkoch closed 1 year ago

abkoch commented 2 years ago

Dear mootyper team,

since our update from moodle 3.9.12 to 3.9.13 ad-hoc tasks get stuck with the following error:

_PHP Fatal error: Declaration of mod_mootyper\privacy\provider::get_metadata(core_privacy\local\metadata\collection $collection) must be compatible with core_privacy\local\metadata\provider::get_metadata(core_privacy\local\metadata\collection $collection): core_privacy\local\metadata\collection in /var/www/moodle/mod/mootyper/classes/privacy/provider.php on line 51_

After removing mod_mootyper ad-hoc tasks run without failure.

Will there be a bug fix for this?

Best regards Andreas

drachels commented 2 years ago

What method did you use for your Moodle update? Which version of MooTyper are you using?

I have a test server on which I am using MooTyper v4.1.1 and just upgraded to Moodle 3.9.13. Everything appears to be working correctly.

Which ad-hoc tasks are you having trouble with? Scheduled tasks from Site administration > Server > Tasks > Scheduled tasks? Or ad-hoc's from the Site administration > Reports > Ad-hoc database queries plugin ?

abkoch commented 2 years ago

Thanks for your immediate response.

It's MooTyper v4.1.1 (Build: 2022012700). We've updated a large amount of Moodle instances (> 5000) the same way we do it usually: using an ansible routine that copies the new moodle files to the filesystem and invokes the updade process via CLI script "upgrade.php" afterwards.

The scheduled tasks work properly. The ad-hoc scripts fail as a manual run of the CLI script "adhoc_task.php" shows.

drachels commented 2 years ago

I am still unable to duplicate any problem with MooTyper v4.1.1 on Moodle 3.9. Makes me wonder what you have in the file at yourmoodle/mootyper/classes/task/cron_task.php in the public function execute(). MooTyper currently does not execute anything and only has a, return, there.

How does your ansible routine do the MooTyper upgrade? Does it do it with git, just file copy, or some other method?

abkoch commented 2 years ago

Thank you for your checks.

We run an own Gitea server where we host our moodle version. We pull from the official branch MOODLE_39_STABLE and merge it with our branch that includes our plugins. Ansible makes 1:1 copies from this branch to the instances excluding the instance specific file "config.php". We've never had problems with this process of update.

We've made no changes to any cron files like "cron_task.php". The error showed up when we ran "adhoc_task.php" via CLI. We noticed that there's a problem because notifications of board messages weren't sent any longer.

drachels commented 2 years ago

The, "Ansible makes 1:1 copies" might be what is causing the problem. It doesn't cause a problem when a plugin is adding some new files, but can cause problems when a plugin drops and no longer uses a file. I know that I recently dropped the locallib.php file which is where the MooTyper cron_task function used to be. Now, the cron_task function is in it's own file. I also changed some of the included lessons and layouts, some new some dropped. If Ansible just copied the new files to MooTyper without erasing all the old files, you can wind up with "extras" that can cause problems. I know that back in 2004 I was guilty of upgrading Moodle that way, until it crashed on the second upgrade I did. Luckily, I learned about and started using Git and even use it with Ansible to upgrade some of my servers and plugins.

drachels commented 1 year ago

With no follow up for nine (9) months, I can only presume that the "Ansible makes 1:1 copies" was the problem, so I am closing this ticket. Note: I also use Ansible and have had to change the way I do plugin upgrades, because of this very same problem.