datakick

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:

Hi @Cassim, could you please post github link to your modified version?

You used stmegamenu.php file modified by @musicmaster. However, he modified different version than you used before. You can't really mix and match (modified) files from different versions of the same module.

This module uses syntax that is no longer supported. In this particular case, the line should look like this: if ((int) $num1[$i] > (int) $num2[$i]) { Similar change needs to be done on line 2731. The question is how many more issues like this will be in third party modules. It's not really safe to switch to PHP8 without preparation steps. I suggest you follow these steps to make your store php8 ready: switch to PHP7.4 disable cache in Advanced Parameters > Performance, so compile-time errors are detected install collectlogs module - it will create new menu item Advanced Parameters > Error Logs watch for every Warnings and Deprecation types of errors this module collects. Most warnings / deprecations in php7.4 are upgraded to errors in php8 proactively click on every front and back office page so you detect as many warnings as possible Once you fix these warnings/deprecation (no new recent occurences) you can safely switch to PHP8 when you switch to PHP8, don't forget to go to Core Updater and update your store again -- this time for code specifically build for PHP8. Once you do this, you can't switch php back to 7.4, though -- you would first need to use core updater to downgrade your code for lower PHP first

#1 - Did you clear your cache after you uploaded new template? If not, it's possible smarty still used compiled version and ignored your changes, resulting in error. #2 - this bug was already fixed in themeconfigurator module. Go to your modules page and update this module to latest version. If no new version is available, it's probably because you are using 'prestashop' version -- updater will not offer updates if author is not 'thirty bees'. If this is the case, you can either uninstall, then delete, then refresh modules page and install tb version. Alternatively, you can download themeconfigurator module zip file and upload it manually https://github.com/thirtybees/themeconfigurator/releases/tag/3.0.10

I believe that you are talking about 'company' field stored inside Address. So you will have to base your rule on this record type -- when new address is created / existing address updated, do something. Trigger: Conditions: Action: Then you just have to figure out how to solve situation when customer have multiple addresses, one with company field set and other empty.

It works, I tested this recently. The problem will be in understanding what 'Company' field is -- this field is present only if you enable B2B functionality. It is NOT the company field that you specify in address.

Bug tracked here: https://github.com/thirtybees/advancedeucompliance/issues/15