datakick

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

Localization > Translations You can unhook it in Modules > Positions Again Modules > Positions Probably a bug, file a github issue

You have to change database tables to ps_category_lang, and slightly adjust columns -- categories don't have short description, or availablility fields. Result should look like this UPDATE ps_category_lang dest INNER JOIN ps_category_lang src ON (dest.id_category = src.id_category AND dest.id_shop = src.id_shop AND src.id_lang = 6) SET dest.description = src.description, dest.link_rewrite = src.link_rewrite, dest.meta_description = src.meta_description, dest.meta_keywords = src.meta_keywords, dest.meta_title = src.meta_title, dest.name = src.name WHERE dest.id_lang = 7 AND dest.id_category IN (3, 4, 5)

Thanks @Petter for the tip, I'll definitely try this nginx extension myself

@Smile it would be great if you would file an github issue, describe behaviour and include some repro-steps,... so this can be fixed

It will either add records, or update them, depending on how you set up import

No, it can't. The issue you are referencing is about something very different, it has nothing to do with this new problem on bleeding edge. I've filed a new issue to track this new problem https://github.com/thirtybees/nocaptcharecaptcha/issues/8 Note that while we can fix this in the module, we need to fix the core as well

You may hate it, but it's kind of a standard. Everybody knows what it means and they have learnt to click on it subconsciously. If you, however, put some slide thingy on your page, it's not so obvious. You make your visitors think, and that's basic UX issue

The exception says it all - the module contains method printForm that expects 3 input parameters. However, module calls this method with 2 arguments, resulting in php error. Previous versions of php were more lenient, and such call triggered only warnings / notices. But in php7 it's no longer permitted. You should modify the module, and change signature of printForm method from public function printForm($vip_add, $vip_end, $vip_cards) { ... } to public function printForm($vip_add, $vip_end, $vip_cards=null) { ... } This will explicitly mark third parameter as optional, making php happy

Bleeding edge? If so, then it's in object model metadata

Anyone reading this might want a lazy version of Zen's solution. It works on Chrome desktop and I guess on most browsers. It is a bit of style sheet to add from the back office, over-riding the styles that need changing rather than editing them. Back > modules and services > custom code | add css /* Niara 1.1 patch to make radio buttons work */ input[type="checkbox"] input[type="radio"] .attribute_radio .attribute_list { cursor:pointer; opacity:0; position:absolute; width:auto!important; float:none!important; margin:auto; right:auto; left:auto; } Another solution is to download latest version of niara theme from github. This (and many more issues) are already fixed there

That's correct, the $.each rebinds this to the current item. Please file a github issue for this bug

The module does not really work on php7, unfortunately. That's because of some regular expression incompatibilities. I've managed to fix it locally, and will release it soon. But even with this fix there are other bugs, for example js code that generates elastic query can generate invalid expression...

Maybe you are using nginx with incorrect rewrite?

Of course you can disable the email. There are many ways to do this: disable / uninstall module edit module and comment Mail::Send command delete email template install conseqs module and set up rule to block this particular email and more... I personally think it's not very good idea to do this, though. You should always verify that the trap didn't catch some valid bots / users. It shouldn't be such a big deal - with properly set up robots.txt, you should catch only a few bots per month. I personally receive the email maybe once every two months