datakick

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.

Illusion of working is not working. You can ignore the problems, but that does not make them go away. Maybe you don't use facetted search. Maybe you don't use webservice. Maybe you don't generate reports summarised by feature values. Maybe you don't have to solve mapping issues when sending data to third party parters like Channable. Maybe you don't search for products by feature value... Maybe these issues are not relevant to you specifically. Then you are lucky, and you can really decide to ignore them. But for a lot of merchants these are real problems that needs to be addressed. Not by hiding them.

You probably didn't understood what I talked about. Previously, only predefined feature values could be reused by products. Custom values could have been created individually per product, but could not be shared. So, you could create predefined value '10mm' and use it by product A and B. You could also create the same custom feature values, with the same value, for product. This custom feature value had different ID, yet the same value. Now, take faceted search on front office for example. Search by feature values would first retrieve all distinct feature values IDs, and display their texts. There would be 2 feature values with the same text displayed, because there exists two different feature values with two different IDs but with the same value. You would be very surprised why the front office is showing two same feature values, especially since the back office shows only one (the predefined one). You would be complaining about the faceted search functionality, that it is broken, or whatnot. But the reality is that it is doing exactly what it is supposed to do. It's just you have shit data quality. By showing you in the back office the same information, we are actually removing this surprise. Showing you the root cause of the problem -- data. In 1.4.0, we did not generate your data out of thin air. We just showed it to you. If the duplicates causes problem in back office, imagine how much trouble it causes elsewhere. I suggest you to clean up your data. Merge duplicates. Clean up the shit. That will solve all the issues. This new one (back office mess), and the existing ones (the mess in front office, exports, api, etc) You can opt to ignore the mess in your database, of course. But we don't want to ignore mess in our databases, though. Hence this "enhancement". What language problems? You understand that we spent hundreds of hours maintaining the system you are using to power your business, don't you? You know, all those pesky deprecation warnings and notices that we fixed will not be warnings in the future php versions. They would be hard errors. Yeah, we fixed those. In my book, that is what you get for donating to the project. You are welcome.

Basically, we have removed the 'Custom' feature values functionality. Custom feature values allowed you to create ad-hoc feature value from your product back office page. However, this feature value existed for that particular product only, and could not be shared. And it was actually hidden from everywhere. Example: You could create feature value '10mm' for product A, and then create the same custom value '10mm' for product B. In database, this would be recorded as two distinct feature values. Custom feature values were causing a lot of problems and troubles. It made it very hard to use faceted search, because the same value existed multiple times. It made it impossible to search for products that shared the same feature value (because they were not actually sharing the same feature value, they only shared 'feature value' value). You didn't see custom values in list of feature values. This all lead to a very poor data quality. Or, as you quite nicely called it, a big piece of shit. This issue was always there, it just was very carefully hidden so it doesn't offend anyone. But hiding it doesn't fix or hide the other issues it causes, so we decided to stop playing this hide and see game, and just show you what you have in database.

Most likely.