Further to the above, I'm not sure how this adhoc task got scheduled. I didn't schedule it myself and I'm new to the instance I'm working on.
Could it be that this adhoc task was scheduled by an upgrade? Does anyone know?
Its the only adhoc task in the "task_adhoc" DB table.
Thanks.
Again ... not a developer ...
One of the changes in 3.9.x it runs through setting all defaults to core/plugins on a minor update ... at the tail end of upgrade.php a long pause while it does that. Think some have reported issues after an update and tracked it down to a setting gone missing - not verified nor reproduceable so ????
adhoc itself has been around since 3.0, however.
Might run it from command line with options to see what's up with it:
Ad hoc cron tasks.
Options:
-h, --help Print out this help
--showsql Show sql queries before they are executed
--showdebugging Show developer level debugging information
-e, --execute Run all queued adhoc tasks
-k, --keep-alive=N Keep this script alive for N seconds and poll for new adhoc tasks
-i --ignorelimits Ignore task_adhoc_concurrency_limit and task_adhoc_max_runtime limits
Example:
\$sudo -u www-data /usr/bin/php admin/cli/adhoc_task.php --execute
'SoS', Ken
The adhoc task was automatically scheduled when you upgraded your Moodle version to a version higher than 2019030100. At that moment the my_course_search area was renamed and some steps were needed to implement this change. Because these steps were not that simple and to speed up the upgrade, these steps were moved to an adhoc task to be completed in the background on a later moment.
Now this ad hoc task fails on the first step it has to do because the search area is not empty.:
if (!empty(self::get_search_area($areaid))) {
throw new \coding_exception("Area $areaid exists. Please use appropriate search area class to manipulate the data.")
Which search engine do you use? (solr - simple search) And what happens if you force a reindex?
sudo -u www-data /usr/bin/php search/cli/indexer.php --reindex --force
Thank you for that insight Renaat,
1) I'm using simple search (I have "index data" and "global search" set to "no" however)
2) I have run the re-index per the command you provided and there didn't seem to be any issues. Below is a snippet of what I think is the relevent section (let me know if you'd like the full output however).
Processing area: HTML block content No new documents to index. Processing area: Courses Processed 24 records containing 24 documents, in 0.1 seconds. Processing area: Course custom fields No new documents to index. Processing area: My courses Processed 24 records containing 24 documents, in 0.1 seconds. Processing area: Course sections Processed 77 records containing 77 documents, in 0.6 seconds.I have re-run crun and still the same error crops up per my original post.
First you need to find if this information can be deleted safely. Perhaps some plugin is still depending on it. But it is also possible that this information is stored with wrong permissions. Moodle throws an error because by now this area should be empty, and for some reason it is not.
Do you have access to the database? What is the output of
SELECT * FROM mdl_config_plugins WHERE plugin = 'core_search' AND name LIKE 'core_course_my_course%';
Personally, I would change the line that throws an exception 3 lines down to pinpoint which plugin is causing the error (in search/classes/manager.php):
$parts = self::parse_areaid($areaid);
$plugin = $parts[0];
$configprefix = $parts[1];
if (!empty(self::get_search_area($areaid))) {
throw new \coding_exception("Area $areaid exists. Please use appropriate search area class to manipulate the data. for plugin $plugin with prefix $configprefix.");
}
Thanks very much for your reply Renaat.
The output of the first query is 0 rows (it runs successfully though).
I also re-ran the query with "core_course_mycourse" though:
The out from the modified error message is
"Please use appropriate search area class to manipulate the data for plugin core_search with prefix core_course_mycourse."