PrestaShop must be compatible with PHP 7.4

[eternoendless]

PHP 7.4 is due for release in November 2019.

PrestaShop 1.7.8 should work with PHP 7.4.

[matks]

This will be especially important since php7.1 support will end on December 1st 2019, so PS 1.7.7 will be compatible only with 2 supported versions (php7.2 and php7.3), which is a very small range.

Source https://www.php.net/supported-versions.php

[matks]

php7.4 is out 😄

[mvorisek]

Yes, the latest stable release of PHP is 7.4. It will be great if PrestaShop can be compatible with it in the upcoming 1.7.7 release. Comment also added to https://github.com/PrestaShop/PrestaShop/pull/13761

Migration guide:
https://www.php.net/manual/en/migration74.php

[eternoendless]

@mvorisek PHP 7.4 will probably not affect PrestaShop itself, but it may affect one of its upstream dependencies. So while 1.7.7 _may_ work well with 7.4, we won't officially support it until we have verified that all upstream dependencies support it as well (we'll do that for 1.7.8).

In practice, this means that you are free to try and run 1.7.7 with 7.4, but if it turns out that something doesn't work then it won't be fixed in a 1.7.7.x patch version.

[mvorisek]

@eternoendless I understand, but it is ok to test with PHP 7.4 prior 1.7.8? If yes, tehn the #13761 PR can target for PHP 7.4.

[eternoendless]

I'm not sure I understand you @mvorisek

As I said, you can always test PHP 7.4 at your own risk. We won't target PHP 7.4 compatibility for 1.7.7 because it is out of scope for that version -- we have to stop adding things at some point. We are currently holding #13761 off until after feature freeze (ie. after all "must have" features have been merged) so that any regressions it may cause won't block development on yet-to-be-merged "must have" changes.

[mickaelandrieu]

Hi @eternoendless , as 1.7.7 is still "not released" what is the cost to add an extra step on travis to test against PHP 7.4 ?

I mean, we can allow this build to fail but at least people will know what they need to fix.

Would you consider this contribution ?

[W1DJM]

Glad to see that you are moving forward with PHP 7.4 support since the current release of PrestaShop will not install completely or cleanly on PHP 7.4. Quite disappointed to say the least.

[matks]

The preferred way for projects to check for php7.4 support is to run the tests with php7.4 and fix everything that is reported broken.
However PrestaShop does not have (yet) a test coverage large enough to do this. Tests will provide a first bug report but QA team will need to test the whole application _manually_ to ensure everything works properly with php7.4 . This massive task takes days or weeks so we cannot do it easily (we cannot ask them to spend 2 weeks reporting bugs, then we fix all bugs, then they re-test for 2 weeks for regressions, then we fix all regressions, then ... 😄you get the idea).

Quite disappointed to say the least.

This is an open source project, it will get better if everybody helps 😄. If you are willing to convert this disappointment into something positive, help us !
To ensure php7.4 support you can:

• run tests using php7.4, fix broken tests
• run automated tools to spot php7.4 issues, fix the issues
• expand test coverage (either unit, integration, or acceptance) so that for php8.0 we can use the run-the-tests-then-fix-all strategy 😄

[W1DJM]

Thanks for the reply Mathieu. I think I was simply shocked that the install completely failed with PHP 7.4 more than anything. I understand that you are caught between a rock and a hard place but I also think that stopping development for 2 weeks or so to get things working with PHP 7.4 would be a wise investment.

[mvorisek]

PHP 8.0 is here in December so we should already target it - https://github.com/PrestaShop/PrestaShop/issues/18547

[matks]

PHP 8.0 is here in December

For php8 it will be even worse. Because I expect some of our Composer dependencies to not be able to provide a version compatible with the wide range php7.1 to php8.0 . So when we will provide the php8 compatibility, we will have to drop some older php7 versions because we will require the latest dependencies, not compatible with these php7 versions (although PS code might be compatible with the complete range). Hopefully we will be able to provide a php compatibility range like "php7.3 to php8.0".

This decision will require multiple users to upgrade their php server, leading to even more friction about the upgrade process and why it's necessary, and possibly will lead to people choosing not to upgrade their PrestaShop instance (in order not to change their running php version) and hence becoming outdated running shops with possible security issues (and obviously unable to benefit from latest features and bug fixes).

Rough times ahead 😅

[LogoiLab]

Just an FYI, ArchLinux is already shipping php7.4 as its default install and as with most rolling-release distros does not keep older versions in the repos. You can get older versions from the AUR but those builds are currently failing due to lack of developer support from the PHP team. As of right now you've probably lost most if not all of your rolling-release style Linux users to updates.

Granted, this isn't that huge of a problem but I have to wait for 1.7.8 to setup shop, I can't image what has happened to rolling-release users who already had a shop setup and can't roll back their updates.

And again, maybe I'm just special for using ArchLinux in production.

[matks]

Just an FYI, ArchLinux is already shipping php7.4 as its default install and as with most rolling-release distros does not keep older versions in the repos. You can get older versions from the AUR but those builds are currently failing due to lack of developer support from the PHP team. As of right now you've probably lost most if not all of your rolling-release style Linux users to updates.

Granted, this isn't that huge of a problem but I have to wait for 1.7.8 to setup shop, I can't image what has happened to rolling-release users who already had a shop setup and can't roll back their updates.

And again, maybe I'm just special for using ArchLinux in production.

No, there is nothing wrong about using ArchLinux in production.

The main issue we have right now is that PHP is evolving too fast and with too much breaking changes between minor versions. The changes being introduced between php7.2, php7.3 and php7.4 require a huge amount of time and energy to be handled correctly on PrestaShop side, and our current team size only allows us to provide this amount of time and energy once per version of PHP and version of PrestaShop.

So we have

• PS 1.7.6 compatible with php7.2
• PS 1.7.7 compatible with php7.3
• PS 1.7.8 compatible with php7.4

And it might become worse with php8.

The same release frequency acceleration can be observed in the rest of php ecosystem (like Symfony) and also in JS ecosystem. It seems that there is a worldwide trend to release new versions in a backward incompatible manner more often.

This issue is not new and it is affecting other projects similar, in size and history, to PrestaShop. We are very concerned by this and will try in the future to find suitable solutions for all (who said "LTS" ?), which would hopefully be able to provide

• ecosystem sustainability
• correct compatibility range (for example "PrestaShop X is compatible with all php7 versions" sound nice, "PrestaShop X is compatible with only php7.2 and php7.3" sounds bad)
• while keeping the benefits of an evolving language as breaking changes allow for greater changes

[ettoredn]

"The main issue we have right now is that PHP is evolving too fast and with too much breaking changes between minor versions"

The main issue you have right now is that PrestaShop is evolving too slow and relies on deprecated PHP functionalities.

[mvorisek]

"The main issue we have right now is that PHP is evolving too fast and with too much breaking changes between minor versions"

The main issue you have right now is that PrestaShop is evolving too slow and relies on deprecated PHP functionalities.

I agree.

One issue is using deprecated PHP functionalities and/or bad practises from the beginning (old very historically).

Another, I I think the primary one, issue is how PrestaShop wants support modern libraries. Here is my ticket for upgrading Symfony and Guzzle: https://github.com/PrestaShop/PrestaShop/issues/17300 Guzzle 5 is a long time EOL (even no security updates), Symfony 3.4 is very old, still maintained, but has a lot of BC related issues.

@matks @PierreRambaud @ettoredn is the any progress on this?

[matks]

We are not keeping and maintaining old technologies because this is fun. Actually this is a very heavy burden and it is quite sad to see your harsh critics when we spend so much time on it. But all the time and energy we spend on _preserving compatibility_ is actually very well appreciated by the businesses owners who need it.

PrestaShop is used by many business which cannot keep up with the current rythm of PHP ecosystems. I suggest you have a look at that wonderful twitter thread about keeping "old and deprecated functionalities". This is really eyes-opening.

Same story goes for other CMS by the way. There is a reason why WordPress preserved PHP 5.2 compatibility for so long.

But if you think the project is going to slow and you want to help, remember that PrestaShop is an open source, community project. You can _invest_ into having PrestaShop moving forward. 🎉

So ... what could you do on this very topic ?

The answer is simple: contribute to PrestaShop tests.

PrestaShop software does currently not have a testing coverage (unit and integration) big enough to allow merging blindly a PR if CI says it's OK. This was a mistake from the past and we are working hard to fix it (I think every year we x2 the test coverage) but it's still not enough.

If we had a test coverage big enough, we could enable PHP7.4 compatibility very simply by allowing the CI to run on PHP7.4 and fix whatever test fails. This will happen one day in the future. You can help this future to happen faster by contributing to PrestaShop sets of tests.

Test PRs are easy to review and easy to merge, unlike other PRs that fix behaviors and need deep code review and deep QA (manual) analysis.

Contributing to PrestaShop tests would be very useful for the project, for the community, to help PrestaShop achieve php7.4 then php8.0 compatibility. Much more than telling us "PrestaShop is evolving too slow and relies on deprecated PHP functionalities." 😉

[ettoredn]

"But all the time and energy we spend on preserving compatibility is actually very well appreciated by the businesses owners who need it."
Indeed, one such example is the preserved compatibility of 1.6 themes in 1.7. I'm dealing with a small business owner who still uses PHP 5.6 and PS 1.6 just because he does not want to invest in porting its customized theme to 1.7.

"PrestaShop is used by many business which cannot keep up with the current rythm of PHP ecosystems"
PrestaShop is used by many businesses which cannot afford or do not want to invest in other proprietary and well supported solutions.

"I suggest you have a look at that wonderful twitter thread about keeping "old and deprecated functionalities". This is really eyes-opening."
It is very eye-opening how you use that thread about _end-user browsers_ as an argument for keeping outdated _back-end_ technologies. The end-user browser does not fall within the sphere of control of the business owner (running PrestaShop), but the machines and web stack definitely do. Moreover, PHP and the back-end web stack have literally nothing to do with HTML/CSS and JavaScript, which are the critical front-end compatibility problems. You can render a IE11 compatible web page by using PHP 5, 7, or 8. Or NodeJS. Or Rust.

"But if you think the project is going to slow and you want to help, remember that PrestaShop is an open source, community project. You can invest into having PrestaShop moving forward."
Absolutely, and honestly, I wish I could afford to invest my time in contributing but, similar to many small business owners using PrestaShop, I do not.

I get it, it is open source and has a very bad engineering legacy. It really baffles how can it be so much widespread considering all these issues, but I guess it just kinda works well enough for the target audience.

[ettoredn]

I understand this is absolutely not my business, but maybe the company behind PrestaShop should try to hire some actual developer? Just thinking out loud.

[matks]

@ettoredn I was going to provide constructive answers to attempt to understand the frustration that seems to come behind your rant, however the statements you are writing are going too far. They actually break our Code of Conduct.

I consequently lock this conversation as it seems nothing good will come of it.

[matks]

@ettoredn If however the steam vanishes and you are ready to discuss in a polite manner the obvious issues you face (else you would not be here) feel free to join our Slack channel here https://github.com/PrestaShop/open-source/tree/master/slack

Warning: the Slack channel complies to the same Code of Conduct as the GitHub repository. This means:

• Using welcoming and inclusive language
• Being respectful of differing viewpoints and experiences
• Gracefully accepting constructive criticism
• Focusing on what is best for the community
• Showing empathy towards other community members

I think this is not too much to ask and that, following these guidelines in a discussion, actual and profitable outcomes can emerge.

EDIT : I unlock this thread and I hope future discussions will talk about how to make php7.4 compatible. I will lock it again if things go nasty again.