Joomla 500 error after a PHP update: what to check first

Your hosting company moved the server to a newer PHP version, or you changed it yourself in the control panel, and the site now shows a blank page or "500 Internal Server Error". Nothing on the site was touched, which is what makes it confusing. PHP changed underneath it, and some piece of code on the site uses something the new version no longer accepts. The fix is usually small once you know which piece it is, so most of the work is finding it.

Get the site back first

If the site brings in enquiries or sales, switch PHP back to the version it ran on before. Most hosts let you set the version per domain (in cPanel it is called MultiPHP Manager; other panels have an equivalent under PHP settings). The site should return within a minute.

This buys time and fixes nothing. Old PHP versions stop receiving security fixes, PHP 8.1 stopped at the end of 2025, and hosts remove them on their own schedule, usually with one email of warning. If your host has already removed the old version, skip this step.

Read the error before touching anything

The 500 page tells you nothing. The real error is one line of text, and that line names the file that failed. Disabling extensions at random until the site comes back can take an afternoon. Reading the line takes two minutes. There are three places to find it.

The PHP error log of your hosting account. In cPanel it is under Metrics, Errors. Many hosts also write a file called error_log into the site root or into the administrator folder.

Joomla's own error display. In the administrator, open Global Configuration, go to the Server tab and set Error Reporting to Maximum. If the administrator is down as well, which is common, the same setting is a line in configuration.php in the site root:

public $error_reporting = 'maximum';

Reload the broken page. From Joomla 4 onwards, setting public $debug = true; as well shows the full call stack, which is the list of files that were running when it failed. Set both back when you are done. With error display on, every visitor can read your server's file paths.

Joomla's log folder, administrator/logs on current versions and logs in the site root on some older ones.

What you are looking for reads like this:

PHP Fatal error: Uncaught Error: Call to undefined function create_function()
in /home/account/public_html/plugins/system/example/example.php:87

The path is the answer. plugins/system/example is a plugin. A path starting with templates/ is your template. components/com_something or modules/mod_something is an extension. A path inside libraries/ needs a second look. It can mean the Joomla version is too old for this PHP version, but just as often an extension has handed bad data to Joomla's own code and the error surfaces there. Read down the call stack: the first file in it that is not part of Joomla itself is usually the one responsible.

What usually breaks

An extension nobody maintains any more. PHP 8.0 removed functions that old code relied on: create_function(), each(), get_magic_quotes_gpc(), and the $text{0} way of reading a character from a string. It also turned some old warnings into fatal errors. The most common is count() called on null, which happens when old code counts a variable that was never filled. (An empty array is fine; null is not.) Extensions last updated before 2020 are the usual suspects.

The template. Older commercial templates ship with their own framework and bundled libraries, and those age exactly like extensions do. If the path in the error starts with templates/, the template vendor may have a newer version. If the vendor is gone, the template has to be repaired or replaced.

Joomla itself. Joomla 3.10 officially supports PHP up to 8.0. It often keeps running on newer versions with error display switched off, but nobody tests or fixes it there, and its extensions fail first. Joomla 5 needs at least PHP 8.1 and Joomla 6 needs 8.3, so the mismatch can also go the other way: a host that moves you to an older or differently built PHP can break a current site.

A PHP module missing on the new version. Hosts build each PHP version separately, and the new one may lack mysqli, gd, intl, zip or simplexml. The error then reads Call to undefined function mysqli_connect() or Joomla reports that it cannot connect to the database although the password is correct. This one is fixed in the hosting panel or by the host's support, not in Joomla.

Encoded extensions. Some commercial extensions are encrypted with ionCube and need a loader that matches the PHP version. The error message says so in plain words. The host installs the loader, or the vendor supplies a build for your PHP version.

A word on "Deprecated" lines. PHP 8.1 and 8.2 added many deprecation notices. They look alarming and fill the log, but they do not cause a 500 error. They can break a page in a different way: if error display is on, the notices are printed above the page and can corrupt the layout or a form's response. Turn the display off and treat the notices as a to-do list for later.

Turn off the piece that fails

If the failing code is a plugin or module, disable it and check that the site returns. Disable, do not delete. Deleting the folder leaves the database entry behind and loses the settings.

When the administrator works, do it under System, Manage, Extensions. When it does not, the switch is a column in the database. With your table prefix in place of abc_:

UPDATE abc_extensions SET enabled = 0
WHERE type = 'plugin' AND folder = 'system' AND element = 'example';

From Joomla 4 there is also a command line route, if you have SSH access:

php cli/joomla.php extension:list --type=plugin
php cli/joomla.php extension:disable 10234

The number is the extension's ID from the list. Be aware that the command line often runs a different PHP version from the website, so a command that works there proves nothing about the site.

Then look for a current version of the extension. Commercial ones usually need an active subscription to download it. If the extension is abandoned, the choice is between replacing it with a maintained one and repairing the code. A repaired third-party extension is yours to maintain from that day on, so repair makes sense mainly when nothing maintained does the same job.

When it is more than one extension

If the error points into Joomla's own files, or fixing one extension just reveals the next, the PHP change has only exposed a larger problem. The site is one or more major versions behind: Joomla 3 has been out of support since August 2023 and Joomla 4 since October 2025. Patching around each error keeps the site alive for a few months at a rising price.

At that point the sensible route is to stay on the old PHP version for as long as the host allows, copy the site to a staging address, and do the upgrade there properly.

Before the next PHP change

PHP moves to a new version every year and hosts follow. The next switch does not have to be a surprise. Copy the site to a staging subdomain, change PHP there first and click through the pages that matter: the home page, an article, a form submission, a login, saving something in the administrator, and any page that depends on a large extension. Then read the log. PHP marks a feature as deprecated some time before removing it, usually in a later major version, so the "Deprecated" lines are an early list of code that will need attention. Nothing on it is urgent, and all of it is cheaper to fix before it turns into an error.

If the site has fallen too far behind for that to be a quick check, our upgrade and migration service starts with a written roadmap of what can move, what has to change and what it will cost.