datakick

I think that thirtybees can't possibly release newest version of smarty for everyone in one big upgrade. That's just too dangerous. While we can fix tb core and modules to work with newest version, we can't guarantee the same for third party modules. So there's need to be some upgrade path. We should really decouple (some) libraries from core, and let merchants decide which version they would like to use. We could also let merchants to use different lib version in debug mode, so they could test the new versions without the stress. This is probably the safest way forward. TB should come with some sensible default version that works for majority of users. And once we have enough feedback from merchants that the newer version works fine, we can make it default for everyone (with option to downgrade). On related note: we should also fix the debug mode. As I understand it, this whole thread is mostly about the warnings and notices that get mixed within HTML (and more importantly JSON) responses. These makes the site unusable. If we overhaul debug mode reporting to something from this millenium, this whole class of problems will cease to exists.

I was able to reproduce this issue. Fix will be part of the upcoming version. https://github.com/thirtybees/thirtybees/commit/45fe39bf0b82aedf0e570263447c8fb7cc306a58

I finally get some time to test this, and must say I really like it so far. I've noticed that the module reports some files as obsolete, while they are not. Notably these config/settings.inc.php --- generated by system itself, it's not part of git. Crucial file, must never be removed config/settings.old.php --- contains saved version of settinsgs.inc.php whenever it gets regenerated config/defines_custom.inc.php --- this file exists so merchants can safely upgrade to newer version of thirtybees and keep their settings (dev mode, etc) mails/... --- not all mail templates are part of git, this dir should be ignored override/... --- this should be definitely ignored translations/... --- this should be definitely ignored themes/... --- themes should not be touched

I have seen few modules, for example this one, which contains code like this: php @ini_set('memory_limit', '1024M'); The intent of the developer was to increase memory limit, and it may work on some hostings with low memory settings. But if you have more than 1G of memory available you would never utilize it, as long as this module is installed and enabled. @Steve, maybe you have some gem like this installed on your server as well?

One important note - previous query will zero out quantities for products without attributes. If you want to keep those intact, use this update: UPDATE tb_stock_available s1 SET s1.quantity = IFNULL(( SELECT SUM(quantity) FROM (SELECT * FROM tb_stock_available) s2 WHERE s2.id_product = s1.id_product AND s2.id_shop = s1.id_shop AND s2.id_product_attribute > 0 ), s1.quantity) WHERE s1.id_product_attribute = 0

Try this one: sql UPDATE tb_stock_available s1 SET s1.quantity = IFNULL(( SELECT SUM(quantity) FROM (SELECT * FROM tb_stock_available) s2 WHERE s2.id_product = s1.id_product AND s2.id_shop = s1.id_shop AND s2.id_product_attribute > 0 ), 0) WHERE s1.id_product_attribute = 0 Because mysql do not support updates with subqueries based on the same table, we have to use the hack with inner (SELECT * FROM tb_stock_available). That will results in temporary table. Wonder why mysql won't do that itself...

This smarty variable overriding is very unfortunate. While it would be quite easy to prevent this in the core, it could mean compatibility issue (although in most cases it would actually fix the module interoperability problems). But we could, at least, detect and report this behaviour.

I have just tested upcoming (not yet released) version of smarty 3.1.35, and there is only one compatibility problem I encountered and that's related to this issue: https://github.com/thirtybees/thirtybees/issues/617. Fortunately this issue can be fixed. But I'm also sure there will be more problems, as different themes and modules can use different smarty constructs. Here the help of community is needed. Merchants need to test their themes and modules on new environment and report the problems. TB developers can't fix problems they don't know about. For example, I have no idea why @musicmaster claims smarty 3.1.28 to be the last one usable. What problems did you encounter with higher versions? Are these errors reported and tracked as github issues?

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. isn't it better to fix the newest smarty version instead?

Build-in debug mode is a very useful tool, but it's not recommended to turn it on in production because it can leak sensitive information about your website. This free module is here to help you with this shortcoming, as it allows you to enable debug mode only for specific sessions. This module creates secret url, and anyone who access your site via this url will browse with debug mode enabled. This way, you (or anyone you share this url with) will have access to debugging information, yet your normal visitors will not be affected. Download link

uff, you are running bleeding edge php version on non-supported operation system. That's a killer combination. Thirtybees is not yet even 100% compatible with php 7.2. I suggest you downgrade to 7.1 if possible

what's your php version?

@Traumflug how do you plan to tackle database migration? Say 1.0.9 will introduce new db column for table A, and foreign key to this column from table B. how will be these db changes created when migrated from 1.0.8 to 1.0.9? what happen when you downgrade from 1.0.9 to 1.0.8 what about order of modification (for example we need to drop constraint before we drop column itself)?

@rubben1985 these particular changes are fine. We don't know, of course, how does the external file look like. I really think that some module or vendor library introduces class named Validate, and that this class gets loaded at the very beginning of the request. That would prevent loading Validate core class, and results in this kind of error. Search for class Validate

as long as the module is for ps16, it should be compatible

Search for 'prestashop checkout extra fields module', you should be able to find few of those (paid).

Could you elaborate?

That seems to be problem related to supercheckout module. I'm afraid nobody can help you without the knowledge of its source code

Also, the same error message is also saved inside your log directory within your thirtybees root. So you can always ftp and look for errors there.

That does not help much. Copy error, then go to Advanced Parameters > Logs, and paste it to Decrypt an exception message. It will show you the error message in readable format.

What does the error log says?

@Chandra please look into tb_configuration table and verify that PS_MAIL_PASSWD is correct. Maybe this problem is related to configuration escaping issue... although not likely

Not necessary, it's simple fix, already submitted

It's probably problem with your infrastructure. I've just tested stmp (mailgun) on 1.0.8, and it works as expected.

This problem originates from referralprogram module. I'm pretty sure this exception will be thrown even on tb1.0.7, if this module is installed and url does not contain &sponsor=xxx parameter. The reason this exception is thrown is because Tools::getValue('sponsor') returns false when 'sponsor' parameter is not part of the request. This invalid value is then passed to cipher tool for decryption. Blowfish would return null for invalid input (boolean type), while PhpEncryption will throws exception. This should be fixed in the core -- the behaviour should be consistent. But the module itself should be fixed as well -- there's no need for decryption call, if we don't have anything to decrypt.