If Joomla stopped working immediately after a PHP change, start with the first relevant server error. A blank page does not identify the cause, and changing several settings at once makes the evidence harder to follow. Preserve the error, establish which runtime changed, then choose a recovery path that does not leave a known security gap open.
First: separate availability from security
Ask the host whether this was a patch within the same branch or a change between branches, such as PHP 8.2 to 8.4. Record the previous and current build, the time of the switch, and whether any Joomla or extension updates happened in the same window. A patch and a branch upgrade need different compatibility investigations.
If the change addressed an urgent vulnerability, switching back may reintroduce it. Ask whether the earlier environment has a vendor security fix. When no patched compatible environment is available, agree temporary isolation or a maintenance response while the developer repairs the application. Do not treat a vulnerable rollback as the final resolution.
Find the runtime serving the affected domain
Hosting panels may assign a different PHP version to each domain. The command-line PHP used by cron can also differ from the PHP that serves web requests. Record the domain’s PHP handler and pool, the web runtime, and any scheduled-task commands. If administrator access still works, System → System Information provides a useful application-side check.
Use the first relevant error, not the last symptom
Keep production error display off. Use the host’s private error viewer or PHP error log, reproduce one failing request, and note the timestamp. Preserve the full exception and stack trace in a private ticket; remove passwords, tokens and personal data before sharing extracts.
| Symptom | Next check | Avoid |
|---|---|---|
| Blank page or HTTP 500 | PHP error log and web-server log for the same request | Publishing detailed errors to visitors |
| Only one component fails | The first failing extension, override or dependency in the trace | Updating every extension before preserving evidence |
| Frontend works; jobs fail | Cron’s PHP executable, modules and working directory | Assuming the website PHP also runs CLI jobs |
| Warnings fill the page | Source of deprecated behavior and logging configuration | Calling hidden warnings a compatibility repair |
Reproduce on an isolated copy
Take a file and database backup and confirm the restoration route. Build staging with the intended PHP branch and required modules. Block public indexing and restrict access. Disable real outbound mail, recurring jobs, webhooks and live payments before opening the copy. Production credentials copied into staging need particular care.
Compare the installed Joomla version with its own requirements, then inventory the template, framework, overrides, components, modules and plugins. Check each vendor’s release notes. A compatible Joomla core does not establish compatibility for abandoned extensions or custom code.
Fix in small, reviewable steps
- Apply supported extension releases that explicitly address the target environment.
- Re-test after each coherent change and preserve the original error for comparison.
- For custom code, review the migration guides for every PHP branch crossed. Record fixes in version control.
- If an extension is abandoned, compare replacement, a scoped repair and Joomla migration. Document future maintenance ownership.
- Keep overrides or plugins separate from vendor files where practical. Record unavoidable vendor patches so updates do not silently erase them.
Test beyond the homepage
Agree a short acceptance list with the site owner: admin login, content save, uploads, contact email, search, member access, checkout and scheduled imports as applicable. Use sandbox payments and controlled recipients. Recheck logs after the tests and distinguish existing unrelated errors from regressions.
Before deployment, account for orders, users and content created since staging was copied. Do not overwrite the live database with an old staging copy. After the switch, verify the active runtime again, run the acceptance list and retain the backup for the agreed period.
When upgrading Joomla belongs in the plan
If the current core, template or essential extensions cannot run on a supported PHP branch, a PHP-only fix may be a short-lived investment. Compare it with a Joomla migration. For an immediate vulnerability, verify patch status first rather than waiting for a longer redesign.
References
- PHP 8.3 migration guide and the guides for subsequent branches you cross.
- Joomla technical requirements — select the version actually installed.
- cPanel MultiPHP Manager.
Need help with your site?
Send us the URL, hosting provider and the problem you need resolved. Our Joomla PHP upgrade and compatibility service starts with a scoped assessment and a written quote.