OpenCart 3 PHP 8 Errors: What They Mean and How to Fix Them

This guide explains what the errors mean, how to tell which situation you're in, and the honest pros and cons of each option.

Which OpenCart 3 versions work with which PHP

The latest OpenCart 3 release is 3.0.5.1, which needs at least PHP 8.1. For comparison, OpenCart 4.1 needs PHP 8.0.2 or newer, and PHP 8.1 or newer from 4.1.0.4.

Find your OpenCart and PHP versions

OpenCart version: log in to your admin. The version is shown at the bottom of every page, for example "Version 3.0.3.8".

PHP version: look in your hosting control panel, usually in a section for PHP settings or the PHP version, or ask your host. If they've just moved you, they'll know which version you're on now and which you were on before.

Put the two together with the table above. If your store is on 3.0.3.8 or older and you're now on PHP 8, the warnings aren't a fault you can switch off. The code simply wasn't written for this PHP version.

What the errors mean

"Deprecated" warnings are PHP telling you that something works now but is being phased out. On their own they don't stop a page working, but they're printed onto the page if OpenCart is set to display errors, and they can break the checkout. OpenCart 3's checkout loads each step in the background and expects a clean reply. A warning printed in the middle of that reply means the checkout can't read it, so it stalls at the next step.

These are the ones you'll see most often on an older OpenCart 3 store:

• mysqli::real_escape_string(): Passing null to parameter #1 ($string) of type string is deprecated in system/library/db/mysqli.php. OpenCart passes an empty value to the function that makes text safe for the database. Since PHP 8.1, passing an empty (null) value to PHP's built-in functions triggers this warning. The latest 3.0 release checks for an empty value first.
• round(): Passing null to parameter #1 ($num) of type int|float is deprecated in catalog/model/catalog/product.php. A product with no approved reviews has no rating, and OpenCart tries to round that empty rating. It's the same PHP 8.1 rule, and it's fixed in the latest 3.0 release.
• Creation of dynamic property Request::$request is deprecated in system/library/request.php, and similar messages for Cart\Cart::$config and others. Since PHP 8.2, code is expected to declare its properties in advance rather than create them on the fly. The latest 3.0 release declares them.

If you see a different file in the message, especially one under extension or storage/modification, it's usually an extension or a modification rather than OpenCart itself.

Your three options

1. Ask your host to go back to an older PHP version

Pros: it's quick, usually a setting in the control panel, and the store works again while you plan a proper fix.

Cons: it's a stopgap. PHP only gets security fixes for a limited time, and PHP 8.1 and older no longer get any. PHP 8.2's security support ends on 31 December 2026, and PHP 8.3's on 31 December 2027. If your store is on 3.0.3.9 to 3.0.4.1, stepping back to PHP 8.3 is a reasonable short-term move. If it's older than 3.0.3.9, going back means PHP 7, which no longer gets security fixes, so treat it as days or weeks, not months. Some hosts won't offer old versions at all.

2. Update to the latest OpenCart 3 release

Pros: your admin, products, customers and orders stay as they are, and you get the PHP 8 fixes in the core code. For most stores this is the right answer.

Cons: it means replacing OpenCart's core files with the new release's, then checking every extension, theme and modification still works. Anything that was changed by hand in the core files has to be found and redone. Extensions that haven't been updated for PHP 8 will still throw warnings until they're updated or replaced.

3. Move to OpenCart 4

Pros: it's the current version of OpenCart, built for PHP 8.

Cons: it's a migration, not an update. Extensions and themes written for OpenCart 3 don't run on OpenCart 4 without being rewritten, because OpenCart 4 is structured differently. You'll need OpenCart 4 versions of everything your store relies on, or replacements, and the data moving across.

Why extensions and modifications break first

OpenCart's own code is one source. Your extensions and theme come from many different developers, and some were never updated for PHP 8. That's why the warnings often point at an extension, and why a store can still have problems after OpenCart itself is updated.

Modifications are a second layer. OpenCart applies them by building a cache of modified copies of its files. After you update OpenCart or change an extension, go to Extensions, Modifications and click Refresh to rebuild that cache, otherwise the store keeps running the old copies. If a modification was written for older code, it may no longer apply cleanly, and the refresh is where that shows up.

Check the error log

Turn on Log Errors and turn off Display Errors on the Server tab under System, Settings (edit your store). Customers then stop seeing warnings, and the errors are still recorded. You can read them under System, Maintenance, Error Logs. The file named in each message tells you whether it's OpenCart, an extension or a modification.

Turning off Display Errors hides the warnings from customers, but it doesn't fix the code, and it may not fix a stalled checkout. Use it to buy time, not as the fix.

Back up first, and test on a copy

Before changing PHP versions or updating anything, back up both the files and the database. OpenCart's own Backup / Restore, under System, Maintenance, only covers the database, so take a copy of the files through your host as well.

Then try the change on a copy of the store, not the live shop. Place a test order on the copy, check the admin and your order emails, and only then make the same change on the live store. If order emails stop after the move, see OpenCart not sending order emails.

If you'd rather not do this yourself, getting an OpenCart 3 store working on PHP 8 is a job I do as part of OpenCart fixes, with the price agreed before I start.