datakick

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

Ohh, that's a bug. Fortunately it's nothing serious. It just means that there's no settings for full page cache hooks in the tb_configuration table. You can safely ignore this warning. If you have debug mode enabled, then it's probably hard to do, though. Note that you should never enable debug mode in production environment. To get rid of this warning completely, simply follow these steps: 1) go to Advanced Parameters > Performance, 2) find section Full Page Cache 3) turn on and off any one of the displayed hooks. This will create the missing setting option in configuration table, and the warning will no longer be in the log. Sorry for the trouble, folks

@smorjkompaniet pm me your domain, and I'll restart your trial. Note that my module supports xml import only

Hello everyone, I just wanted to advice anyone who is using Full Page Cache to turn this feature off. I just found very serious security bug in the code. Nobody should use this feature until it's resolved. Edit: There were many bug fixes in thirtybees 1.0.7. The security bug was fixed as well, but the whole functionality is still NOT usable

Are you using community theme? I've tested it, and it works just fine there

@janex - this can be really caused by many different things: misconfiguration of your server font actually missing on your server you can be using Media servers with incorrect Access-Control-Allow-Origin settings some css might override font family on icon-* css class and many more That's why I wrote start with javascript console in web browser. Is there any error in console, or in network tab? If there is, what it says? If not, then examine html element where the icon should be, and look what font-family it uses... I could tell you what's wrong, but I'd need access to your back office first

Looks like font awesome is not loaded for some reason (Access-Control-Allow-Origin maybe?). Open your javascript console/network tab and look for errors there, that should help you understand where the problem is

That's misconfiguration of your mysql db. I suggest you follow this recommendation

This is a bug in 1.0.6 that's been fixed. Thirtybees (should) come with random_bytes polyfill, but this polyfill not part of 1.0.6. The only code that uses this random_bytes function is Rijndael encryption, and this is going away soon. There are alternative encryption methods, so the easier way to fix this is change to different encryption. Log into your database and go to the <PREFIX>_configuration table. Find a key called PS_CIPHER_ALGORITHM and set the value to 2

@rubben1985 that's the thing with development, things that seems easy are usually the hardest one to implement :) There are really many areas that needs to be carefully adjusted - review criteria - it's not possible to use criteria for products - review lists - ensure that it's filtered by correct entity type. We don't want to mix different type of reviews together. This applies mainly for customer reviews page / all reviews page - email templates should be different / modified - there's no product title or image for shop review - rich snippets - store reviews needs different metadata than product reviews, otherwise google would be angry - review export needs adjustment - review import - and who knows what else :) But yeah, this feature is really needed, I get asked for this a lot.

@the-rampage-rado: Looking forward to the custom 'stars' feature! I'm a bit reluctant with implementing this feature, because couple more features will not work with it correctly, or will require custom hacks. For example sizing, half-stars, etc... But I'll probably implement it anyway, there are quite a many people what want this. @rubben1985: Do you plan to include store review? It's in the backlog, but it's a huge feature. Also, I probably make it a bit more generic, because there are people who want to review other things as well. For example brands, sellers if they have marketplace, etc... I haven't decided yet, but given the amount of work associated with this feature, I'll probably make it part of a premium module only.

Make sure you have routes defined for all languages.

Version 1.0.20 - support for images I'm happy to announce that new version 1.0.20 has just been released. This version fixes few bugs, and brings one major new feature - support for images. Your customers can now attach images to their reviews: Other changes extracted css classes to allow popup window customization - issue #71 fixed multistore bug in all reviews page - issue #68 check that dom php extension is loaded and more...

@b_otho said in Updating to 1.06 - Error with "Address::isDeleted": I just tried clearing APC cache through the module. Didn’t help. Please open file classes/Address.php and ensure that it contains method isDeleted, it should be somewhere around the line 385. ``` public static function isDeleted($idAddress) { $row = Db::getInstance(PSUSESQLSLAVE)->getRow( (new DbQuery()) ->select('a.deleted') ->from(bqSQL(Address::$definition['table']), 'a') ->where('id_address = '.(int) $idAddress) ); if (!isarray($row) || !isset($row['deleted'])) { return true; } return (bool) $row['deleted']; } ``` If the method is there (as it should, otherwise this file should be mentioned in Changed files list), then the issue really must be with the php cache.

@b_otho said in Updating to 1.06 - Error with "Address::isDeleted": Dyou mean Advanced Parameters > Configuration Information? I cannot see that anything should be wrong. If there are no changed files listed than it should definitely work -- the only other explanation is that the php APC cache wasn't flushed, so it's still uses the original php file.

@b_otho method Address::isDeleted was introduced in 1.0.4. Could you please verify that *all* files have been updated correctly - Simply open Configuration Information to see if there's any changed file. It is possible that updater could not update Address.php file, for example because of wrong owner or file permissions.

@b_otho the sql issue is already fixed in newer version. You can either update, or apply this fix manually

Work on this project has been temporarily suspended, I plan to return to it later this week.

@doclucas the sheet is no longer accessible, could you please fix the sharing permissions:

It is very strange that it happened only occasionally. The message from error log is still needed to figure out what went wrong, though. Could you please look into your server's error log and copy the error message here.