datakick

tb is not using md5 for oassword hashing. It is using password_hash function instead, that's quite secure solution. If you have migrated from ps16 some of the accounts might still be using md5, but after first login their password will be automatically rehashed using password_hash function.

No, full page refresh would result in resetting javascript objects -- your selected carrier / payment options, filled in text fields (name, email,....) would be lost.

It's not possible with the current version. In next version you will be able to specify autocomplete type for each entry field input

It can be a problem if you are using language with non ascii characters, such as ěščřžýáí. Search, ordering and comparison would not work as expected.

CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ALTER TABLE <table> CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Turn on debug mode and see if any error message is displayed. Look into /logs directory in your thirtybees instalation, and also into your php server error logs. There should be some additional information there

Your video does not show Actions part of the cart rule. That's where you can set up that the cart rule should apply to specific product only

They are (the dangerous ones). Thirty bees server does not allows you to update to bleeding edge, it simply does not offer this target for selection.

The new version of core updater is not yet released, it's currently under testing. There were a lot of changes, both in server api and module, so I want to be sure this works correctly before we release it officially. Wouldn't want to destroy your stores during update 🙂 Good idea, will look into it. Although I don't think many merchants would notice this -- does anyone actually read the news stream on dashboard?

How many spams do you get? I personally have one spammer as well, but I'm almost sure it's not automated script. From access logs it looks like somebody do this manually. And there's not much I can do about that. I have set up Conseqs module rule to block sending contact_form email to customers, so this spam attempts do not bother me much, as I'm the only one who actually receive the spam emails.

You need to look into server's error logs to figure out what the error is about.

This issue is fixed in bleeding edge: https://github.com/thirtybees/thirtybees/issues/1242

These are only notices, not errors. You don't have to worry about them much. What happens here is that module is registering hook (telling thirty bees core to call back when something happens) but it does not implement code handler. Without the handler core have no way to actually call back the module. It's like asking somebody to call you but forgetting to provide your phone number. Thirtybees simply detects this situation, and emits notice into system log with hope that somebody will contact module author and ask them to fix this issue. Usually the fix is pretty simply, just delete hook registration from module.

It should work without major problems. I'm personally using 8.0.23 for development, and so far encountered only single issue regarding complex queries of information schema -- this affects core updater, but is already fixed in new version.

Don't worry about this, it's harmless. This happens when your customer visits your site after they placed order. The cookie still reference the old cart that has been converted to order already. Thirtybees / ps16 detects this, and create a new cart. And in ps16 this 'notice' is generated. Not in thirtybees, though.

I tested the functionality on my local environment and it works fine. Please ensure you have latest version of niara theme, and that you don't have any core modifications and/or overrides

There is not much that can be done. This would require massive rewrite of the js app, there's not a simple solution

This is just a short FYI: We are currently integrating various features to main branch (aka bleeding edge) in preparation for release of thirty bees version 1.3.0. Some of these features require special initialisation, for example creating entries in database tables, new menu items, etc. Unfortunately, current version of Core updater do not support this functionality - only code is updated, and potentially database schema is fixed. But no data fixtures can be inserted into the database as part of update. This is serious limitation that prevents us to roll out of new features. Therefore, we have decided to extend Core Updater and implement this functionality. New version will be released soon. This new version allows us to introduce new core code together with all data fixtures it needs, nicely wrapped together. New functionality in 1.3.0/bleeding edge already depends on this new core updater functionality. Unfortunately, this also means that in order to update to upcoming version 1.3.0 (or current bleeding edge), you will have to first update your Core Updater module. Current version of core updater CAN NOT be used to update to this new version, because the system database would end up in inconsistent state. You can still use current version to update to 1.2.0, but not to main (bleeding edge). This is wanted behaviour. Once new version of core updater is released (hopefully this week) and you update to it, you will once again be able to update to bleeding edge and/or 1.3.0.

Nobody can answer that based on your description. Something must have changed - new module, updated php version, implemented caching system, antivirus, hacked server, etc. Computer programs rarely stop working without external input. Did you look into server logs? What does browser console says?

I see. Unfortunately no, it's not possible from within the module itself. You can delete it directly in db, using query like this: delete from tb_revws_review_image where id_review = 12345; Just replace id_review with correct value

It's not possible. The email address is required to distinguish between returning and new customers. Flow for different kind of customers are very different. For example, with returning customers you can choose between existing addresses, you don't have to enter account related information again, etc.

Hi everyone, Sorry for the trouble. This seems to be related to server plesk software update -- the configuration of extra PHP environment property was lost during the update, and the api server stopped working. The server is up and running again.

Hi Andy, I don't understand the question. Could you please explain a bit more?

Thirtybees requires InnoDB database engine. Your mysql server does not support this. You need to contact your hosting provider and ask them to enable it

that's indeed a very good idea, as it offers much better protection than the IP address check. It also ensures that the employee context is properly initialized -- that's important for logging, error handling, etc. And since you extract the logic to the admin controller, you can also wrap it all into a small useful module and offer it to the community 🙂