datakick

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.

@AndyCYes, you can use this one. Or you can purchase generic support hours, and if any hours are left, you can use it for other issues.

Hi @Norwegian_Rat Chex module is indeed compatible with tb1.4/bleeding edge, and it works nicely on PHP8.1. My own store runs on bleeding edge, PHP 8.1.13, and I haven't seen any issues with chex. There are few PHP8 warnings in revws module, they will be fixed in upcoming release.

Looks good. Congrats, you are not affected 🙂

of course, db prefix can be different: <PREFIX>scheduled_task

table should exists since 1.3.0

Hi everyone, we just had a support request related to high server load. Looks like there is a potential for infinite loop. That can have quite negative impact on server performance. This issue is actually not a bug in the thirty bees core. It looks like a bug in PHP itself, and only for some combinations of PHP and server time zones. I was able to reproduce the issue on PHP7, time zone US/Central. Not reproducible on PHP8 US/Central, or on PHP7 Europe/Prague. The issue is related to adding time interval to \DateTime object shortly before the Daylight Saving Time threshold. https://github.com/thirtybees/thirtybees/issues/1569 Just to be sure, you can look into your database: SELECT from_unixtime(last_execution), from_unixtime(last_checked) FROM tb_scheduled_task; if any of the returned datatime is around the DST threshold, your server is probably affected. To fix this, simply update all scheduled tasks: UPDATE tb_scheduled_task SET last_checked = UNIX_TIMESTAMP(), last_execution = UNIX_TIMESTAMP();

INDEX command denied to user -- this is sql error that your database server throws when your database user doesn't have sufficient privileges, in this case probably INDEX privilege: https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_index

Hi @AndyC I'm glad you managed to restore your store to working state. If you still need our help, you can purchase support time on store.thirtybees.com At the moment, I suggest you run your store on PHP7.4. Please read my previous post: