Call for votes for (or against) upgrading Smarty

[Traumflug]

This is about the near term strategy of thirty bees development.

Current situation is that thirty bees comes with a fairly ( > 2 years) old version of Smarty, version 3.1.19. This version is no longer compatible with PHP 7.2 and later. Those who put their shop into development mode see PHP warnings about everywhere. And successive PHP releases might well turn these warnings into errors, breaking things in non-developer mode as well.

To get closer to a solution, I've committed an upgrade to Smarty 3.1.25 for getting it into the thirty bees 1.0.6 release. @lesley would prefer to revert this upgrade, because a year ago he tested newer Smarty releases and they broke some templates.

Hence this call for votes, because there are valid reasons for both strategies.

Strategy 1 is to upgrade Smarty on the 1.0.x development branch. Code advances surprisingly well on this branch while we manage to keep compatibility with PrestaShop modules and themes. Which means, the 1.0.x branch may stay for quite a while, perhaps another year. From 1.0.7 or 1.0.8 on it can become fully compatible with most recent PHP versions. At a certain risk to rely on theme developers fixing Smarty bugs in their themes.

Strategy 2 is to move on to development branch 1.1.x (and abandon 1.0.x). Then thirty bees is released from the promise to keep full compatibility with PrestaShop, can upgrade Smarty without looking back and even start to weed out some of the no longer needed, historic PrestaShop code (for example compatibility with PS 1.4). Those running PHP 7.2+ on their server have to upgrade then. And, well, get their theme fixed anyways.

If you want to read even more about the issue, see Github issue #557.

Now, please cast your vote by commenting on this topic! thirty bees listens to its merchants.

[the.rampage.rado]

For me supporting 7.1 is enough but if you want to present this CMS as more advanced and more modern than 1.6 then this have to be done. If you have few issues with the most used themes in the marketplaces I can't imagine that those issues can't be ironed out in few hours and then everybody can use the latest and greatest php with their current themes.

I know that iqit is refusing support for Tb for now but I can't imagine they will stick to this opinion much longer if you gather community. And how you can get more users - it's important to support the newest versions of all parts of this platform.

And why do you wait for 1.1.x to start removing legacy (before 1.6) code from the core? Also the full caching needs some fixes and more testing. And probably the most important part is trust in you - people should know that if they migrate their shops will have life ahead without need for custom migration to another system. I think that currently the trust is not very high as one of the first developers is not getting around and the fixes done in the recent versions are more cosmetic than bugfixes and improvements...

[movieseals]

I noticed the pile up of php errors... I do not think that prestashop compatibility has to go all the way to 1.0.4 - I think 1.6 is a good start for now. Unfortunately, I still have to use a lot of third party Prestashop module to keep things running the way I need my shop to run. Until there is a wider offer of modules and/or the addition of missing functionalities in the core, we are kind of stuck between two worlds. So I vote for strategy one for now. I understand the need to move forward and leave some technology behind but until all the bases are covered, I think we need to take it slow. Another year is not a bad thing to see how things evolve.

[datakick]

How about you include both smarty versions into tb 1.0.6, and let merchants select the version in config file? This way everyone can easily switch back to older smarty version if they discover any issues or problems.

[30knees]

I like datakick's suggestion.

[Briljander]

I am also stuck with a lot of Prestashop modules and do also run Warehouse theme...

[dynambee]

I vote to stay on 1.0.x and maintain PS 1.6 compatibility for another year or perhaps longer. Doing this makes it easier to attract new users and makes the platform attractive to developers who already have PS 1.6 themes or modules. Existing users also have investments in themes and modules that the move to 1.1.x will break.

I would also suggest, as an aside, that the eventual move to break compatibility should be a bigger version number increment. Instead of 1.0.x to 1.1.x I believe it should go from 1.0.x to 2.0.x. The breaking of compatibility is a fundamental change in the way 30bz works and IMO should be reflected by a major version increment.

[vincentdenkspel]

@traumflug I'm not a developer so a lot you are saying is abacadabra to me and as such i can't make a vote. So if possible you could add something to the post like: option 1: don't upgrade smarty ; advantages: ....... ; disadvantages:..... option2: update smarty; advantages: .........; disadvantages: ..........

If your post is mainly targeted to developers please let me know and i will delete this comment.

[Traumflug]

How about you include both smarty versions

As composer tries hard to give the deaf when such requests come up, it doesn't support such setups. Which means, it can't be done without opening another can of worms.

[Traumflug]

Alright, thank you very much for all the votes and comments!

I just agreed with @lesley on this strategy, and I think it reasonably matches what was written above:

1. Smarty will stay on 3.1.19 for another 4 months / up to end of the year.
2. After that, compatibility with PS 1.6 modules and themes will be kept as a goal for another year, but not at all costs.
3. Regarding the version number we'll roll a dice, then.

I'll start packaging thirty bees 1.0.6 tomorrow.

[toplakd]

Could pack Fancybox V3 with 1.0.6 as its working well with PS1.6 and TB 1.0.5. I'm using it on live 1.6 as stil postponing migration to TB :( As V3 is far mor fancy than V2, supporting swipe gestures and other features.

[MockoB]

With 93 issues still open on github, you would like to give your precious time to break the compatibility with 1.6? After all, that was one of the fundamentals of the project! If you want to make something good for the project then read the feature requests on your page. Yes, there is such section!

[lesley]

You can help us make it through those 93 issues is you want @MockoB

As for the feature requests, we are not implementing any new features into the 1.0.x branch. If we do, we will never leave the branch and will be at 1.0.187 before we know it, with no real core progress.

[Briljander]

I understand @MockoB point. Shouldn't the aim be to close issues before trying to make any drastical changes?

[lesley]

It is. See, here is the core issue. Both Debian and Ubuntu ship with php 7.2 now as the default php version. The current version of smarty has several deprecated functions that could be removed in later versions of 7.2, because it is so old. That is the heart of the problem we were trying to figure out the best way to handle.

[Briljander]

I understand. I like new features and would also like to 7.2 but I do think I will have a lot of problems cause I do have modules that's developed for 1.6 and also pretty unique cause they're aimed for the Swedish market. Cause of that I will probably have to pay all upgrade and developement of those modules cause those companies put all effort into being compatible with 1.7, not Thirtybees. Also I am afraid they won't offer any support at all.

That's my concern and unfortunately that's why I still run Thirtybees in dev, not in my liveshop.

[Traumflug]

With 93 issues still open on github, you would like to give your precious time to break the compatibility with 1.6?

Nah. Rest assured we won't intentionally break compatibility with PS 1.6 just for the sake of getting a disruption, much less spend substantial amount of time on doing so. At least I won't.

But, and that's the root of the issue discussed here, there are some of these 93 issues which can't get fixed without accepting some (possible) breakage with PS 1.6 themes. That's the dilemma: either fix these bugs in thirty bees or keep full compatibility with PS 1.6. Can't get both. And because that's such a diverse topic, we asked.

The above decision means: we accept warnings when running on PHP 7.2 until end of the year. Next year we'll fix these warnings on PHP 7.2 and accept some possible incompatibilities with PS 1.6 themes instead. And if there are ways to fix these themes for compatibility with PHP 7.2, we'll certainly help to get them into your shops.

If you want to help, approach your theme developer and ask him to review his theme for compatibility with PHP 7.2 and Smarty 3.1.32 (the current version). They certainly can.

[Traumflug]

I will have a lot of problems cause I do have modules that’s developed for 1.6 and also pretty unique cause they’re aimed for the Swedish market.

If you run a dev shop, testing these possible incompatibilities is fairly easy:

1. Edit composer.json, find the line for smarty/smarty and exchange 3.1.19 for 3.1.32.
2. Run composer update.

That's it already. If your modules continue to work with this change, you're safe for the future. And we're keen on hearing about your findings, of course.

[Briljander]

@Traumflug Great, I will try this and see how it runs.

[movieseals]

@traumflug I tried it on my shop. It broke most of the major modules we use. Curiously, it also broke the layout of the backend. Words or icons disappeared but their functionality was still there.

It did not seem to affect my theme per se but it did break several modules, apparently some from thirty bees as well (Best sellers just disappeared).

I think for a shop that uses limited functionalities, it can work.

[Traumflug]

I tried it on my shop. It broke most of the major modules we use.

Excellent!

Well, I mean 'excellent' in the way that we have some real evidence now. Bugs visible and reproducible can get fixed.

Let's start with this: https://github.com/thirtybees/thirtybees/issues/571

Bonus points for more step by step instructions on how to reproduce and screenshots. With some luck we can fix all of them even before rolling out Smarty 3.1.32.

[rubben1985]

I did not see the voting until now, but you took the right choice. Breaking compatibility with PS before having a strong user and developer bases is a commercial "suicide". Happy with the decision :)

[DaoKakao]

It seems, like there's a need of extra abstraction layer over smarty in order to be less dependent on php/smarty versions change. (this is a joke :winking_face: ) Yet another moment is that there's a php7.3 beta available already, so it is possible such sutuation, when TB still won't be compatible with the deprecated php 7.2

Both things are important equaly: if you break compatibility then you risk to loose a lot of clients, from another hand, keeping situation frozen again brings risk to loose prospective clients and those ones, who have decided to upgrade/move to more modern solutions.

So, TB devteam, being limited in resources, has faced difficult challenge - how to keep balance between moving forward and holding backward compatibility for the sake of conservative lients.

As it seems to me, i would choose the way of moving toward php 7.2/7.3 and newer smarty as a priority, keeping support for the key customers, fixing open issues and holding backward compatibility. Unfortunately, it is much easier to give such advices rather than predict which direction will be right.

[doclucas]

I know you already read my opinions, but anyway, I am voting for strategy 1: Upgrade Smarty to the latest version (3.1.32) on the 1.0.x development branch. keep compatibility with PrestaShop 1.6 modules and themes by adapting the "bridging" code (such as code in smarty.config.inc.php) to the new smarty version. If done right, no template and modules will have any issues. The issues reported by @lesley were most likely due to smarty being upgraded without adapting the core to it. As I suggested before, you can also look at PS 1.7 smarty bridges and backport some or all of their changes, as they use the latest smarty. Again, just doing the composer update will surely break things. You must modify the bridging code first. I am happy to beta test it for you when you are ready. You already have quite a beautiful core (especially compared with PS 1.6). It needs a few components upgrades (smarty etc.) and PHP 7.2 compatibility fixes, and it can become a great platform to continue building on.

Also, as @datakick suggested, it may be good, if not too much of a headache, to keep both smarty versions and let users switch between them. If it's too much of a headache, then just do the excellent 3.1.32

Frankly, without being too dramatic, I think that moving to a core that will no longer be PS compatible may become a death sentence to this project at this stage. Watch out!

[doclucas]

@DaoKakao well said :)