Quick answer: Moodle’s environment report blocks an upgrade when the server cannot safely run the target release. Do not suppress those checks. Match each warning to the PHP binary, database server or web-server configuration that Moodle is actually using.
PHP version or 64-bit error
Moodle 5.3 requires 64-bit PHP 8.3 or 8.4. Upgrade the PHP runtime used by the web server and the CLI. Restart PHP-FPM or the web server, then verify both versions. PHP 8.5 is not listed as supported for this release.
Missing sodium extension
Install or enable the sodium extension for the active PHP build. Check the loaded configuration file rather than editing a guessed php.ini. Restart the relevant service and confirm the module from both web and CLI contexts.
max_input_vars below 5000
Set max_input_vars = 5000 or higher in the configuration used by Moodle. Confirm the effective value after restarting PHP. Managed hosting may require a control-panel setting or provider request.
Database version failure
5.3 requires MySQL 8.4, MariaDB 11.4.0 or PostgreSQL 17, with documented alternatives for Aurora MySQL and SQL Server. A database upgrade is a separate high-risk project: test application compatibility, backups, replication and rollback before changing production.
404 or 403 after deploying new code
From Moodle 5.1 onward, the web document root must point to the public/ directory. A 404 after upgrade commonly means Apache, Nginx or the hosting panel still serves the repository root. Correct the web root; do not expose internal directories as a shortcut.
Re-run the check safely
Clear opcode caches if necessary, reload the environment page and verify cron separately. Record each changed setting so the production and staging environments stay aligned.
Related Moodle 5.3 guides
- Moodle 5.3 LTS: what is new?
- How to upgrade to Moodle 5.3
- Moodle 5.3 server requirements
- Moodle 5.3 theme compatibility checklist
Frequently asked questions
Can environment checks be bypassed?
They should not be. The checks represent platform requirements that protect the upgrade and future supportability.
Why does Moodle still report the old PHP version?
The web server, PHP-FPM and CLI can use different binaries and configuration files. Confirm the active version in every execution context.
Why did the site become 404 after deployment?
A common cause is an unchanged document root. Moodle 5.3 expects web traffic to be served from the public directory.
When to bring in specialist help
Use an experienced Moodle administrator or hosting engineer when the work changes database major versions, authentication, production routing, custom plugins or a heavily modified theme. Record the change, test it away from production and keep a named rollback owner.
Final recommendation
Use a staging site, rely on version-specific evidence and keep a tested rollback path. Moodle 5.3 is a strong long-term target, but a controlled upgrade is more valuable than an early upgrade that breaks teaching workflows.
Source check: Verified on 21 October 2026 against official 5.3 server requirements and Moodle installation and public-directory guidance.
