OpenCart 3.0.x.x PHP versions support

We have discussed on github whether to update some of system/storage/vendor libraries, to have support for the latest PHP 8.4 version. This would affect the 3.0.x.x branch of OpenCart, starting with upcoming 3.0.4.2. But as it turns out, not all 3rd party vendor libraries are able to support both PHP 7.4 and all of the PHP 8.0 to 8.4 versions at the same time. E.g., the latest twig/twig package, while supporting PHP 8.4, has dropped support for PHP 8.1 or lower.

This means, we have have to drop support for older PHP versions such as 7.x or 8.0 in future OpenCart 3.0.x.x releases.

Any thoughts on this? What do you think? How should we proceed?

Could upgrade Twig to 3.11.3. There is a 3.11.x on GitHub branch that suggests it supports PHP 7.4 to 8.4 and also the latest security patches.

JNeuhoff wrote: ↑

Sun Jun 22, 2025 12:39 am

This means, we have have to drop support for older PHP versions such as 7.x or 8.0 in future OpenCart 3.0.x.x releases.

Any thoughts on this? What do you think? How should we proceed?

It sounds to me like dropping support for older PHP versions is the way to go.

ADD Creative wrote: ↑

Sun Jun 22, 2025 11:55 pm

Could upgrade Twig to 3.11.3. There is a 3.11.x on GitHub branch that suggests it supports PHP 7.4 to 8.4 and also the latest security patches.

I was experimenting with this twig version, told composer.json to use "twig/twig": "^3.11", for some unknown reason, it picked up twig/twig 3.19.0. I ran the composer under PHP 8.4, may try it again under PHP 7.4, if we still want support for PHP 7.4. Other packages like scssphp/scssphp or cardinity/cardinity-sdk-php will likely require newer versions, too, to satisfy PHP 8.4 demands.

I think We need to stop dragging PHP 7 along. It’s obsolete, insecure, and limits progress. PHP 8+ brings speed, stability, and modern tools we should be using. Dropping PHP 7 is overdue. Let’s focus on the future, not legacy baggage.

If you do switch it to require later PHP 8 versions, I would suggest making it OpenCart 3.0.5.0 or 3.1.0.0 instead. That way you could say "use OpenCart 3.0.4.1 if you're using PHP 7 to 8.1, or OpenCart 3.0.5.0/3.1.0.0 for PHP 8.2 or later".

Not sure if others agree, but a major PHP requirement that is implemented on a minor point release seems confusing to me.

On ADD Creatives point - I am currently building a new site for a client on on 3.0.4.1 and php8.4 with a few minor changes to the current twig libraries without upgrading and not run into any issues switching back and forth from 7.4 to 8.4. I would agree that 8.4 support is better going forward and that it would be better to drop 7.4 rather than not support 8.4.

On Jonathan's point - I agree. Please could you consider 3.1.0.0 or 3.0.5.0 if you decide to drop php7.4 support

JNeuhoff wrote: ↑

Mon Jun 23, 2025 8:44 pm

ADD Creative wrote: ↑

Sun Jun 22, 2025 11:55 pm

Could upgrade Twig to 3.11.3. There is a 3.11.x on GitHub branch that suggests it supports PHP 7.4 to 8.4 and also the latest security patches.

I was experimenting with this twig version, told composer.json to use "twig/twig": "^3.11", for some unknown reason, it picked up twig/twig 3.19.0. I ran the composer under PHP 8.4, may try it again under PHP 7.4, if we still want support for PHP 7.4. Other packages like scssphp/scssphp or cardinity/cardinity-sdk-php will likely require newer versions, too, to satisfy PHP 8.4 demands.

^3.11 would assume semantic versioning where only a change in the major number would indicate an incompatibility. So that would give any version < 4.0. ~3.11.3 or 3.11.* should work.

scssphp/scssphp will be an issue The same version 2.0 added support for PHP 8.4 at the same time as dropping support for PHP 8.0 and lower. See https://github.com/scssphp/scssphp/issues/773.

Johnathan wrote: ↑

Mon Jun 23, 2025 9:52 pm

If you do switch it to require later PHP 8 versions, I would suggest making it OpenCart 3.0.5.0 or 3.1.0.0 instead. That way you could say "use OpenCart 3.0.4.1 if you're using PHP 7 to 8.1, or OpenCart 3.0.5.0/3.1.0.0 for PHP 8.2 or later".

Not sure if others agree, but a major PHP requirement that is implemented on a minor point release seems confusing to me.

Agree with you.
3.0.5.0 or 3.1.0.0 indicates a major update (which it is if we drop support for older versions php 8.x) and will make it clear to all users.

OSWorX wrote: ↑

Tue Jun 24, 2025 4:41 pm

Johnathan wrote: ↑

Mon Jun 23, 2025 9:52 pm

If you do switch it to require later PHP 8 versions, I would suggest making it OpenCart 3.0.5.0 or 3.1.0.0 instead. That way you could say "use OpenCart 3.0.4.1 if you're using PHP 7 to 8.1, or OpenCart 3.0.5.0/3.1.0.0 for PHP 8.2 or later".

Not sure if others agree, but a major PHP requirement that is implemented on a minor point release seems confusing to me.

Agree with you.
3.0.5.0 or 3.1.0.0 indicates a major update (which it is if we drop support for older versions php 8.x) and will make it clear to all users.

Yep also agreed. Dropping support for PHP 7 is a biggie and so it needs a big-ish version number jump.

OK, it seems the majority sees it as an important enough change to justify the next version to be 3.0.5.0.
I have tested some upgraded composer.json settings with later versions for the required packages, and so far this one seems to be the best one:
It will require PHP 8.2 or later, and with the exception of cardinity/cardinity-sdk-php , there are no deprecation messages. As regards cardinity/cardinity-sdk-php (which is only needed for the Cardinity payment extension), I asked the author of this package to add proper support for PHP 8.4, see the github issue here.

Can someone else please do a quick test for the updated system/storage/vendor please?

divido/divido-php should be removed as the payment extension was removed in 3.0.4.0.

ADD Creative wrote: ↑

Wed Jun 25, 2025 12:11 am

divido/divido-php should be removed as the payment extension was removed in 3.0.4.0.

Yes, you are right.

I also noticed when using the latest twig/twig package, one of packages used by it, namely the symfony/filesystem, requires PHP 8.2 or later, and won't work with PHP 8.1 or earlier, whereas twig/twig or any of the other packages would have been just fine with PHP 8.1 onwards. So it looks like support for PHP 8.1 or earlier will have to be dropped, and the minimum PHP version for next OC 3.0.5.0 will have to be 8.2, or later.

So we are looking at these supported PHP versions:
OpenCart 3.0.3.8 or 3.0.3.9: PHP 7.3 (possibly earlier ones which I haven't tested), 7.4
OpenCart 3.0.4.0 or 3.0.4.1: PHP 7.4, 8.0, 8.1, 8.2, 8.3
OpenCart 3.0.5.0: PHP 8.2, 8.3, 8.4

There is a polyfill for php8.0

JNeuhoff wrote: ↑

Wed Jun 25, 2025 5:01 am

I also noticed when using the latest twig/twig package, one of packages used by it, namely the symfony/filesystem, requires PHP 8.2 or later, and won't work with PHP 8.1 or earlier, whereas twig/twig or any of the other packages would have been just fine with PHP 8.1 onwards. So it looks like support for PHP 8.1 or earlier will have to be dropped, and the minimum PHP version for next OC 3.0.5.0 will have to be 8.2, or later.

So we are looking at these supported PHP versions:
OpenCart 3.0.3.8 or 3.0.3.9: PHP 7.3 (possibly earlier ones which I haven't tested), 7.4
OpenCart 3.0.4.0 or 3.0.4.1: PHP 7.4, 8.0, 8.1, 8.2, 8.3
OpenCart 3.0.5.0: PHP 8.2, 8.3, 8.4

symfony/filesystem 6.4 still supports PHP 8.1 and is still maintained. It's a requirement of scssphp/scssphp which allows "^5.4 || ^6.0 || ^7.0", so should be no issue supporting PHP 8.1.

The bigger issue is with symfony/validator it's a requirement of cardinity/cardinity-sdk-php (4.0||^5.4.43||^7.1.4), why it doesn't allow 6.x is strange and a bit of a pain. So it will need version 5.4.x, which is not maintained, but I do believe it will still get security patches as it's part of Symfony.

Also I don't think it's wise upgrading the cardinity/cardinity-sdk-php without testing the major version change doesn't break the Cardinity payment extension. If Cardinity aren't maintaining it, it may be best just to remove it as it seems to be the cause of most of the Composer issues. Or just leave the old SDK and dependencies the same as done with Braintree and Wechat.

Your would also want to use "twig/twig": "^3.11.3" instead of "twig/twig": "^3.0" to ensure it will have the latest security patches.

@AddCreative: I think if I don't hear back from the author of the Cardinity payment extension, I might remove it altogether from the OC core.

I just tested the "scssphp/scssphp": "^1.13" and it gets loads of deprecation messages when running under PHP 8.4. Hence we'll have to use "scssphp/scssphp":"^2.0.1", which is fine for PHP 8.4, but grabs a package ""symfony/filesystem" version "v7.3.0" which requires PHP 8.2 or later.

JNeuhoff wrote: ↑

Wed Jun 25, 2025 8:30 pm

I just tested the "scssphp/scssphp": "^1.13" and it gets loads of deprecation messages when running under PHP 8.4. Hence we'll have to use "scssphp/scssphp":"^2.0.1", which is fine for PHP 8.4, but grabs a package ""symfony/filesystem" version "v7.3.0" which requires PHP 8.2 or later.

What version of PHP are you running composer on? You need to use the lowest version of PHP when updating. Using PHP 8.1 pulls v6.4.13 of symfony/filesystem.

Or maybe able to use "platform" to set PHP 8.1 as the base.
https://getcomposer.org/doc/06-config.md#platform

ADD Creative wrote: ↑

Thu Jun 26, 2025 12:09 am

What version of PHP are you running composer on? You need to use the lowest version of PHP when updating. Using PHP 8.1 pulls v6.4.13 of symfony/filesystem.

Or maybe able to use "platform" to set PHP 8.1 as the base.
https://getcomposer.org/doc/06-config.md#platform

I was running composer on PHP 8.4. I'll try again with PHP 8.1.