datakick

The idea behind tb project is still the same - to maintain compatibility, and have stable and bug free product. Feature development was never a big part of the mix. But that's ok, as tb core is already feature rich. Of course, sometimes breaking compatibility changes have to happen. Smarty upgrade is an excellent example -- we had to upgrade smarty library to newer version, because old version was not compatible with php 7.2.

turn off demo mode in upper right corner

I'm not going to spend any more time on this. I did plenty of tests today, and none showed any problem or issue. I need some concrete steps to reproduce the problem on a community module. Without it, I assume the problem is in third party module(s) itself.

I did all my best to reproduce this problem on vanilla tb / niara. To no avail - caching seems to be working correctly. I'm afraid panda author found some specific way to break stuff, but without access to its code I cant help

I agree, this will be included in niara

@wakabayashi I'm sorry but I dont eally understood what the issue is. Could you please try to explaon once again... How does this issue demonstrate on the front end?

Can anyone reproduce this issue with non-panda modules? I tested the caching functionality on bleeding edge with 'homefeatured' module, and it works correctly.

Try this <a href="{$link->getPageLink('index')|escape:'html':'UTF-8'}" title="{$shop_name|escape:'html':'UTF-8'}"> ... </a>

What cache are you talking about? Smarty? Full page cache?

The inherent property of forum posts is that they get out of sight very quickly. Developers don't even notice them most of the time. It's not like we are sitting 24/7 and reading everything you guys post here. I usually open forum for 10 minutes during my coffee break. During those 10 minutes I manage to read notifications, answer some PM. And sometimes I can even read some posts. One or two of them, at most. I never get a chance to read them all. Sometimes it's obvious from the post that there is some issue that should be fixed. I usually open a github issue for it. But sometimes I might not have enough time to do it. And when that happens, I usually I forget that I ever saw such post, and github issue is not filed, and it will never be fixed. If you, on the other hand, filed a bug report directly on github, the bug will be addressed eventually. It might not be immediately, but it will be eventually. The bug will be visible to all developers (even those that don't visit forum) until it's closed. To post bug repots on forum seems to me like a waste of time -- if no developer sees it, the author wrote it for nothing. If developer sees it, he must spent his own time to copy it into github issue - that's a time that he could have been spent on actually fixing the issue... Obviously that was 'call for help', and forums are ideal for such calls. Don't you agree? And, by the way, that post clearly states that "If you find any bug, please report it to github. https://github.com/thirtybees/thirtybees If the problem is not posted on github, it will not get fixed. You can take a chance and hope that some dev will notice your post here on the forum. Or you can file that issue directly and make sure it will get noticed.

Let's start with problem #2 -- iso code can't be used multiple times. This is valid requirement, there are many places in the codebase that expects that only one language exists for every iso code. For example, method Language::getIdByIso($iso) is used multiple times, and it returns 'id' of language. If there were two, or more, languages associated with the same iso, what id should be returned? First one? Random? None? Throw an exception??? There would be many areas that would stop working correctly (ie, problem #1) Now, with this in mind -- how the hell did you managed to have two languages with the same iso code? Since it's not possible to achieve this from back office (problem #2)

As long as you keep 'Friendly URL' the same you can rename your product name to whatever you want, it should not have any negative SEO impact

I believe the culprit is javascript file /modules/addtocartfromurl/views/js/bootstrap.min.js It contains some very weird string that makes the entire file invalid - when you load it into the page it throws syntax error. When this file is joined with other scripts into smartcache javascript bundle, it will probably make the entire bundle invalid as well.

BTW, I've tested free orders on bleeding edge, and it works as expected

Javascript smartcache concatenates all javascripts file to single file. While this reduces the amount of resources on the page, it has one big drawback - scripts are no longer isolated from each other. If initialization of script A throws an exception, it can prevent script B from running. This option should be used only when you are 100% sure all your scripts on the page works OK. Never enable this smartchase if you can see any red lines in javascipt console.

Module 'blocknewproducts' does not implement displayHome hook. That's not a bug in the system.

Not sure what the problem is, I've just tested the functionality and it work for me without any issues. Maybe try to unhook the hook once again, and this time open console and look in networks tab for any errors

Also, note that you can translate only one 'section' at the time. It's a bit unfortunate

I can't reproduce this. Can you show some screenshots?

Talking about bugs on forum is not bug reporting. Forum is (should be) primarily used for discussion between users, and not as a communication channel with developers. When you find a bug, please file a github issue. Try to describe it as best as you can, come up with reprosteps, etc... That way it will be tracked, and it will not get lost in the forum archives

Include the top line into your expression. Something like this should do the trick {if ($page_name == 'search' || $page == 'order-opc')} <meta name=”robots” content=”noindex,follow” /> {else} <meta name="robots" content="{if isset($nobots)}no{/if}index,{if isset($nofollow) && $nofollow}no{/if}follow" /> {/if}

Have a look if you have these changes included in your code: https://github.com/thirtybees/thirtybees/commit/f3f0f1ab2538633111fdb902a7f2a40cbb835ae6

I wouldn't say that it doesn't work. It does work quite nicely. The problem is that many modules are written in a way that just prevent any caching. For instance, consider module that implements hook 'displayHome'. Thirtybees assume that, since this is displayable hook, its output can be cached. But this assumption might not be true. The hook can have 'side effects' if the hook is not called every time page is rendered, the module will not work as expected. For example, this hook it can insert or update data in database, perform webservice call, do captcha validation, etc... TB, of course, have no way to know which hook implementation are 'pure', meaning its output is based solely on input parameters, or which are impure (with side effects). So it can't automatically decide what output should be cached, and which not. Unfortunately, merchants have to step in, and do this decision -- they have to mark which hooks are cacheable, and which aren't (using those red and green toggles). The problem is, of course, that merchants don't have this information as well. Then can only experiment, and see what works and what now,... and hope for best. So, it's pretty easy to come to the conclusion that the OPC is broken These are the reasons why usage of OPC is not encouraged. It exists only because some very tech-savvy merchants use it to fine tune their store, but for general audience it's not really useful. Thankfully, tb is pretty fast even with this cache disabled. I would, actually, vote for removing this from core to separate module.

Your theme probably doesn't support webp. If it does support this feature, it must be marked in theme's config.xml file, like this

Version 1.1.2 has been released few days ago with the fixes. No need to manually apply the fix, simply download the latest version