datakick

This is not usually what happens. Spammers use email addresses of real people, not their own. They are abusing your server to act as a sender of spam mails. Of course, they occasionally use their own email address to check that the emails are sent, but in most cases they use real email addresses. The most efficient way to mitigate this is to block outgoing contact_form emails. Spammers will have no reason to abuse your website, if it does not send emails to end users

This is already fixed bug. You can either update to bleeding edge, or apply this fix: https://github.com/thirtybees/thirtybees/commit/a7cd6399183897306cbbd77cac13a4f525344bb8

That's strange. There are few possible reasons for this, none of them very likely the file is not readable -- check file permissions the smarty context is misconfigured -- maybe some module changed include path to different location... very unlikely I don't think update to 1.2 would solve this,... but of course it may 🙂I wouldn't worry about modules compatibility, they should work as fine on 1.2 as on 1.1

I'm afraid this is almost impossible to fix. Core does not know what payment options exists, they are not enumerated anywhere. It only knows about modules that implement 'payment' hook, but what payment options each module provides is big unknown. When the payment is processed, payment module gets a chance to create/validate an order, and during this step provides information about the payment to be stored inside order. Because this info is not available to the core itself, we can't really use it during back office order creation, not without invoking payment process itself.

Ensure that file <admin>/themes/default/template/controllers/logs/employee_field.tpl exists -- replace <admin> with your admin directory. If it does not exists, you should use core updater to sync your codebase

Hi @Dolfijn, I can't reproduce this issue on latest niara/community theme. The price calculation works correctly for all calculations and volume discounts. This looks like a bug specific to your old ps16 theme. I'm glad you already have a solution, maybe it will help others that comes with old ps16 default theme.

@Dolfijn what theme do you use? Both product.js and product.tpl are part of the theme. If there is a bug, we can fix it inside community-default-theme and niara, but it will still be part of third party themes.

As always -- when there is 500 error code, you have to look into your server's error log to see what is the root cause. The error message will be either inside your apache/nginx error log (not access log), or in /logs/ directory in your thirtybees installation. Check both locations

https://www.php.net/manual/en/function.password-hash.php Currently, it uses bcrypt by default. In the future php versions this might change, of course.

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