datakick

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

The module is stupid. It performs email search only during installation. And it also looks only inside /mails/en directory, and ignore all theme and modules email templates. The fix for you is to put your custom email template into this directory, for example /mails/en/my-template.html, and then reset module. If you don't want to reset, you can add the entry into database table tb_aeuc_email manually. mysql> select * from tb_aeuc_email; +---------------+------------------------+------------------------+ | id_aeuc_email | filename | display_name | +---------------+------------------------+------------------------+ | 1 | account | Account | | ... | ........ | ....... | | 32 | voucher_new | Voucher new | +---------------+------------------------+------------------------+

And what is the question?

As I wrote before - nobody deleted or changed anything. The functionality in 1.4.0 is the same as before, the same behaviour was in ps16 as well. It's the same since 2013/2015 at least: The code says that if order went through at least one state that has 'Delivered' flag set, then order is considered delivered, and therefore add products button is disabled. We didn't changed, and don't plan to change this logic anytime soon 🙂

Plan is to remove it from core. Sending email functionality will be implemented as a system/library module. We want to reduce third party dependencies from core as much as possible. It will be up to merchant to decide which email module to install. There can be module that sends emails using standard 'mail' php function. There can be a module that uses this legacy SwiftMailer library. And of course, a module that will implement sending using Symfony Mailer. I personally plan to implement module that will send emails using mailgun rest API. I'm sure there will be demand for amazon SES, although that can be part of symfony mailer as well...

Then there is a question how existing documents are impacted by adding new products to order (I mean invoice, delivery slip, etc). In some countries there are strict laws that prohibit modifying existing invoices once they were delivered to end customer (my country is one of them). In thirty bees, we should consider invoice to be delivered upon creation -- even if email is not sent to customer, they can still download it from their account. Maybe thirty bees is smart and generates new amendment invoice automatically. But maybe it's stupid and it modifies existing one, which could cause you a trouble.

Great stuff. I also recommend using php7.4 and fix all those issues there. I just want to remind everyone that if you are on 1.4 you can use collectlogs module to track those issues in summarized way, without the need to search inside php log files. The module will show you both paths to compiled template file, and to source file as well.

Hi everyone, just a friendly reminder that next major release will not support PHP7.3 and older. Lowest supported version will be PHP 7.4.