Why Your Website Can Break After a PHP Upgrade
Keeping PHP up to date is an important part of maintaining a secure and reliable website. Newer versions usually offer better performance, continued security support and improvements that benefit modern applications. However, changing the PHP version can occasionally cause a previously working website to display errors, lose certain features or stop loading altogether.
This does not normally mean that the PHP upgrade itself has gone wrong. More often, part of the website was written to depend on older PHP behaviour that has since been changed or removed. Themes, plugins, third-party libraries and custom code can all introduce compatibility problems, particularly when a website has not been actively maintained for several years.
PHP changes over time
PHP is continually developed. New versions introduce features, improve performance and fix security vulnerabilities, but they also remove old functions and tighten rules around how code should behave. A piece of code that PHP once accepted with little complaint may generate a warning or fatal error in a newer version.
Some changes are relatively minor. They may produce notices in an error log without affecting what visitors see. Others are significant enough to prevent an entire page—or the whole website—from loading. This is particularly likely when upgrading across several major PHP versions at once, such as moving directly from PHP 7.4 to PHP 8.3 or 8.4.
Older versions of PHP were sometimes forgiving of poorly defined variables, incorrect data types or functions being used in unintended ways. Newer versions tend to enforce these rules more strictly. Code that was technically incorrect but continued to work can therefore fail as soon as the server begins processing it under a newer PHP version.
Themes may contain outdated code
A website theme is not purely responsible for colours, fonts and page layouts. In systems such as WordPress, themes can contain a considerable amount of PHP code controlling templates, menus, forms, custom content and integrations with other services.
If a theme has not been updated recently, it may call PHP functions that are deprecated or no longer available. It might also rely on behaviour that changed between PHP releases. The result can range from a small layout problem to a completely blank page.
Custom-built and heavily modified themes require particular attention. Even if the original theme developer has released a PHP-compatible update, those improvements may not be present in the customised version used by the website. Updating the parent theme will not necessarily correct problems inside custom templates or a child theme.
Plugins can create compatibility problems
Plugins are one of the most common causes of problems after a PHP upgrade. Each plugin is a separate collection of code, often developed and maintained by a different company or individual. A website with dozens of plugins is therefore dependent on dozens of developers keeping their software compatible with current PHP releases.
Actively maintained plugins will usually be tested against supported PHP versions. Older, abandoned or rarely updated plugins may not be. A plugin can appear to work perfectly for years simply because the hosting environment has remained unchanged. Once PHP is upgraded, its outdated code may suddenly become visible as the weak point.
The failure does not always affect the whole website. A contact form may stop sending, an ecommerce checkout may fail, or a particular section of the administration area may become inaccessible. These partial failures can be more difficult to notice than a completely broken site, which is why testing should cover important functions rather than simply confirming that the homepage loads.
Third-party libraries may be hidden dependencies
Many themes, plugins and custom applications rely on third-party PHP libraries. These provide ready-made functionality for tasks such as sending emails, processing payments, creating PDF files or communicating with external services.
Website owners may not even know these libraries are present because they sit inside another package. If the theme or plugin includes an old copy of a library, that dependency may be incompatible with the new PHP version even when the surrounding code looks current.
Modern PHP projects commonly manage these packages through Composer, which makes dependencies easier to identify and update. However, upgrading them can introduce further compatibility questions. Newer library versions may change their own functions and requirements, meaning that the website’s custom code must sometimes be updated at the same time.
Custom code is easily overlooked
Custom PHP code is often the most difficult part of an upgrade because there may be no external developer providing updates. It could have been written years ago by a previous agency, added directly to a theme or placed in a small site-specific plugin that nobody remembers exists.
This code may perform an essential job such as calculating prices, connecting to a customer database or changing how users log in. If it depends on removed PHP functions or outdated libraries, upgrading PHP can expose the problem immediately.
The age of the code does not automatically mean it is unsafe or incompatible, but older code should be reviewed before a major PHP change. Documentation may be limited, and the original developer might no longer be available, so additional time may be needed to understand what the code does before changing it.
A PHP upgrade can reveal existing problems
It is tempting to blame the new PHP version when a website breaks, but the upgrade often reveals a problem that was already present. The website may have been relying on obsolete code, unsupported plugins or programming mistakes for a long time. The older server environment simply allowed those weaknesses to remain hidden.
Returning temporarily to the previous PHP version may restore the website, but it should be treated as a short-term recovery measure rather than a permanent solution. If the old version has reached end of life, it will no longer receive normal security fixes. Remaining on it indefinitely leaves both the website and its hosting environment increasingly exposed.
The better solution is to identify the incompatible component, update or replace it, and correct any custom code that still depends on obsolete PHP behaviour.
Test the upgrade before making it live
A PHP upgrade should ideally be tested on a staging copy of the website first. This creates an opportunity to discover problems without interrupting the live site. Error logs can be checked, outdated components identified and important functions tested under the proposed PHP version.
Testing should include more than browsing a few public pages. Forms should be submitted, searches performed, user accounts accessed and ecommerce transactions tested where applicable. Scheduled jobs, email delivery, integrations and administration tools may use PHP code that is not triggered during an ordinary visit.
A current backup should also be available before any server changes are made. Although changing PHP does not normally alter website data, a reliable backup provides a clear recovery point if other updates or code changes are required as part of the process.
Keeping the site maintained makes upgrades easier
PHP upgrades become much more difficult when several years of maintenance have been postponed. Themes, plugins and libraries may then need to jump across multiple major releases, each with its own compatibility changes.
Regular maintenance keeps the gap smaller. Updates can be applied incrementally, abandoned software can be replaced before it becomes urgent, and custom code can be reviewed while its purpose is still understood. This turns PHP upgrades into routine maintenance rather than emergency repair work.
A broken website after a PHP upgrade does not mean that upgrading was a mistake. It means that part of the site was not ready for the modern environment it now needs to run in. With proper testing and ongoing maintenance, those dependencies can be found and corrected before they cause disruption.