The each() function is deprecated

[musicmaster]

Running a shop under TB 1.06 and PHP 7.2 I keep getting this message: <b>Deprecated</b>: The each() function is deprecated. This message will be suppressed on further calls in <b>C:\xampp\htdocs\_myshop\vendor\smarty\smarty\libs\sysplugins\smarty_internal_compilebase.php</b> on line <b>75</b><br /> As it says it will disappear when you look at that page a second time. But it will re-appear when you make some change to that page or when you empty the cache. Is there a solution for this?

[doclucas]

Yes. Use php 7.1 TB is not yet compatible with php 7.2, so you will see a lot of such errors if you keep using 7.2 See this github issue too: https://github.com/thirtybees/thirtybees/issues/557

[gonssal]

Can we stop saying that deprecations mean the software is "not compatible" with a given version of a programming language? Deprecations are a way to warn developers that some functionality will most probably get removed in a future version, and deprecation messages should never show up in a properly configured production server.

thirty bees' own code has plenty of deprecations (search for @deprecated in the code), does that mean that the deprecated code is "not compatible" with the rest of thirty bees? No, it means that it will most probably be removed in a future version while it still works perfectly fine.

[lesley]

@gonssal My thoughts exactly.

If you use an edge version of PHP that is not officially supported, don't be surprised to see notices and deprecations. Its getting harder and harder to support 5.6 and the latest versions without having these.

[doclucas]

Nowhere did I say that "deprecation means incompatible", but anyhow if you mentioned it - code compatibility checkers are normally checking for 2 main things: deprecated and removed functions. If and when they find any, they mark the code as incompatible. Deprecated code can still work, but strictly speaking - a warning is an error and no application should work with visible or hidden errors. Suppressing those errors is not the proper way to deal with code. Sure, your clients and maybe you won't see them, but they are still there and they shouldn't be.

TB is not compatible with php 7.2 because some parts of it throw errors (even if it works when u suppress them) and more importantly - some other parts (eg. rijndael encryption which uses the removed mcrypt) don't work at all.

[musicmaster]

I am a bit puzzled about those claims about many incompatibilities. My experience was that it worked quite well. Except for the problem I mentioned I saw only some error messages in the backoffice from the Cheque module that I don't use.

I didn't do a comprehensive test but I used quite a few functions.

[doclucas]

Turn off caching and you will see them much more often. :light_bulb: Especially if you turn on debug mode as well... By the way, regarding the claims you mentioned, one possible reason you don't see errors/warnings is because the developer suppressed some of them with the @ operator. Not the most professional way to write code (to put it mildly). Good read: https://stackoverflow.com/questions/1868874/does-php-run-faster-without-warnings/1869185

I really like this comment (by a real pro):

[musicmaster]

This was a little project for a webshop from which the shop part has been disabled for the moment. It originally ran PS 1.6.0.14. The provider switched to PHP 7.1 so something needed to be done. I first upgraded to PS 1.6.1. As the psonesixmigrator module didn't work (an unique key error for the pstab table) I then went straight to TB 1.0.6 by copying tables with my Copyshopdata tool. After that there was quite a lot of finetuning/bug fixing to do which I did under a PHP 7.2 development environment. Of course development mode was enabled and I regularly had to empty the cache. It still has the original theme.

[Traumflug]

@musicmaster about 16 hours ago

I am a bit puzzled about those claims about many incompatibilities.

It's fairly simple: 99% (100%?) of these messages originate in Smarty code. thirty bees currently uses Smarty 3.1.19, a ~~two~~ four years old version.

Upgrading Smarty was under consideration, of course: https://forum.thirtybees.com/topic/1950/call-for-votes-for-or-against-upgrading-smarty

Result of this consideration is that Smarty will be kept at its current version up to end of the year. Because any upgrade is seen as a risk regarding compatibility with PrestaShop themes and modules. We want merchants migrating from there to feel as comfortable as possible.

In January I'll happily upgrade Smarty, because I see these messages as well, day in, day out. If you want to do this now, and have a developer installation, proceed like described in this post.