datakick

Thanks for the but report, let's track it in github: https://github.com/thirtybees/thirtybees/issues/815

This is really harmless debug message. In fact, I'll drop it from the code in the next version, as it does not help anyone. It can mean one of two things: 1) visitor's cookie contains reference to a cart that not longer exists in your database. This can happen, for example, when some module removes abandoned carts from the database. 2) visitor's cookie contains reference to a cart that has been already converted to an order. This will usually happen on order confirmation page. In both cases we just need to remove cart reference from cookie and carry on. Neither of these are bug, and I don't see any reason why it should fill merchant's log

Any chance that these are stored inside configuration table? If so, this might be caused by this issue: https://github.com/thirtybees/thirtybees/issues/807

These notices are, well, notices. They are not errors themselves, and are not cause of your problems. You should, of course, fix the template (or module) to get rid of them, but that will not help you with those two other problems.

we shall add some check into class_index generator to prevent this kind of problems in the future

there shouldn't be any directory classes/range/pdf I suspect you accidentally copied directory classes/pdf to classes/range/pdf. This can confuse autoloader, because there are now two classes with the same name. To fix this 1) ensure that directory classes/pdf exists and that it contains file HTMLTemplateDeliverySlip.php 2) delete directory classes/range/pdf 3) delete file cache/class_index.php

If you have debug mode enabled, then disable it and try again. It has the tendency to break json/xml responses because of display_errors php directive

Don't do that, as system is not designed to share images. For example, when you delete product, all its images are deleted as well. If on of those images is shared with another product you would have a problem.

The theme does not work without the Tools.php override. It throws Call to undefined method Tools::getProductsImgs() in product-list-item.tpl This method indeed does not exists in ToolsCore, so the theme should not depend on it. I suggest you remove this from the theme. The best way to provide this functionality might be dedicated module -- your theme could trigger hook to obtain product images, and this custom module would fulfil the request. If the module were missing, then the theme would fallback to standard rendering.

Url structure has changed, which means all inbound links, bookmarks, etc wont work anymore. SEO nightmare. For example, topic urls changed from forum.thirtybees.com/topic/id/friendly-url to forum.thirtybees.com/topic/id-id/friendly-url

This check has already been fixed If it shows this warning for you, it really means you have server cache enabled on your server.

Frankly I don't know. I remember there was a whole thread (https://forum.thirtybees.com/topic/1095/paypal-6-0-0-beta-the-final-push-for-victory) dedicated to paypal v6, but that seems to be deleted since. So that knowledge is gone forever. I could find only one bug on github regarding v6 (redundant api calls on every page). While that's unfortunate, it's not something that should prevent using that version of the module. But I'm sure there is the reason nobody is using it. But it would be great if we have those reasons tracked as github issues, otherwise we can never fix this. Here we need merchants help. Please test v6, if you can, and let us know what does not work. So we can finally resolve this paypal hell.

Oh, it's also necessary to change the next line $order = $params['order']; to $order = $params['objOrder']; Basically, the beginning of the hookPaymentReturn method should look like the highlighted code here

There's another bug in hookPaymentReturn. Edit file paypal.php, find method hookPaymentReturn and change the first line from if (!$this->active || !isset($params['order']) || !$params['order'] instanceof Order) { to if (!$this->active || !isset($params['objOrder']) || !$params['objOrder'] instanceof Order) { Note that all these fixes are already part of the paypal v6.0.0, see here What is the reason paypal 6.0 is not used yet?

Try to edit file /modules/paypal/controllers/front/expresscheckout.php and change line Tools::redirectLink($this->context->link->getPageLink('order-confirmation', true, '&id_cart='.$cart->id.'&id_module='.$this->module->id.'&key='.$customer->secure_key)); with Tools::redirectLink($this->context->link->getPageLink('order-confirmation', true, null, [ 'id_cart' => $cart->id, 'id_module' => $this->module->id, 'key' => $customer->secure_key ]));

@musicmaster said in Smarty and PHP 7.2: I experience just the just those notices / deprecation warnings That is excellent news. That means that the debug mode is the only functionality I know of that is causing real problems on php 7.2. The rest of the core system and modules works just fine. Debug mode is the only reason why I suggest using php 7.1 at the moment. When debug mode is on, those deprecation warnings get mixed into html, or they are injected into ajax responses, and that causes problems. But notices and deprecation warnings themselves don't mean that the thirtybees (including current smarty lib) is not php 7.2 compatible. They are really just warnings, advising us that future php versions will have problems with our codebase. But because of terrible implementation of debug mode reporting, these warnings causes real issues right now. That's why I suggest we tackle debug mode first. Once we have that fixed, we can really advice merchants to use php 7.2, as the core code will be 100% compatible. And then, we can start work on php 7.3 compatibility. That will require fixing all those notices and warnings. We will need to update smarty library, or patch it as you suggested. But we don't have to rush that decision, because php 7.2 will be supported until Nov 2020.

@musicmaster said in Smarty and PHP 7.2: For me the main point is the PHP 7.1 recommendation. I don't believe that it is a good idea to recommend people at this point of time to start a webshop with that PHP version. Within a year many of them will be automatically upgraded by their hosting provider to PHP 7.2. And as many people apply code changes instead of overrides - so that they cannot easily upgrade TB - that means that quite a few people will have a serious problem. Starting a webshop based on PHP 7.1 at this point of time is just a bad idea. Unfortunately I don't see much of a sense of urgency on this forum to fix this issue. Do you experience any errors with php 7.2? Or is it just notices / deprecation warnings?

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?