Waiting for feedbacks : Frameworks upgrades for v9.0

[fabienvallon]

The problem

Hello guys ,
For the v.9.0 we would like to upgrade our frameworks ( PHP, SF .....)
We studied quickly what could be done ( or not )

See here for details : #31937

My main idea would be be to drop PHP7.X & PHP8.0 ( and keep PHP8.1 & PHP8.2 ) but I would like to have your opinion

Pro :

• Security support / flaws
• Easy to maintain
• Better XP for dev

Cons :

• Much more effort is required for modules developers

What do you think ?

The solution

What do you think ?

Alternatives

No response

Additional context

No response

Do you plan to work on this subject?

• I'm willing to contribute a formal specification.
• I'm willing to provide any wireframes or design assets required for this feature.
• I'm willing to submit a Pull Request that implements this feature.
• I'm willing to help verify that the implemented feature works as intended and produces no unintended side effects.

[kpodemski]

I love that idea, and I hope my fellow developers will agree that it'd be awesome to have a chance to use PHP 8.1 features inside v9 without worrying for PHP 7.4 and 8.0 ❤️

[jf-viguier]

Drop PHP7.X & PHP8.0 is ok for me.

[FabienPapet]

Same here, drop all php < 8.1

[0x346e3730]

>= 8.1 is the sanest choice imho.

[olecorre]

Drop PHP7.X & PHP8.0 ? mumm ok for me.

[boherm]

I agree with this too.
For me and because PrestaShop aim to build an e-commerce website, the main thing to consider after all is security.
So it's a necessity to drop PHP <= 8.0!

But yeah, it can be complicated for developers to make their modules compatible with PHP 8.1+.
I'm afraid that some merchants and web agencies are also not following this release due to a potential big effort to update their shops despite increased security.

[eternoendless]

As a developer, I love the idea of being able to benefit from the language features of recent PHP versions.

From a business side though, I'm a little worried about the risk of making it more expensive for merchants and module developers to upgrade to v9. Taking into account that support for PHP 8.1 is fairly recent in the PrestaShop ecosystem (only PS 8 supports 8.0 and over), I'm not sure if the modules ecosystem will be ready to support PHP 8.1 in time for v9. I'd like to hear what agency / module developers have to say about that.

[ghost]

Alors oui mais non.

Pour être un kidam du dev et de la contribution ça serait génial, on gagnerait du temps sur la QA plus besoin de lancer des tests sur toutes les versions de PHP un rêve pour tous les devs.

Mais cela risque vraiment de mettre un coup à l'âme de PrestaShop sur la flexibilité des versions de PHP, sans vouloir faire devenir PrestaShop un Wordpress il y a tellement de belles histoires avec PrestaShop !!!

Je vais vous en raconter une … il était une fois un prince charment ( un entrepreneur ) qui c'est dit qu'il allait vendre des cordes … il créa un site sur PrestaShop basique et dépensa quelques milliers d'euros en modules ( les salaires de PrestaShop, et des créateurs de modules ), après quelques années et un bon CA il comprit qu'il faillait faire refaire son site pas une vraie agence ( salaires des agences et encore des créateurs de modules dont PrestaShop ).

En gros je serais tellement d'accord avec vous mais vous sautez une étape les gens qui vous font tous vivre les e-commerçants. Dans la description de cette discussion il n'est jamais mentionné le coût pour un marchand et les problèmes pour un marchand ouvrez les yeux

Pour rebondir j'utilise régulièrement 3 Projets Open Source … PrestaShop, NextCloud et Matomo

Un e-commerçant lambda ne créera pas une instance Nextcloud ou Matomo par contre il montera son site PrestaShop et oui ce n'est pas les mêmes contraintes.

Et pour finir tant que les partenaires ne mettent pas à jour leur module c'est se tirer une balle dans le pied le module avis-verifie 60K téléchargements pas compatible php 8 et Prestashop 8.0, idem pour DPD 40K téléchargements et pas de version 8.0 sans parler du temps pour sortir des correctifs de sécurités

Tant que les créateurs de modules ne seront pas calés sur le nouveau cycle de versions ( CF graph Pablo ) … vous allez tuer PrestaShop avec ça.

Donc pour moi c'est oui mais NON

---

So yes but no.

To be a kidam of dev and contribution it would be great, we would save time on QA no need to launch tests on all versions of PHP a dream for all devs.

But it really risks to put a blow to the soul of PrestaShop on the flexibility of the versions of PHP, without wanting to make PrestaShop a Wordpress there are so many beautiful stories with PrestaShop !!!

I'll tell you one ... once upon a time a charming prince (an entrepreneur) who said he was going to sell strings ... he created a site on PrestaShop basic and spent a few thousand euros in module (salaries of PrestaShop, and creators of modules), after a few years and a good turnover he understood that he needed to redo his site by a real agency (salaries of agencies and again creators of modules including PrestaShop).

Basically I would agree with you so much but you skip a step the people who make you all live the e-traders. In the description of this discussion it is never mentioned the cost for a merchant and the problems for a merchant open your eyes

To bounce back I regularly use 3 Open Source Projects ... PrestaShop, NextCloud and Matomo

An e-merchant lambda will not create a Nextcloud or Matomo instance but he will build his PrestaShop site and yes it is not the same constraints.

And finally, as long as the partners do not update their module, it is to shoot themselves in the foot the module avis-verifie 60K downloads not compatible with php 8 and Prestashop 8.0, ditto for DPD 40K downloads and no version 8.0 not to mention the time to get out of F**LLES de SCRITE

As long as the module creators are not aligned with the new release cycle (CF graph Pablo) ... you will kill PrestaShop with this.

So for me it's yes but NO

[x13pl]

We are one of the largest companies creating modules for the Polish market.
Currently, we have over 100 modules for sale, as well as several hundred custom-made ones based on individual orders.

I am definitely in favor of requiring PHP version 8.1, even though we ensure compatibility for previous solutions, we would gladly take advantage of the new features in version 8.1 when creating new ones.
Even now, developers are not satisfied with the need to maintain backward compatibility, and I think it will be a plus for freelancers as well.

[Seb33300]

PHP 8.1 and Symfony 6 💯

[lxregistry]

remove smarty and keep only twig

[lxregistry]

maybe will be better to go in paralel with php
Prestashop 8.1.2 with php 8.1 and symfony 6.4
next version
Prestashop 8.2 with php 8.2 and symfony 7

take an example from your competitors ....
https://www.shopware.com/en/news/shopware-6-6-rc/

[PrestaEdit]

The discussion is still there or it's already over : #32462 ?

[kpodemski]

@PrestaEdit As you can see, the discussion is still open, if you have any feedback, let us now

[kpodemski]

@okom3pom upgrade from major to major will cost you anyway, that's the thing with major releases, there are major changes - I understand your point of view, but in my opinion, we need to move forward, our ecosystem needs to catch up

As long as the module creators are not aligned with the new release cycle (CF graph Pablo) ... you will kill PrestaShop with this.

It's been over half a year since PrestaShop 8 was released, and some module developers still need to update their solutions, and whose fault that is? Upgrading solutions from 1.7 to 8 is super easy. I heard that PrestaShop SA will force module developers to upgrade their solutions.

But it really risks to put a blow to the soul of PrestaShop on the flexibility of the versions of PHP, without wanting to make PrestaShop a Wordpress there are so many beautiful stories with PrestaShop !!!

What's the thing with the flexibility here? Let's be honest. We should not support PHP versions that are EOL. You are from Friends of Presta, aren't you guys started educating people on how important security is? Another thing is that maintenance of older PHP versions is just a pain, every time we want to upgrade some dependency, there's a discussion about what we should do about this library X that doesn't support PHP Y anymore.

[ghost]

As I explain, I totally agree with you.

But when I see the messages on facebook groups, forums ... I am afraid that PrestaShop SA lose all these small merchants.

Personally it will not change anything for me, and I do my updates alone.

And I must admit that not to make update-alternatives when I make a PR to test it will be fine too :D

Here I really speak for the good of the first PrestaShop SA contributor

[matks]

But when I see the messages on facebook groups, forums ... I am afraid that PrestaShop SA lose all these small merchants.

It looks like to me there is a rift between prestashop developers needs and prestashop merchant needs.

[PrestaEdit]

It's less than 15 members of the discussion.
Less than 15 days since the beginning of the discussion.

And, so, a "community" choice to drop the support of PHP versions lower than 8.1 on PrestaShop 9.
Or not.

[matks]

It's less than 15 members of the discussion.
Less than 15 days since the beginning of the discussion.

You pinpoint a problem but I think it hides another. The real problem I see here is that the majority of PrestaShop users are passive and will not provide a feedback. You're right: 15 people is insignificant when compared to the hundred or thousand of PrestaShop users. But these hundred and thousand? They are mostly silent 😐 and do not participate. So we have no idea what they think.

I think even if we wait for 2 more weeks, we'll get maybe 2 or 3 more answers? We'd have 18 feedbacks 😄 instead of 15. It's still not enough to make an informed decision. As of today, we have no reliable way to know what the majority of users think. So we can just use the feedbacks of the people who engaged, the people who took time to answer 😉 these 15.

The root problem is not the duration of this discussion is the lack of engagement of the majority of the community 😭 .

And, so, a "community" choice to drop the support of PHP versions lower than 8.1 on PrestaShop 9.

I want to clarify something: the community does not choose whether or not to drop PHP versions. The leadership council does, following the 2023 organization of the project.

This Discussion was not "hello, we want to drop some PHP versions can you tell us your decision?" but rather "hello, we want to drop some PHP versions can you tell us how you feel about it, that will help us decide" 😉

We have acknowledged (we = the leadership council that I am a member of) the feedbacks of this Discussion, plus the considerations about Composer dependencies, plus the PHP ecosystem evolution, and given all these inputs we believe we can take a decision. I guess you have seen it in the draft announcement.

The future will tell us if it was a good or a bad decision.

But let me tell you something : we are no supermen. Today we believe this is the right answer but it's still possible to revert it. It's not written in stone, and it can change.

If we have hundred of people telling us "noooooo this was a very bad idea guys" I'm sure we will backtrack 😄 . This project and its community is way too big, too rich, too complex to allow us to decide something and never challenge it (funny thing: I wrote something about it here yesterday ) . We're just regular people, trying to make the right call 😄 given the situation, the context, the feedbacks we have and the knowledge we have about the project and its ecosystem. Please do not judge us too hard 🙏 we're just trying to do our best and it's a very hard task.

[PrestaEdit]

Hi,

I seen this inside the draft annoucement and know it since at least 4 days, just regarding the changes/moves done on the project.
I know how it's work, since months/years and I like your answer there cause it's mention something "new" : it's not a community-concern but a council decision.

And, you know what ? I'm okay with this. I'm okay with this since months/years. Really.
My only concern is to make clear that the lead is taken by PrestaShop SA and - above all - that it is assumed. And I told this since a lot of times, so I just can agree with this. 🙂

N.B. : I'm not against the drop of PHP versions. I could be against it for only one reason : that the latest version 8.x since the major 9 does not handle this PHP version.

[Seb33300]

From the documentation, PrestaShop 8 is compatible with PHP 8.1: https://devdocs.prestashop-project.org/8/basics/installation/system-requirements/

[matks]

it's mention something "new" : it's not a community-concern but a council decision.

I agree it's a good thing it finally is clear. You can thank @eternoendless who did an amazing work of pushing people to finally set in place the 2023 organization and publish it. Finally it's 100% clear who take decisions regarding the project: we have 4 councils (leadership, technical, product, quality) that do take decisions regarding each of these domains. Before 2023 it was blurry and confusing.

It's been a bumpy road, but I'm quite happy with the current step we are. In 2018, only employees of PrestaShop SA were granted maintainer rights to the project. In 2020 the possibility to become maintainers was opened to everyone, and @kpodemski was the first person who walked that door. In 2022, the project moved forward being more neutral* and now in 2023 we have open councils who take decisions.

I'm sure from the outside it might look very slow 😉 but the PrestaShop project is such a big mountain that changing habits and changing how things are done takes a very long time.

I'll also seize the opportunity to thank @ttoine: the situation we have today would not exist without all the work he did in the previous years, explaining how this was the right direction and pushing towards what we have today.

*I say "more neutral" and not "neutral" because there is still work to do. The company and the project were mixed together for more than 10 years 😆 so there was a looooooot to untangle, so much that we could not do it in one shot in PrestaShop 8 (although I believe we removed the most important links 😊 ). So I know there is leftovers.

[matks]

For your information, a decision was taken https://build.prestashop-project.org/news/2023/prestashop-9-min-php-version-will-be-81/

This decision was taken while considering many things, and the feedbacks of the people who wrote here was in the list 📖 .

[MatShir]

Should we close the feedback topic (or move to announcement section in discussion ?) ?

[matks]

I think yes we can close.

[fulldecent]

The blog post title is:

PrestaShop 9 Minimum PHP Version Will Be PHP8.1 // THE PROJECT MOVES FORWARD AND DROPS OBSOLETE PHP VERSIONS

But this is a contradiction because PHP 8.1 has already been obsoleted and PrestaShop 9 is not out yet.

---

Instead it would be a permanent solution to the problem, and a clear engineering policy if we could please just say:

TITLE: PrestaShop's Aligns Its Supported PHP Versions With The PHP Project

BODY:

Our new policy for PHP supported versions is as follows:

1. When the PrestaShop project releases a new major version X.0.0 (major versions can have backwards-breaking changes), we will support exactly the PHP versions which are then actively supported by the PHP project.
2. When the PHP project releases a new version, we will immediately add it as a supported PHP version in our in-progress work on the next major version of PrestaShop and our automated testing. We may also add support for PHP versions to PrestaShop's supported versions at any time.
3. When the PHP project ends active support for a version, we will immediately make a new point release to each of our current supported versions of PrestaShop to mark the ended PHP version as deprecated. Please upgrade your PHP.

Please note, as a consequence of the above policies, this means every PHP version PrestaShop supports in its first release of a major version X.0.0 release will continue to be supported through every X.Y.Z release in that major version.

[kpodemski]

Unfortunately, I am not sure if we can guarantee this:

When the PrestaShop project releases a new major version X.0.0 (major versions can have backwards-breaking changes), we will support exactly the PHP versions which are then actively supported by the PHP project.

or this

When the PHP project releases a new version, we will immediately add it as a supported PHP version in our in-progress work on the next major version of PrestaShop

We cannot possibly know the extent of changes in the PHP project in the future. Sometimes, changes may be so big that it would be difficult to make adjustments, or there may be a need to drop too many PHP versions. Eventually, this will be quite an important business decision that impacts the entire PrestaShop ecosystem.

Fortunately, PHP has now a much more friendly release cycle and it should be easier :)

[fulldecent]

We want people to upgrade.

I am most interested in dropping versions of PHP that are not actively supported. Like you said, this is easier for us to do because those versions will now stay along longer. When we drop versions, that makes modules have to update-- and it lets everybody see when old modules are crusty, unsupported and time to be ignored.

As for new versions, at a minimum, we can immediately add them to continuous integration testing. Then actually support the then with the release can be a "goal" but not a commitment. Like you said, we can't know what commitment entails.

Hopefully a policy like this can be a useful target going forward and does not require much thought or a special blog post with special policies each year.