datakick

There were a lot of security fixes in 1.5 that closed a lot of holes in the system. A lot of those are relevant for both ps16 and thirty bees, some are thirty bees specific. Some were in modules, some were in back office only, and some were in front office. Commits in github are kind of a disclosure. Anybody can look and see what was fixed. And anybody can use this information to attack sites running older versions. I don't know about your experience, but my store is hammered daily by hacking scripts looking for vulnerabilities. Some of those scripts are blind, some of them are not.

This is funny. How does this "Premium stuff" affect you? Is your OCD acting up because there is a new button in bottom right corner, in a place that was unused before? Well, add 3 line of CSS to your admin override css file to hide it. Are you mad that there is a new "Premium modules" section in modules overview? Is it so hard to ignore it? Do the other uninstalled, but free, modules in the list trigger you in the same way? If this bother you, kindly create PR request that adds setting option to hide these extra modules. I promise you we will merge it. I just won't waste my time implementing something like that because I don't need it, and I have a lot more pressing issues on hand. On both 1.4 and 1.5 you have access to the same list of free native modules. Updating to 1.5 will not hinder your options at all. Yet it will give you a lot of bugfixes, performance improvements, security fixes, and couple of new features for free. And if you opt to become supporter, you will get access to a lot of interesting modules as well. This is strictly optional, nobody is forcing you to do anything. If you stay on 1.4 you should be fine for now. Just don't update your PHP versions. And be prepared that over the time you will loose access to free modules updates, as the new versions will be using functionality from the core not available in 1.4. And I strongly suggest you at least cherry pick all the security related commits from the 1.5 version. Or you store will be hacked.

It really depends on what kind of bot that is. It can indeed be some regular bot - if that's the case, then update to 1.5 may help a little. This version contains up-to-date database of know bots (https://github.com/JayBizzle/Crawler-Detect) and ignores request from them. More likely though, this is some sort of hacking attempt.

They are basically the same themes, the difference being mostly in CSS (and some small html tweaks). The same commits can be applied (usually) to both themes, so there is not much overhead in maintaining both of them.

Both are supported. All fixes are pushed to both themes

What mysql server version are you using? It will probably be quite outdated

PM me access to your back office, I can investigate

No, you can connect multiple installations to your account, and you can use premium modules on all of them.

If you want to import product supplier information, and if you are on tb1.5, you can use my free module https://store.getdatakick.com/en/free-stuff/import-product-supplier This module does not perform the import itself. It simply registers new CSV import entity Product Supplier. Standard thirty bees CSV Import will see this entity type and can work with it. New version of the module also supports two new fields Supplier Product Name and Additional comments.

This functionality is now in bleeding edge. You can now set custom email subjects for your order statuses

You need to look into error logs (collectlogs module) to find out if there is any error. It may be caused by override, module, or whatnot. I personally can't reproduce this issue, and I do sell virtual products.

This is new bug in 1.5 (the customizable one) -- tracked here https://github.com/thirtybees/thirtybees/issues/1730 Thanks for reporting it. I've fixed it already, and will push the fix to bleeding edbe and 1.5.x branch

This is very common problem with a lot of older modules. When you see this error (on PHP8) or warning (on PHP7), then replace key_exists($key, $this) array_key_exists($key, $this) with property_exists($this, $key) The first two functions can be used with array only. If object is passed instead, older versions of PHP converted this object to array automatically (silently, or with warning). PHP8 do not do this automatic conversion, and fails instead.

I looked into logs, and it looks like your site isn't reachable from our accounts server. Your site renders some sort of captcha/challenge, which blocks integration.

Last week we have released new premium module Remove account. This module adds your customers an option to request account deletion, directly from their customer account in front office. Account is not immediately deleted, but rather scheduled for deletion. Your customers can change their mind during the waiting period. Merchants have the option to approve or reject the deletion request. Or you can set it up to automatically approve account deletions. Technical notes: Customer account is not really deleted. Rather, all customer data are merged with one (hidden) customer account. This removes all personal information from customer record (compliance with GDPR), yet it keeps data for accounting and statistics purposes. Invoices are kept intact, as required by (most EU) laws. PII data on invoices are not subject to GDPR law, so it's OK to keep customer name, email, or address there even after account deletion. Let us know what other functionality would you like in this module.

yes, tbhtmlblock module is not multistore-ready https://github.com/thirtybees/tbhtmlblock/issues/3

core updater should take care of it for you

I've just pushed fix for this problem into bleeding edge: https://github.com/thirtybees/thirtybees/commit/554e9967340a34bee0bdf51a4cf957f8f97a865b I'm also thinking about adding the key to the database. It will make the table bigger, but should help performance significantly.

We can safely drop this, as browser support for webp is very good now: https://caniuse.com/?search=webp

Yes, since thirty bees 1.4 (I think) we track pack items sales as well. This info is taken into account. So, if you sell product A separately 1 times, and as part of pack 9 times, purchases module will see 10 sales of this product. Sure, let's add this to backlog. For MOQ -- we already have something similar to this, but little bit more generic -- custom notes for products. So you will be able to notes for product A and Supplier S, for example "Always order whole box" This is settings for Export section. It's a remnant from first version of the module, we will probably remove the export functionality completely. Export was used before we had purchase orders to gather data for it. Yes, shop default currency Module already do this. If it doesn't work for you, please check javascript console -- maybe there is some error that blocks this js functionality. Safety stock represents minimum quantity you should have on stock to be able to achieve expected service rate. It takes into account only demand and service rate settings. Reorder point represents quantity on stock when you should reorder the product. This will never be less than safety stock, but it can be higher. It takes into account order placement costs, and stock ownership costs. This is what we use to suggest products to order.

I've added this to the backlog. Thanks for the suggestion

I have no issues with importing product with features. Can you provide sample csv import file?

Yes, paid version is an extension of free one. Do NOT uninstall the free version. Just upload the premium version over it. Thanks for the report

Exactly Yes, that would do that. If you manually update the module and remove the function handler, the system will still try to call it I agree. I don't like the original Logger much, but at 1.2 there wasn't an alternative. We can modify this place in Hook to simply trigger PHP warning and let collect logs do its job. Or even better, we can simply unregister the hook, since we already know that the handler doesn't exists.

Thank you so much, that's interesting. Unfortunately it also makes it much more complicated to implement, as usual 🙂