datakick

@Luv try downloading latest version 1.0.21, it should be fixed

You can simply check if _PS_ADMIN_DIR_ is defined. Alternatively, you can look what controller is currently in use - Context::getInstance()->controlller. Can I ask what you are trying to achieve? It seems really strange that the logic override should behave differently for backed/frontend

This seems to be bug in tbupdater module, it should be addressed. https://github.com/thirtybees/thirtybees/issues/619

@30knees said in Hack stats module to show the combinations of best selling products?: @datakick Shouldn't your module be able to do this? I have the ordered products list, but how do I group and sort that according to the most ordered product? Unfortunately no. My module can create list of transactional data only, it can't summarize it. There are plans to implement this (summary list feature), but it won't happen anytime soon. In fact, I first need to modularize my module a little bit first. It offers too much functionality, and that makes it too pricey for many merchants. Usually when someone wants to buy it, they need one or two functionality at most. But they have to pay higher price for all the other functionality won't even use. Most people want either xml export, or xml import. And almost nobody is using lists, mass updates, or custom fields,... Which is a shame, really, because these features are so powerful. I actually think that the list is the one feature that everyone should use daily.

@basix101 said in Updater v.1.3.3 "thirty bees' caching features are disabled": Edit: The "Update Thirty Bees" button is missing because of the disable cache error! Edit file /config/settings.inc.php, find line with _PSCACHEENABLED_ and change it to look like this: define('_PS_CACHE_ENABLED_', '0'); Note that this constant is not used anymore tb core, but tbupdater module still use it to determine if the cache is turned on/off

You can disregard this warning, it's a minor compatibility issue

The second issue - php warning - is fixed by https://github.com/thirtybees/blocklayered/commit/e83e3992eb6411f5dc4b072ce7fd4fc78845df48

Since the download took only 1 second, I assume the problem is in misconfiguration of your server. You probably do not have curl installed, or you might have some firewall that prevents the operation. I just tested it, and it works. Download took 93 seconds though, so I had to extend timeout limit on my nginx.

hmm, this one is caused by fix in the smarty engine. When iterating over array ends, smarty will keep the item variable alive -- referencing the last processed item: {foreach $list as $carrier} ... {/foreach} // at this point $carrier still references the last carrier in the $list The problem is when $carrier variable already exists before {foreach} statement. In smarty 3.1.19, original value was overwritten. That was deemed as a bug, and was fixed in newer version. Now the original value is restored. That means: ``` {assign var='carrier' value=1} {foreach $list as $carrier} ... {/foreach} // at this point $carrier contains value 1 ``` There isn't much we can do about that, really. We can fix this particular issue with OPC, but it's not really possible avoid this kind of bugs in general. https://github.com/thirtybees/thirtybees/issues/617

@dosbiner thank you for the info, this is quite strange error message. Do you have override for either controllers/front/ParentOrderController.php controllers/front/OrderController.php If not, could you disable all non-thirty bees module and try opening checkout page again?

Until this is fixed, you can bypass this validation. Edit file modules/stripe/stripe.php, and change lines 959..971 from php protected function tlsCheck() { $guzzle = new GuzzleClient(); \ThirtyBeesStripe\Stripe\ApiRequestor::setHttpClient($guzzle); \ThirtyBeesStripe\Stripe\Stripe::setApiKey('sk_test_BQokikJOvBiI2HlWgH4olfQ2'); \ThirtyBeesStripe\Stripe\Stripe::$apiBase = 'https://api-tls12.stripe.com'; try { \ThirtyBeesStripe\Stripe\Charge::all(); $this->updateAllValue(static::TLS_OK, static::ENUM_TLS_OK); } catch (\ThirtyBeesStripe\Stripe\Error\Api $e) { $this->updateAllValue(static::TLS_OK, static::ENUM_TLS_ERROR); } } to php protected function tlsCheck() { $this->updateAllValue(static::TLS_OK, static::ENUM_TLS_OK); }

It seems that endpoint https://api-tls12.stripe.com no longer exists -- domain can't be resolved to IP address. Github issue: https://github.com/thirtybees/thirtybees/issues/614

I'd like to ask for your cooperation with testing new version of smarty engine. As you might know, current version is rather old, and is not php7.2 compatible. There is a plan to upgrade smarty engine to newer version soon. This move is potentially dangerous, even though smarty syntax should be backwards compatible. It would be great to detect and fix any issues before this change is released. I've tested the new smarty engine on community theme, and it seems to be working correctly. But it's important to test other themes, and modules, as well. How can you help? First of all, this call for help is targeted for those of you who have dev / test environment. You can, of course, do this on your production site as well. It just bears some risks :) You will also need ssh access to your server Here are steps: upgrade you shop to 1.0.7 - there are few bugs in older versions that prevent using newer version of smarty. ssh to your server, and install composer: edit file composer.json, find entry smarty/smarty and change version from 3.1.19 to 3.1.31 (this is not the latest version 3.1.33 because that one has known bug) run composer update delete content of directories /cache/smarty/cache/ and /cache/smarty/compile/ switch to php72 [optional] Test your site and report any bug or issues. Please let us know even if you don't find any problems, so we know that it works fine with your theme.

Hard to tell what went wrong. There's probably some hint in your server's error log, or in thirtybees/log directory (if you have debug mode enabled). Regarding manual update - it's totally possible to go directly to 1.0.7. Just remember that you'll need to delete all stats modules, as described here. Simply follow the steps described in that article, the only difference is that you need to extract 1.0.7 version instead of 1.0.4

@AndyC pm me your domain, I'll issue a license for you. Note that I still don't consider this module to be production ready :)

thanks @Luv, I've created an issue for this on github

@Norwegian_Rat your server probably failed to download the zip files from those urls. Please check with your hosting provider that your server don't have any restrictions regarding remote file access.

This is obviously data related. I'd love to investigate, but it's not possible unless I can reproduce this bug. Therefore, I would need access to your backoffice + info for which can this bug be reproduced. Then we could figure out what's wrong.

@wakabayashi said in Full Page Cache - please do not use this feature: @datakick I am still very confused about red and green? Did you change this mechanics? I am on 1.0.3 and there green means: always load the hook without cache! In 1.0.7, as a result of changing behavior from opt-out to opt in, the colors are inverted. Red color now means slow (non-cached) hook, green means fast / cached hook. I believe this is what everyone would expect, anyway. You are right, in previous versions the colors were inverted, the green meant slow and red was fast. Weird

I believe the problem is on thirtybees side. In ps16, the class PaymentModule was located in /classes/PaymentModule.php. Thirtybees moved this to /classes/module/PaymentModule.php. That is compatibility issue, which prevents overriding. Module is trying to override file that does not exists in tb anymore

Smarty syntax should be compatible, so unless the module developer used some undocumented / unofficial syntax in their templates, the ugrade to the newer version should be fine.

@pilou said in Error message about Cache: Oh ok, for php7.2, I just read it was compatible in the post talking about 1.07. It still isn't. At the moment, thirtybees still uses rather archaic version of the smarty (3.1.19) that does not support php 7.2 properly. Because of few bugs in tb core code, it was not possible to upgrade smarty to newer version -- it throwed 500 errors on php72. These bugs were fixed in 1.0.7, so it's now possible to upgrade smarty to newer version. Upgrading smarty to newer version is considered to be (potentially) breaking changes, so it's not part of this 1.0.7 release. You can upgrade smarty to newer version yourself, and let us know how it works for you. Whether you encountered any bugs or issues, or if it's working correctly. Just don't upgrade to newest version 3.1.33, as it contains this bug. I've tested smarty on 3.1.31 and it seems to be working just fine.

@pilou said in Error message about Cache: Warning à la ligne 265 du fichier /home/www/********/classes/PageCache.php [2] Invalid argument supplied for foreach() To get rid of this warning, follow steps described above Unknown error à la ligne 75 du fichier /home/www/********/vendor/smarty/smarty/libs/sysplugins/smartyinternalcompilebase.php [8192] The each() function is deprecated. This message will be suppressed on further calls This is unrelated. You are probably using php 7.2, right? Thirtybees is no yet compatible with that php version

You can read more info regarding Full Page Cache here. tl;dr - unfortunately it's not safe to use this feature in any version of thirtybees I'm not sure if it's possible to fix the underlying problem properly. If not, maybe this feature will have to be dropped completely.