musicmaster

@lesley said in Smarty and PHP 7.2: The need for the button was to offer the later version of smarty that will likely break modules. A push forward so to speak. I don't believe that such a button is a solution. The number of incompatible modules and themes is too large - as far as I can see. And even when a shop might initially work with the new version it might break when the user installs a new module. Most webshop users know little about software and such a crash is for them an absolute taboo. I doubt that many module and theme makers will be prepared to adapt their software - given the still low visibility of Thirty Bees. Many will rather advise their customers to switch to Prestashop. Prestashop dropped Smarty and I believe that was the right decision. By giving up on backward compatibility Smarty proved itself an unreliable partner for the kind of ecosystem that Prestashop is. Of course sometimes software needs to break backward compatibility. But that should be done with a major new version and support for the old system should be maintained for some time. Smarty didn't do that. What guarantee do we have that they won't do the same again in the future? When you build a webshop you expect it to be around without major changes for at least three or four years. But on the TB forum people are advised to use PHP 7.1 - that won't be supported after 1 december 2019. Sometimes people are even advised to use PHP 7.0 - that is no longer supported. This is not right. I see not really an alternative to the kind of solution that I proposed in this post: keeping a compatible Smarty version (that means lower than 3.1.28 as far as I can see) and fixing it so that it runs under PHP 7.2. It is the only way to stay both compatible with the Prestashop 1.6 ecosystem and up-to-date with PHP. My solution was a proof of concept and other people may be able to improve it. But I see no alternative.

@the-rampage-rado said in Smarty and PHP 7.2: @musicmaster I like your attitude here! :D This is not a small issue. With the Panda theme you cannot access the front office under PHP 7.2 in development mode thanks to this little warning. Very likely it isn't the only theme with such a problem. Just a few months ago the announcements on the forum were that with the new year Thirty Bees would start supporting PHP 7.2. And now we are told that that will be implemented with a Smarty upgrade that will break backward compatibility - what isn't a real solution. The plan for Thirty Bees was that it would provide a vision for the future for all the people using Prestashop 1.6 who don't like 1.7. For the short term that meant improvement of the code (more speed, less bugs) and some extra features that provide a concrete incentive for migrating to TB. When enough users had joined would there be the step to TB 1.1 where TB implemented its own vision and gave up on complete backwards compatibility. The code improvement has gone well and is still going well. But the extra features that should seduce people to migrate are a bit of a problem. Elastic Search appeals to too few people. GDPR may never arrive. And now we are told that PHP 7.2 compatibility won't be what it had been suggested to be either.

You might copy the three smarty tables from a fresh install. You can also import the file I attached that contains those three tables. Anyway, clean the cache as soon as possible. 01546953434158lazy.zip

Updating to a PHP 7.2 compatible version of Smarty is the same as switching to another framework. By giving up on backward compatibility in 2015 Smarty abandoned users like Prestashop and Thirty Bees. Smarty has de facto been abandoned code since 2015. But software doesn't age so we happily have kept using it. With PHP 7.2 we have arrived at a point where one single line in the Smarty code gives a problem. We can now fix that little problem or declare such a fix taboo. Smarty itself doesn't maintain this code anymore. So we can feel free to do with it whatever we like. There will never be another update from the Smarty maintainers that might interfere with our fix. It is very nice that the latest Smarty version is better. But so are Twig and other template engines. Switching to each of them will have the same effect at the moment: it will kill Thirty Bees as it will leave it without supporting software. The argument that the code is fetched doesn't make sense to me. Nothing forbids us to include this code into our own code. Nobody will notice those extra 300K in a software package of 40M.

@traumflug said in Smarty and PHP 7.2: That said, such workarounds are pretty exactly what I'd like to avoid. The usage of each() you found is a bug and bugs can get solved by changing the buggy code. The PHP folks didn't introduce such warnings to annoy users, but to detect bugs and help eliminating them. The fact that a function is deprecated does not mean that it is a bug. The PHP people didn't abolish each() because it is buggy. They just found it a poor alternative for foreach(): slower and harder to read. And given that they wanted to clean up the language a bit it had to go. And if you look around the internet you will see that nearly every major software package used to contain it. Rewriting the Smarty code with foreach() is a nice ideal but I find their code a bit hard to understand. This was the only alternative to get things working. I find it a bit easy to call it a workaround. I rather see it as risk-averse: given how complicated this piece of their code is it is very easy to get unwanted side effects when you try to restructure it. Just replacing this function minimizes that risk. But of course I will welcome it when at some point in the future some genius manages to restructure this code the "proper" way. I don't believe upgrading Smarty to a PHP 7.2 compatible version is a viable alternative for TB at the moment. It will break compatibility with almost all the code that was written for Prestashop. And the quality of the error messages means that that is almost impossible to fix.

I have been looking how I could run my TB 1.08 on PHP 7.2 without those annoying warnings. My first step was looking for the highest Smarty version that worked with my shop. It was 3.1.27. Next I looked at the warning that got. I searched the code but there is only one instance of "each()" in it. I found on internet a "myEach()" function that should be able to emulate each() and implemented it. Attached is the resulting code. Only the file /libs/sysplugins/smartyinternalcompilebase.php has been changed from the default 3.1.27. The code comes under the /vendor/smarty directory of the shop. As far as I can see it works. Can other people test it? 01546705970018smarty.zip Follow up: it looks like the version-update wasn't a good idea. It seemed to give hangup problems when run under PHP 7.2. However, the modification of smarty_internal_compilebase.php seems to work well. See below. smarty_internal_compilebase.zip

When you want to debug javascript errors your first step should be to disable minimization (the CCC functions). As far as I can see you didn't do that. Always start with the first error message. In your first picture that is iris.min.js. That doesn't look like a TB file. If you move your mouse over the filename in the console you see its full path and say something about to which module it belongs. ERRBLOCKEDBY _CLIENT most likely means that some addblocker or anti-malware software that you installed blocked a file.

@rubben1985 said in error 500 when activating debug mode: anyone with programming knowledge can tell me if I did something wrong with the code I introduced in the validate file? (code was to make work a module). In the actual state when I activate debug, site breaks so I can not use it but I need the code inside the file (but maybe I made something wrong even if the module now it works) No way anyone can tell you how that will work out. Both functions that you have added include an external file that you haven't added.

It might be that DO had to redo things for Ubuntu 18.04. I set this droplet up two months ago and probably since then they repaired some bugs (in my install there was no Mysql password). I used to prefer Virtualmin but the fact that nowadays they don't even activate php reduced my trust. One curious question: I understand that my pretty url's did not work without overrides enabled. But what puzzles me is that on the homepage most of the images (80% at least) were shown correctly despite being a pretty url. How could that be?

Thanks for the tip. As a tip from me: your blogpost on installing TB on DO doesn't mention this allowoverride stuff (or that you need to add modrewrite for it). It might be good to add it.

Thanks, that fixed it.

@lesley said in Product links don't work: Not overrides in your installation allow overrides in apache, https://httpd.apache.org/docs/2.4/mod/core.html#allowoverride Sorry, this evades me. I thought we talked about TB/PS overrides and suddenly you refer to Apache overrides. What is your point? Is there something wrong with my Apache configuration?

Localhost is on php 5.7. The servercode is a copy of the localhost code. Both have overrides enabled.

This is PHP 7.2. Could that be a problem?

The funny thing: all this is working on my localhost, but not on the server. I have refreshed the .htaccess many times but it just doesn't have an effect.

I want to keep the Prestashop linking system. So I copied the link descriptions from my Prestashop installation (see attached picture). But it doesn't work. Neither the category links (like http://www.bilbil.com/34-chocolade), nor the product links (like http://www.bilbil.com/geslaagd/155-snoepblik-geslaagd.html) work. They result in 404s. In addition I have a problem that on my home page some pictures show the file-not-found image. But they do have an image and I can't get the image to show. Take for example http://www.bilbil.com/5722-homedefault/chocolade-munten-50-gram.jpg. This should refer to http://www.bilbil.com/img/p/5/7/2/2/5722-homedefault.jpg. But that image is there and the "pretty url" not.

I will look whether I can make this somehow reproducible. At the moment I can't find the key.

As soon as I refresh the page it is normal. Somehow TB does not preserve its css file in circumstances where PS does so.

I mean that I regularly see my TB pages as below. And that that never happens with a Prestashop installation.

When I reboot my computer and the browser comes up again I will see the webshop under Prestashop as I left it. However, the same webshop under Thirty Bees will look as if the CSS file wasn't loaded. Is there a way to fix this?

@fabsca said in thirty bees Fatal error: no UTF-8 support. Please check your server configuration.: . Or is it a TB problem? If you search the internet for "Fatal error: no UTF-8 support. Please check your server configuration" you will see that it is quite common with Prestashop too and has to do with server restrictions.

Did you fix the ElasticSearch bug that is mentioned here: https://forum.thirtybees.com/topic/2395/update-to-1-0-8-shows-500-server-error/9

In de psorderdetail tabel worden zowel prijzen met als zonder btw opgeslagen. Dus veel win je niet met het aanmaken van een nieuwe tax id. Aan de andere is het ook niet veel werk zo'n nieuwe belasting id te implementeren. Je krijgt zoiets als update psproduct set idtaxrulesgroup=6 where idtaxrulesgroup=2 Waarbij de waarden bij jouw natuurlijk anders kunnen liggen en je ook psproduct_shop moet updaten...

In de backoffice ga je naar Localisatie->Belastingen en pas je het tarief aan. Daarvoor hoef je niet rechtstreeks in de database bezig te gaan.

Ervan uitgaand dat je de prijzen inclusief btw gelijk wilt houden moet je de prijzen excl btw met 106/109 = 0.97247706 vermenigvuldigen. Prestashop slaat alleen de prijs excl btw op dus die moet je veranderen. Je kunt dat rechtstreeks in de database of met Prestools doen. Let wel op dat je geen producten met 21% btw meeneemt.