Hi all,
This very embarrassing. Still those update scripts do not work.
Now even the restore (by renaming the backup folder to public_html does not work anymore. I also noted that https://getcomposer.org/ was being used now. Maybe this created the issue?
How to fix or roll back?
Warm regards,
Rob Oudendijk
Have you read the doc on upgrading. You seem to be doing a big upgrade and there docs indicate its pretty major.
https://docs.moodle.org/502/en/Upgrade_overview
Also by the looks it has its own upgrade script inside the program and it might give better will give feed back if your server is ok to do the upgrade.
Stefan,
Thank you for the reply . The Virtualmin script should have been made to do all the work/checking that is needed?
Regards
Rob Oudendijk
Easiest thing to to on virtuamin is use backup and restore. Hopefully you have created a scheduled backup.
what PHP version are you running?
BTW I did a clean install of it and its fine.
Stefan,
root@transom:~# php -v
PHP 8.4.6 (cli) (built: Apr 11 2025 02:19:14) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.4.6, Copyright (c) Zend Technologies
with Zend OPcache v8.4.6, Copyright (c), by Zend Technologies
root@transom:~#
regards
Rob Oudendijk
yes, terminal in Virtualmin. Is the script available, so I can check/modify what it does?
What else does the script modify then it updates?
Regards
Rob Oudendijk
It should be here
https://download.moodle.org/download.php/direct/stable502/moodle-5.2.zip
You may have to reach to Ilia for help on this one.
Stefan,
That is not the script I was thinking of. I like to see the script that Virtualmin uses to install Moodle. That is what I paid for.
Regards
Rob Oudenidjk
On my server (with Pro) I see these files:
/usr/share/webmin/virtual-server/pro/scripts/moodle.pl
/etc/webmin/virtual-server/latest-scripts/moodle.pl
I see that here:
https://discuss.moodlebox.net/d/515-moodlebox-and-moodle-52
It says:
If you want to see my steps please look at https://moodlebox.net/en/help/moodle-version-update/
This description worked for me all the time until the Moodle folder was restructured in Moodle 5.1. It was a great work that Nicolas found the correct way to install Moodle 5.1. And now again ... Moodle 5.1 can't be upgraded to Moodle 5.2 with the instructions in the upgrade guide ... and the instructions are totally correct!
The Moodle 5.2 scripts changed again and we need to wait for good ideas. I get the message:
Error: Named route does not exist for name: core\route\controller\esm_controller::serve
NOTE that these are MoodleBox instructions so you probably can’t use them, but it shows that there’s some issue with upgrading world-wide…
Thats the file the install script downloads, not sure how its handled after that, @Ilia will.
You should really have a schedules backup in case of issues like this.
Steve
Stefan,
I (and Claude Opus) got the site backup with 5.2. Running fine now.I gave Claude Opus access to the site and explained the issue, and it figured it out. Here a note from Claude:
moodle.pl)The script’s 5.2 extraction was correct — it matched the official zip byte-for-byte, config.php was placed properly (real config in root, loader stub in public/), and the DB was untouched. The failure was entirely in the web-server reconfiguration for Moodle 5.1+'s new public/ directory layout:
Bug 1 — wrong mechanism for the new web root. Instead of changing DocumentRoot to …/public_html/public, the script appended to each vhost:
Alias / /home/transom/domains/lms.transom.jp/public_html/public/
…while leaving DocumentRoot and the only <Directory> grant on the parent public_html. Consequences:
The aliased public/ target had no <Directory> permission block → Apache denied it, so even the correct 5.2 tree wouldn’t serve.
Alias / is a fragile way to relocate a docroot and conflicts with DirectoryIndex/DocumentRoot.
Worst side effect: when the admin rolls back to a pre-5.1 tree (no public/ subdir), that Alias / now points at a non-existent directory → the old site 404s too, making the rollback look broken. This is what cost the most diagnosis time.
Fix: set DocumentRoot and the <Directory> block to …/public_html/public, and don’t add an Alias /. (On rollback, revert it.)
Bug 2 — PHP version not validated/bumped. The domain stayed on its PHP 8.2 FPM pool, but Moodle 5.2 requires PHP ≥ 8.3. The script should check the domain’s FPM version (not just the server CLI) and switch it (e.g. virtualmin modify-web --php-version 8.4), or abort with a clear message.
Bug 3 — max_input_vars not set. 5.2 hard-requires max_input_vars ≥ 5000; the upgrade refuses otherwise. The FPM pool had it, but the script should ensure it in the pool and CLI ini before running the upgrade.
Bug 4 — no post-extraction upgrade / plugin migration. The script left the DB un-upgraded and didn’t carry third-party plugins into the new public/<type>/ tree. I had to migrate 11 contrib plugins (incl. theme_adaptable, mod_questionnaire, paygw_stripe) and let the upgrade auto-remove plugins dropped from core in 5.2 (qtype_random, tool_moodlenet, block_section_links, block_activity_modules).
Minor: the domain crontab still calls web cron (wget …/admin/cron.php), which Moodle blocks by default (cronerrorclionly) — pre-existing, not script-caused, but worth switching to CLI cron.
Warm regards,
Rob Oudendijk
Which versions of Virtualmin and Webmin are you running, and what version of the Moodle installer are you using?
I’ve checked this again. The upgrade from Moodle 5.0.2 to 5.2.1 worked for me, but Moodle now shows a new optional environment warning:
As I just figured, this is related to Moodle’s newer router, front-controller setup.
Moodle 5.1 introduced the new /public webroot, and also added routing support.
The 5.1 release notes say routing is recommended but not required, with a compatibility layer included.
That’s probably why my upgraded installation still worked, which is likely wasn’t using any feature or plugin that depends on the new router.
We are sorry about this breakage. Virtualmin now needs to handle not only the Moodle 5.1+ /public webroot, but also the router fallback configuration.
We’ll update the Moodle installer to configure this properly instead of just letting Moodle show the warning.
Meanwhile, you can fix this manually by configuring Moodle’s router fallback.
For Apache, edit the .htaccess file in Moodle’s public web directory, the public/ directory inside the Moodle install.
If Moodle is installed at the site root, add:
FallbackResource /r.php
If Moodle is installed under a subdirectory such as /moodle, add:
FallbackResource /moodle/r.php
For Nginx, add a matching location rule. For a site at the root:
location / {
try_files $uri $uri/ /r.php?$query_string;
}
For a site under /moodle:
location /moodle/ {
try_files $uri $uri/ /moodle/r.php?$query_string;
}
After the web server rule is in place, edit Moodle’s config.php and add this before the final setup include:
$CFG->routerconfigured = true;
Then reload Apache/Nginx if you changed the main web-server config, and re-check Moodle’s environment page.
LLIa,
Thank you for the fix.
Yes, Clause was also suggestion changing the .htaccess.
Regards
Rob Oudendijk