datakick

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

coreupdater does not have any dependency on tbupdater. It can work without it fine. However, without tbupdater module installed, native tb modules will not be automatically updated. So it is likely that you used some old and buggy version of coreupdater because of this. tbupdater module is indeed internally marked as deprecated. The functionality to keep other modules update needs to be moved to core, and then we can finally stop using this module. Until that is done, though, I recommend not to uninstall this module.

This is a regression. The root cause is that the code in 1.4.0 do not check if the input file needs to be converted to utf-8. We have to reintroduce this check. Tracked here: https://github.com/thirtybees/thirtybees/issues/1549 Workaround: encode your csv files in UTF-8 instead of ISO-8859 encoding.

This looks like killed ajax request. Something blocked the request. Maybe adblocker, firewall, misconfigured server, modsecurity, proxy server,... Look inside browser network tab, find the ajax request, and see what happened.

While you are still running your store on PHP8.1, go to core updater settings, and change target PHP version to 7.4. Then perform update -- that will replace libraries with version compatible with PHP74. Then you can safely downgrade your PHP version.

I'm running my store on php8.1 already, works very smoothly. While thirty bees core and most native modules are php8.1 compatible, third party modules might not be. The only way to test this is by trying.

You don't have to fix these db differences, but it would be better if you do 🙂 I know it says 'Dangerous' for some of them, but it is not, really.

Yes, it indeed looked like a small issue, that's why Smile provided you with optimistic estimate. Further evaluation proved otherwise, though. The fix would be very simple, few lines of code. But it has the potential to create a huge clusterfuck of other problems, so we decided against it. The problem is that thirty bees sometimes uses country code in context when language code should be used. In most cases it does not matter, as country and language iso code are usually identical. However, for Estonia, this is not the case. Country iso code is ee, while language code is et. If we fixed the problem in the core and used lang iso code properly, it would fix some translation issues. However, it would also have unwanted side effects. For example, et would be used in url instead of ee, so all urls (for multilang sites) would change from www.site.com/ee/category/product.html to www.site.com/et/category/product.html I bet that somebody would complain about that, as it would mean lost of all incoming links. At the moment we are aware and track this problem, but we are unsure how to safely fix it.