datakick

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.

tl;dr : Full Page Cache should still not be used at the moment Update regarding Full Page Cache in thirtybees 1.0.7 Thirtybees 1.0.7 version contains couple of fixes to FPC that tries to solve most of the problems described here, including quite serious security bug. Unfortunately it seems that there is another issue that makes this functionality unusable. What is FPC, anyway The theory behind FPC is really quite simple. Thirtybees will save rendered page into the cache, and any subsequent request to the same url will be served cached version. There is also a mechanism that removes entries from the cache when related database entities changes. So, for example, when product gets updated, all cache pages related to this product be removed from cache. This works nicely, as long as there aren't any modules that hooks to the page. We can't just simply cache html content generated by module. We don't know what that content is, and what event should trigger removing this content from cache. As an example, imagine review module. Such module will have some hook to display review list on product page. Now, what happens when we create new review, and the FPC is enabled? This new review will NOT be displayed on product page, because thirtybees does not know that it should flush cache when there is a new review. It only knows to flush cache when the product itself changes. On the other hand, there are many modules that generates content that is safe to cache, because this content depends only on related entity (product). For example, module that changes color picker. This is the reason why FPC allows you to choose hooks which content should be cached, and which not. In older ( <= 1.0.6 ) versions of thirtybees, all hooks were cached by default, and merchants could only decide which hooks should NOT be cached. This opt-out principe was really a bold decision, and it caused many modules not to work by default (reviews module, nocaptcharecaptcha, newsletter, etc...) So, for 1.0.7, we decided to change this to opt-in -- hooks content are not cached by default, and merchants need to decide which one to cache. This should make the whole system more reliable. The bug Unfortunately, the mechanism that dynamically evaluates the hook and injects the fresh content to cached page contains a bug. And it's a nasty one, one that can acause 500 error code on some pages. This bug was always in the code, it just didn't manifest so often, because all hooks were cached by default. You could reproduce the same error even in 1.0.6 code, if you toggled the hook from cached to non-cached state. It's possible to get rid of these 500 error codes even in 1.0.7 simply by making all hooks cacheable (toggle them to green). But then many modules will stop working correctly. Conclusion At the moment, the FPC is not usable. Not until we fix this newly discovered bug

@purity said in Release 1.0.7 is there!: Seems to work fine with everything toggled green. Do you remember the old Pentium division flaw joke: Sure it gives the wrong answer, but look how FAST it is! This is probably what's happening to your site right now. And it's been that way ever since you've enabled full page cache. This feature never worked correctly, not even in previous versions. I'll describe what's wrong in another thread later.

@Purity, could you please try this: toggle all hooks from red state to green, then enable Full Page Cache again, and test the front end again? I'm afraid I know where the problem is. If my hunch is correct, that would probably mean that Full Page Cache is beyond saving...

@purity said in Release 1.0.7 is there!: Where is the correct place to report an issue with the full page cache? It's sending certain pages to 500 error on my installation. I did delete the cache/class_index.php What is the error message in the log?

@the-rampage-rado It should. The error on frontend was still there even after cache cleanup?

@the-rampage-rado said in Release 1.0.7 is there!: Just few impressions about 1.0.7 caching stuff: When I just click enable and all hooks are red the front end gives me 500 and few parts of the page (very strange error, I've never seen it like that). The following days I will check what could cause this. I also had problems logging in in BO but this I imagine was caused by not deleting the cache prior to uploading the files. There's one more step that needs to be done when manually upgrading to newer version of thirtybees. The file cache/class_index.php must be deleted. This file contains information about core php files and their overrides. Thirtybees tries to keep this index up to date, it gets rebuild whenever you install/uninstall modules, during system upgrade, etc. But thirtybees will not detect when you add or remove core php files manually, for example using ftp upload. When this file is out of sync it almost always results in 500 error code. I think this is the case -- there is now core php file PageCacheKey.php, and with outdated class_index this file will not be loaded. I've modified the first post in this thread, and added this step