datakick

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.

Your question is not very clear. "now this whole page of features looks like big piece of shit" -- what page of features? This post was originally about front office "Data Sheet" section, and it's translation. Are you referring to this section?

This is bug in ultimatedatabaseoptimizer module -- module constructs invalid sql query, and database raises error. New version of tb reports all invalid sql queries as errors. Previous tb versions silently ignored these errors. You can force the original behaviour (see Advanced Parameters > Performance > Ignore SQL errors), but I strongly advice against it. You should contact module developer and ask them to fix the bug instead.

That's because this is not an application issue, but deployment problem. Thirty bees correctly created resized image files, as you proved by accessing them directly without time=??? parameter. If the image is not accessible when you add any query parameter to the url (like time=111), then the issue is in your server configuration. Check your .htaccess and/or nginx rewrite rules. Check your proxy server settings (cloudflare, or whathave you).

Yeah, this is definitely a bug in the Whatsapp module. The proper way is to fix the module itself. Module should not pass integer as 3rd parameter. This method always accepted 2 parameters only (in ps16, and in all previous tb versions), so passing this 3rd parameter was always a no-op. We will see more issues like this in the future, with newer PHP versions being much more strict.

It's a deprecation warning, just an annoyance. Revws works fine on php8. It will not work on php9 without changes. Fix will be released before that

<span id="our_price_display" class="price" itemprop="price"> This <span> should not have itemprop attribute. See here: https://github.com/thirtybees/niara/blob/eddb7661e611f9f4f494449eec0cea134c0c884d/product.tpl#L326-L327

No,it's not normal. That would be huge coincidence. What tb version are you running on? There were some fixes in bleeding edge regarding webp generation, so maybe updating to 1.4 will help.

you don't need their webp module. tb supports webp natively.

See my previous answer. Moving watermark section to the end of .htaccess is not a solution, as other rules have precedence. You can even delete the watermark section, as it is a no-op when at the end of the file. The watermark section explicitly says that access to source image files is forbidden, unless the referrer header matches your admin directory. When you load Bo > Products page, your browser requests image from your server. This requests contains REFERER http header, and your apache server use it to authorize request. If you have problems with this, it might be by string Referer-Policy -- your server might have instructed browser to never send this REFERER header, and that would couse your problems. For more info, see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

The bug I fixed today in watermark module was not related to your issue. It only fixes specific situation when module did not properly clean up when uninstalled. Regarding your issue -- this is NOT A BUG. When you install watermark module, access to source image files is supposed to be blocked. This is, after all, the reason why anyone would use this module -- to protect their image assets. It doesn't make any sense to have watermarked images on product page, but allow access to source/high resolution version without any watermark image. The watermark section should be at the beginning of the .htaccess file, otherwise other rules have precedence

add <webp>1</webp> into your config.xml file. Should look like this: https://github.com/thirtybees/niara/blob/e8e7e46f18f5ff1b52df67b27382058be8af8537/config.xml#L221 Also, update to latest bleeding edge.

chex uses different payment discovery API that standard checkout page. Standard checkout calls hook 'displayPayment' that returns arbitrary html / js code that should be injected into the page. Chex does not do this, as it would not be able to control the page flow if it was constructed randomly. Instead, it uses hook 'displayPaymentEU', that returns list of payment options together with action to be performed. The result is the same as when you enabled 'Advanced EU Compliance' module checkout page.

I've just tested watermark module .htaccess modification functionality, and it seems to be working. Module correctly remove its section when uninstalled. If this did not happen for you, then maybe permissions or ownership of the .htaccess file has changed sometimes in between the module installation and uninstallation module wasn't uninstalled properly, but simply deleted somebody modified .htaccess file and removed or modified delimiters that watermark module uses to detect borders of the section.

??? I don't follow....