PHP Upgrade Check for OpenCart — what will break after switching to PHP 8.3, 8.4 or 8.5

PHP Upgrade Check for OpenCart is a module by the CatCode studio that answers one question before you change the PHP version: what in this shop will stop working? PHP 8.1 gets no security fixes after 31.12.2025, PHP 8.2 gets them only until 31.12.2026 (php.net dates), and over the years the shop has collected modules by different vendors, OCMOD and vQmod patches and a theme with edits. Switching PHP “to try it” on a live shop means risking an error page instead of a product or the checkout.

The module reads every PHP file of the shop — the OpenCart core, extensions, the code of OCMOD and vQmod patches, themes, libraries — and compares it with what PHP 7.0 … 8.5 removed or changed, following the official php.net migration guides. For the PHP version you pick, every extension, patch and theme gets a verdict, and every finding comes with the file, the line, the code and the fix. Nothing is executed and nothing is changed.

What the shopper sees

The shopper never sees the module: there is no code, event or patch of it on the storefront. Its job is to keep the shopper from seeing something else: an error page instead of a product, a blank page or a checkout stuck at the payment step after the host switched PHP.

A shop breaks in different ways after a PHP switch. A function PHP removed (each(), create_function(), mysql_*) is simply not found, and the page stops with a fatal error. A deprecated function in OpenCart 4.0 – 4.1.0.3 with “Display errors” off sends the visitor to the error page. Some functions keep working but return a different result. The module finds these places before the switch, so you fix them on your own schedule rather than after shoppers complain.

What the admin gets

The System → PHP Upgrade Check menu entry with four tabs: Overview, Report, Error log (Pro) and Settings. The entry appears right after installation.

Overview

• This server now: the PHP version and its support status by the php.net dates, the “Check the newest release on php.net” button, the OpenCart version and the minimum PHP it demands (from system/startup.php), the database, the ionCube Loader, the PHP extensions OpenCart needs, memory_limit and max_execution_time.
• What this OpenCart does with a “Deprecated” notice: the module reads the error handler of your shop and says in plain words whether a deprecated function only lands in the log or sends the visitor to the error page.
• Scan: the PHP version picker (7.4 – 8.5), the “Scan now” button with progress and Stop, the date of the last scan, the number of files and the files that could not be read.
• Result: how many extensions and parts of the shop will break, need a PHP extension, give other results, are encoded, have only notices or are ready; the core files on their own line; the “Needs attention first” list.

Report

A “what — verdict — found” table for every extension, patch, theme and part of the core. “Details” opens the findings: the level, the file and line, the code itself, what changed and in which PHP version, the fix, and a “What to do” box — ask the vendor for a version for the PHP you need or let a developer fix the lines. The PHP version is switched with buttons without a new scan; the “Show ready ones”, “Show not installed” and “Show libraries” switches add what is hidden by default.

OCMOD and vQmod patches

A patch has no files of its own: its code is inserted into someone else’s file. The module reads the code of every OCMOD insertion from the database and every vQmod XML, and shows the finding with the patch name and the line of the file it changes — so you see straight away which module to ask for an update.

Error log (Pro)

For what only shows while the shop runs. Switch a copy of the shop (or the shop itself for a quiet hour) to the new PHP, go through the storefront, the cart, the checkout and the admin, then come back here: the module reads the OpenCart error.log and the PHP error_log, groups identical messages, counts how many times and when last, and traces each one to an extension, a patch or the core.

Settings

• Target PHP by default (8.3), whether to scan the core files and the vendor/ libraries.
• Extra folders to scan as well and paths to skip (an old copy in system/library, for example).
• Licence: a 7-day Pro trial or the key after purchase.

How it works, step by step

1. File list. admin/ (including a renamed admin folder), catalog/, system/ without cache, logs, sessions and uploads, extension/ in OpenCart 4, PHP files in the shop root, vendor/ libraries (also outside the shop root), vQmod, the code of OCMOD patches from the database and the folders you add.
2. Groups. Every file belongs to someone: an OpenCart 4 extension (name, version and author from the installer records or install.json), an extension from the OpenCart 3 installer, the core (by the official file list of your OpenCart line), an extension that ships with OpenCart (installed or not), a third-party extension, a theme, a library or “other files”.
3. Reading. Every file is parsed with the PHP tokenizer — the same one PHP uses to read code — without running it. Large files are read with the memory_limit of the server in mind, and the ones that do not fit are listed as “check it by hand”.
4. Rules. 92 functions, 6 whole extensions (mysql, mssql, mcrypt, imap, pspell, oci8), 30 constants and syntax and behaviour rules from the php.net migration guides for 7.0 … 8.5: each() and create_function() (removed in 8.0), $str{0} (8.0), strftime() (deprecated in 8.1), “${var}” in strings (8.2), a “Type $x = null” parameter without “?” (8.4), curl_close() and imagedestroy() (deprecated in 8.5) and more.
5. No false alarms. An extension that is not installed is counted apart — its code does not run. A database driver config.php does not use stays silent. A function the shop declares itself (a polyfill) is not reported as removed. A line behind a PHP version check (PHP_VERSION_ID, version_compare, function_exists) is not counted where it never runs.
6. Verdict. For the chosen PHP version every finding gets a level: will break, stops the page, needs an extension, result changes, cannot check, notice. The verdict of a group is the worst level of its findings. On OpenCart 4.0 – 4.1.0.3 with “Display errors” off a deprecated function counts as “Stops the page”.
7. Then it is your turn. You switch the PHP version in the report without a new scan, update or fix the extensions and scan again until the verdict says “Ready”.

What is tested and what is not

Tested locally on four OpenCart versions from the official archives: 4.1.0.3 (mysqli), 4.0.2.3 (pdo), 3.0.5.0 and 2.3.0.2, on PHP 5.6, 7.0, 8.1, 8.3 and 8.5, with “Display errors” on and off. Every page and every action of the module — without a single PHP message in the log. The verdicts were checked against the expected ones on test extensions and real modules (Mollie 14.1.2, Mollie 9.4 with vQmod 2.6.6, d_quickcheckout). Awkward files — unreadable, binary, with a syntax error, in cp1251, with a BOM, nested 3,000 levels deep, symlink loops, files over 768 KB — the scan still reaches the end and lists what it could not read. A big shop — 60,836 files in 180 seconds. In the tests a test server stood in for the licence server.

Limits worth knowing. The scan is static: what only shows while the shop runs (null passed to a string function, an undefined array key, a float turned into an integer) it does not see — that is what the Pro “Error log” page is for. The rule about properties created on the fly (PHP 8.2) only checks classes without a parent class, __set() and traits, so it can miss some cases. Findings in vendor/ libraries matter only if something uses the library, so they are hidden by default. We have not tested real encoded modules by other vendors — only our own encoded test file. Not run live: OpenCart 4.0.0.x – 4.0.1.x and 4.1.0.4, 3.0.0 – 3.0.3.x (the core file lists cover them), MySQL 5.7, OCMOD packages for OpenCart 4, hosts without outgoing connections (there the php.net button just says it did not answer). The rules go up to PHP 8.5; later PHP versions will need a module update.

Under the hood

• Read-only. Files are parsed with the PHP tokenizer and never included or executed; the module writes to nobody’s files.
• One admin event — the menu entry under System. No storefront events, no OCMOD and no core edits.
• Own tables for the scan, the queue, groups, findings and marks; uninstalling removes them.
• AJAX steps of 6 seconds with a queue in the database: the scan does not hit max_execution_time and keeps going until it reaches the end.
• The module itself raises no PHP notices. On OpenCart 4 with “Display errors” off a single warning would send the admin to the error page, so every file access is silent, and an unreadable file simply lands on the list.
• Core file lists come from the OpenCart tags on GitHub: 2.0.0.0 – 2.3.0.2, 3.0.0.0 – 3.0.5.1, 4.0.0.0 – 4.1.0.4.
• php.net: the support dates of PHP versions are built in; the newest release is requested only on a button click and cached for a day.
• The licence lives in its own settings group, so saving the settings never touches it.

How to install

1. OpenCart 4: Extensions → Installer → upload cc_phpupgrade.ocmod.zip (keep the archive name) and click Install. OpenCart 3: Extensions → Installer → cc_phpupgrade-oc3.ocmod.zip. OpenCart 2.3: copy the contents of the upload/ folder of cc_phpupgrade-oc2.ocmod.zip to the shop root.
2. Extensions → Extensions → Modules → PHP Upgrade Check → Install.
3. System → PHP Upgrade Check: pick the PHP version you are moving to and click “Scan now”.
4. Open “Full report” and start with the “Needs attention first” list.
5. For Pro: Settings → Licence — the 7-day trial or the key from the e-mail after payment.