datakick

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

Can you enable debug mode to see the actual error message? Also, please attach your theme's config.xml file

I don't know what to tell you then. If we don't know what the error says, it's hard to tell what went wrong

You should delete this whole override file. I don't see any reason for it to exist, other than screw your store. Especially since there isn't any module reference. Once you delete it, don't forget to remove /cache/class_index.php file as well

This doesn't look like an override -- did you attached file from /override/... directory?

You need to figure out which override is causing this, and if you need it for anything. Most probably not... Look if there is override/classes/Tools.php file. If so, look inside... I bet hash method will be overwritten, for some reason...

What error is that?

Try to restore original IP address, as described here: https://support.cloudflare.com/hc/en-us/articles/200170786-Restoring-original-visitor-IPs-Logging-visitor-IP-addresses-with-mod-cloudflare-

I don't know what you did, exactly, but the zip file contains global.css file modified on Nov 19: > zipinfo niara-master.zip | grep global.css -rw---- 0.0 fat 178726 tx defN 19-Nov-29 14:56 niara-master/css/global.css Note that the zip file does not contain niara directory, but niara-master. If you simply unzip it, it won't replace your niara directory. You need to unzip it, and and move the content

Do you have latest version of core updater? Did you uncheck Ignore community themes switch before update?

I don't have free capacity to take on such project, unfortunately

The watermark module was not initially forked because there wasn't any license file in the github repository. License file is there is now, but the modules is already updated to work on ps17 only, so it would be harder to migrate migrate it back to work on ps16 / tb... but of course it's doable

Did you click on 'reset indexation status' button before you regenerated images?

I think you misunderstood the sentence. It does not say that only small images will be converted to webp. The meaning is that the resulting webp format is smaller

PS watermark module does not support webp format on output

Close, but not enough... we need to see what's in the response body

Your server throws some 5xx error, and we can't help you unless we know what it is. You can look into browser javascript console, in Network tab, and look for these 500 error responses. They should contain some more information

Yes, these radio issues are already fixed in new versions of niara theme, so forwarding themes to bleeding edge should fix the issue. Of course, if you have modified niara theme, you need to reconcile the changes manually

What tb version are you running? This should have been fixed in 1.1.0 already

I wouldn't be so sure this module was the root cause, it's possible it is just a red herring. From stacktrace, it's obvious that thirtybees is trying to download logo for some module from thirtybees repository. It is quite possible that it was 'tbupdater' module for which the logo image was being downloaded. If that's the case, then deletion of this module would hide the problem. But not solve it -- it might still be there, patiently waiting for another chance to manifest. I'd suggest additional investigation.

Looks like you have outdated guzzle library. First, check that your /vendor directory is up to date -- download thirtybees install zip file, extract it, and upload /vendor directory to your server. If this doesn't help, then the only explanation is that there's some module that comes with its own version of guzzle library, and this somehow overrides the default guzzle library that comes with thirtybees.

That's not true, for a valid query the result is an empty array. This method returns false if there is some other issue, for example references to unknown database table or column. And that's definitely a bug... I hate the fact that in non-dev mode thirtybees don't throw on these errors

Hard to tell what the problem is, there isn't any resource limitations in the module itself. But it can be caused by other modules -- I've seen modules that set php max exec time to 20 secs, and never restore it after their job is done -- things like this can affect other modules in pipeline