datakick

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.

Your thirty bees store has "trust store" file that contains root certificates of all trusted certification authorities. This file is outdated in 1.3.0, and does not contain new root certificate that Lets Encrypt uses nowadays. Which causes your store to not trust any servers that are using certificates issued by Let's Encrypt. Including thirty bees api server. To fix this, all you need to do is update to latest thirty bees 1.4.0. If you can't do that, then you will have to manually download the truststore file: https://raw.githubusercontent.com/thirtybees/thirtybees/main/tools/cacert.pem and save it as /tools/cacert.pem inside your thirty bees installation. There should already be this file, you have to overwrite it.

This is nothing new. The functionality to 'add products' to order is disabled once the order is switched to shipped stated... or something like that, I don't remember correctly.

it is blockcontactinfos:

Yes, you must set Database server address, database name, login and password. Server address is usually localhost, but can be different. You have to go to your cpanel and create new database there and db user that can access that. Use that info when installing thirtybees.

We can't help you if you don't tell us what the error was. Please provide screenshots. Also, look into your server error logs, and into /logs directory inside your tb installation. There might be some additional hints.

This one is something that guys behind smarty library have to figure out. We are just consuments of their library. They can't remove support for date format modifier, as that would break all smarty templates. So they will have to come up with some sort of internal polyfill for strftime function.

If you detect any error that is clearly caused by core, or native module, don't hesitate to file issue on github: https://github.com/thirtybees/thirtybees/issues Copy as much details as possible (omit sensitive data, of course) Sometimes it's hard to determine the culprit. The good rule of thumb is to look at the stacktrace, if there is any module mentioned. If there is, it's may be problem with that module. But still it can be issue with the core. If unsure, file github issue. The worst that can happen is that we close it as not relevant 🙂

Hi all, we have just released first version of collectlogs module. You should already see it in your back office module page. This module requires 1.4.0, so this is relevant to you only if you already updated your store. This is a very simple module, but it very quickly become one of my favourite. It's main task is to collects php errors, warnings, deprecations, etc, and displays them nicely in back office overview. You can also set up cron job and you will be informed by email every time new error is detected. This is great way to catch new errors early, for example when you install new module. In the module back office overview you can see list of errors, see how many times they occurred, when was the last time it happened, etc. If you click on error, you will see additional details and context. Note that these details are collected the first time error happened. All these information make it quite easy for a developer to figure out where the problem is, and reproduce it. For you, it makes it super easy to track issues with your codebase and slowly fix them. If you are, for example, planning updating to PHP8, I suggest you run this module in PHP7.4 for a while, and make your developer fix all DEPRECATION warnings. With those fixed, the update to PHP8 should be smooth. As a side note -- we at thirty bees offer support services, we can fix these issues with overrides and third party modules for you. Don't hesitate to reach out.

No, but you can restrict product to certain carrier, and that carrier can have zone restriction set up.

I believe there is no issue for that. You can create it.

Awesome, thanks for confirmation.