Custom PHP application upgrades

Why custom applications are different

A WordPress site gets much of its PHP compatibility from plugin and theme updates. A custom application has no updates to install: every fix is in your own code. There are often no automated tests either, and the knowledge of how the system works lives in the code itself rather than in documentation.

Old frameworks and libraries

Many applications are built on a framework, a ready made base that developers build on. Code from the era of CodeIgniter 2 or 3, CakePHP 2, Zend Framework 1, Laravel 4 or 5, Yii 1 or Symfony 2 often can’t run on PHP 8 as it is. The framework either has to be patched, or upgraded one major version at a time. Applications written in plain PHP may use the removed database functions (mysql_ functions) directly.

Applications also carry libraries, ready made pieces of code bundled with them or pinned to an old version in the package list (Composer). Common examples are spreadsheet exports built on PHPExcel (since replaced by PhpSpreadsheet), old versions of PHPMailer for sending email, old PDF libraries, and payment gateway kits whose providers have since changed how they work. Abandoned libraries need replacing.

The database and the connections around it

The database server often needs attention too. Moving from MySQL 5.x to MySQL 8 or MariaDB can bring stricter rules (SQL modes) about empty dates and how results are grouped, new reserved words that clash with existing column names, and a change in how text is stored (utf8 versus utf8mb4).

Connections to other services matter as well. Payment providers and other outside services (APIs) retire old addresses and older security protocols (TLS versions), so an integration can fail even when the code itself is fine.

How we approach it

• Take stock of the code, the framework and every library it uses
• Run the application on the target PHP version in a private staging copy, while the live system keeps running
• Write a few simple checks (smoke tests) around the workflows your business depends on, such as logging in, creating a booking, generating an invoice and sending the emails, before changing anything, so we can prove they still work afterwards
• Use code analysis (PHPStan) and automated upgrade tools (Rector) to find and fix the bulk of known changes, followed by a careful manual review
• Decide component by component whether to patch, upgrade or replace

Sometimes the fastest safe path is a temporary compatibility layer, for example a small shim that maps the old mysql_ calls to their replacement (mysqli). That gets an old application running on a supported PHP version first, then the code is modernised properly in stages.

A scoped review comes first, then a plan and a fixed quote. We keep what already works and change what the new PHP version needs. Nothing changes on the live system until you approve it.

Gotchas we check for

• Missing array values (undefined index notices) that were silently ignored now show as warnings or errors and flood the logs
• Code that relied on loose comparisons changes behaviour without an error: 0 == "abc" is now false
• Names written without quotes (bare words) used to be treated as text and are now fatal errors in PHP 8
• Session and cookie settings that behave differently on the new server setup
• Hard coded file paths and settings that only exist on the old server
• Scheduled scripts (cron jobs) run by a different PHP version from the website
• The timezone default, which can shift dates and times
• allow_url_fopen being off on newer PHP setups, which silently breaks code that fetches other web addresses
• The character encoding of old data, which can turn accented letters and symbols into garbled characters