datakick

niara theme (and probably others) has its own override for homeslider template that tries to pick images from /modules/homeslider/images/ directory. You need to update this override template in niara theme: /themes/niara/modules/homeslider/homeslider.tpl changes are described here: https://github.com/thirtybees/niara/commit/15e5338e628fca184a339d6cde66c961bfeb8169 or simply download this version and use it to replace the one in your theme: https://raw.githubusercontent.com/thirtybees/niara/15e5338e628fca184a339d6cde66c961bfeb8169/modules/homeslider/homeslider.tpl

I just released new version that strengthens the address manipulation logic. Hopefully that will fix this issue. Also, I added one last-second validation check. This one ensures that address belongs to customer, and is performed just before the final redirect to payment. So, if the strengthening of address manipulation did not work, this one at least block the order creation. Please test

Oh, this is another niara theme checkbox issue, similar to this one: https://github.com/thirtybees/niara/issues/6 The fix will be similar as well. Let's track it under https://github.com/thirtybees/niara/issues/66

Unfortunately I was never able to reproduce the issue, and I didn't found any problem with static code analysis. I don't know what to fix. I don't know how to verify that the fix 'fixed' the bug. I need some repro-steps, but nobody was able to provide that yet.

Check overrides.

If you updated first by automatic update, then it wiped out your slides. You will have to upload them again. Slider box size can be set in module settings page. Set 'Maximum image' width to 799 to achieve the same sizes as were default in previous version.

Hi everyone, We have just released homeslider v2.1.0 This module fixes long-standing issue with deleting slider images during updates. From now on, images will not be stored inside module directory, but instead inside global /img/homeslider/ directory. That way, they will survive module updates. Note: that if you update to this version using automated system (tbupdater), you will still loose your slides images (because they are not yet moved). To prevent this, you need to download the homeslider zip package and install it manually https://github.com/thirtybees/homeslider/releases

Fair enough, I will release already fixed modules

That's correct, datakick module does not trigger any object model hooks. It does not work with object models, but directly modifying data in database. That way, it can manage to import/update data very fast. The drawback is the limited interoperability with other modules, like in this case. It is similar to direct data modification using phpmyadmin -- when you change data that way, hooks are not triggered as well.

Spanish translations exits and are accessible -- you can click on the es.gzip link to see that it can be downloaded. If it did not work in your case, then the issue could be connectivity / internet outage thirty bees api server/datacenter outage your server is not allowed to make outbound connections -- check your php settings.

I have added PHP8.2 build. You should be able to update to bleeding edge now

thirty bees webservice uses the same concepts as prestashop one. You can refer to their documentation: https://devdocs.prestashop-project.org/8/webservice/. The only significant difference is that thirty bees does not support partial updates yet - so no PATCH requests

Yep, this is a bug. Fixed in bleeding edge

Advanced Parameters > Performance > Media Servers Note that this also affects other assets like css and js files. And some modules (and maybe even some core code) sometimes generates direct url, so you still have to keep the original images on your server.

Thanks for confirmation. This was a bug in theme, not in core. It should be fixed when updating to new version of thirty bees as long as you have Update community themes option enabled.

What tb version? I believe this was fixed already https://github.com/thirtybees/niara/commit/f56c79cd8566f349dec81c40ce9c8cd2f5a41864

Yes, it will be part of next version of collectlogs module.

@wakabayashi this is an indicator that there is some issue within smarty lib regarding cache directory cleanup. That's good to know 🙂 Bad thing is that collectlogs consider these as a separate issues (because of different error message). To fix this, you can add new line into database table <PREFIX>collectlogs_convert_message This line should help: INSERT INTO tb_collectlogs_convert_message(`search`, `replace`) VALUES("/^rmdir.*Directory not empty.*/", "rmdir(): Directory not empty"); Collectlogs will then track all these errors under single issue. You will probably want to clean up your tb_collectlogs_logs table afterwards 🙂

collectlogs module does the similar thing already -- it groups the same errors together. The difference is that it does it in runtime, and not by parsing server error files. There are few reasons why we used runtime method instead of log file parsing. The most important one is that we can collect additional information like context (server variables, application state,...) and stacktrace. Other reason is practical -- server error logs are usually stored in a directory that is not accessible by web application (ie /usr/local/var/log/php-fpm/error.log). If we tried to open this file from PHP app, we would be blocked by php security settings.

There is already bulk delete implemented (will be in the upcoming version), so that would be a workaround for this. My idea is to have some sort of 'resolved' status, where you could mark issue as resolved. Resolved issues would be hidden from the list, but could be returned if the issue re-appeared. There could be different resolve statuses, like 'Resolved in the upcoming releases', or 'Resolved in the next version of module', 'Resolved' etc

I have fixed this bug in blockview native module. You can copy changes to SunnyToo clone, since it's the same mod.

Yes, thirty bees $cookie object is transient storage available for any module developer. Anyone can add anything to that object. Thirty bees core only manages very small subset of these properties. In your case, ga_cart is added by ganalytics, viewed by blockviewed. Looks like blockviewed does not implement any limits... Edit 1: I have filed issue for blockviewed module: https://github.com/thirtybees/blockviewed/issues/4 Edit 2: panda modded version blockviewed_mod by SunnyToo is also affected.

as I wrote -- you should look inside the cookie. Since it's encrypted, you probably have to modify or overwrite Cookie class. Before this line: https://github.com/thirtybees/thirtybees/blob/bdeec484a5029102a368e311b6a7990b14185904/classes/Cookie.php#L245 you can add something like // change to your IP address $myIpAddress = '108.132.123.123'; if (Tools::getRemoteAddr() == $myIpAddress && strlen(Tools::base64UrlEncode($content) > 3000)) { d($this->getAll()); } That will kill the script and display content of cookie (for your IP address only). Also, note that browser is complaining about 'combined' size, so you might need to tweak the size limit a little.

You will have to look inside cookie to see what makes it so huge. Some module will probably store something interesting in there. Also, you can try changing encryption algorithm. On my local default installation, Blowfish algorithm returns cookie with length=357, while PHPEncryption algorighm returns cookie with length=613. However, Blowfish is not recommended, as it's much slower and less secure.

PHP 8.2 will be officially released soon, on December 8th. I have tested thirty bees 1.4 on PHP 8.2 release candidate, and the results are mixed. The good news is that the system does work properly on 8.2. I didn't found any new error or exception. If your store runs on PHP8.1, you should probably run on PHP8.2 as well. The bad news is that there are a lot of new deprecation warnings. And by lot I mean a lot. It's even worse than the PHP7.4 deprecation warnings, and that was a hell. It will take us a long time to fix these in core and native modules. If you can, please run your test env in PHP8.2, and report all warnings on github. Unfortunately, most third party modules will have to be tweaked as well, because of the new Dynamic Property deprecation warning. Almost every third party module I looked at was raising this deprecation warning. Fortunately, the fix for these type of errors is usually very easy -- simply declare property as public should be enough in most cases. Sometimes it's not, though.