datakick

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.

By 1.4 you mean bleeding edge, right? Because fixes are in the bleeding edge. If you, by any chance, updated to 1.4.0 (stable release) again, you would get the same buggy version as before.

That would be unfortunate. This is actually one of the main reasons why we need to implement core updater to be independent on tb core. Unfortunately, that's still not the case. If you can't access the modules page, you would have to perform the php downgrade manually. You can go to https://thirtybees.com/download-specific/ and download zip file for your target php version (7.4). You can then unzip it to your server installation. All you have to care about is the /vendor directory, actually.

When did I wrote that this was user error? In fact, I even wrote To me that sounds like I were saying that the problem is in the software. I wrote that there is zero dependency between coreupdater and tbupdater. And that's the fact. I've looked inside the code of both modules to prove it. I've even tested it by deleting the tbupdater module. The coreupdater module worked absolutely fine. There is no dependency. Moreover, tbupdater modules does not implement any hook handlers, have no overrides, and all classes are in their own namespace. This means that the tbupdater module lives in absolutely isolated environment. Its code is not executed unless there an explicit interaction. And there is none in coreupdater. Prove me wrong, delete the tbupdater module from your installation and test coreupdater to see if you reproduce the issue again All that investigation points me to a simple conclusion -- after you installed the tbupdater module, you were able to update coreupdater to new version, which fixed your problem. Installation of tbupdater module did not fix the issue, it just enabled you you to fix it. How? Without tbupdater module installed, the system would not show you that new versions are available. Did you manually check github repository of all native modules, and manually downloaded and installed the latest versions?

ok

The plan is to have general-purpose back office system for managing customer communication. Something similar to current Customer Service, but with additional features -- filtering, predefined messages, automatic assignment, etc. This part will have no dependency. And then there will be lot of small modules that can plug into this system to provide incoming and outbound communication channels. Some of these modules can, of course, implement their functionality using external service that you will have to subscribe to.

Fixed both in in main and in 1.4.x branch.

@wakabayashi thank you for your work on this one. Please create PR for your changes. This functionality indeed needs a lot of work to make it useful. I think that this should not be part of the core, though. RMA functionality could be implemented as a separate module. If there is some need to modify core to better record or track returns and refunds, we can extend the core, but I don't think there is anything like that needed. You don't have to worry about moving this to module yourself. It's actually on a todo list for the future. All enhancements you implement will be transferred as well