datakick

All information required for invoicing is collected, including address If you cart contains only virtual products, shipping is not displayed No, such option does not exists. It behave in the same way as default checkout -- allow free orders. I don't understand

Thanks for reporting this. Fixed in new version 0.9.3

In PHP8 Attribute is a reserved name. Every PHP codebase that used the same name must stop using it if they want to be compatible with PHP8. Thirtybees definitely want to run on PHP8, so we renamed this class to ProductAttribute. You will have to adjust your module and replace usage of Attribute class with this one. For example, if your module contains $attr = new Attribute(); $attributes = Attribute::getAttributes(); You have to change it to look like this $attr = new ProductAttribute(); $attributes = ProductAttribute::getAttributes(); There is also more easier solution - add this line at the beginning of every PHP file in the module (that is using this class). And you can keep the rest of the code intact use ProductAttribute as Attribute;

Yes, as long as it's a full backup. You shouldn't do merge into current root directory, but delete everything (or rename your root directory) and replace with your backup.

Oh, that's scary. Stage 1) remove the infection. use core updater and/or Configuration information to figure out if core files were modified. Use core updater to fix that look for any modules that you didn't installed check your overrides. You can use overridecheck module to list all existing overrides. check the theme for any modification. Take note of all modified or new files. Write down file creation/modification dates. Stage 2) strengthen your store update core to latest bleeding edge 1.5, if possible. There were a lot of security fixes rename your admin directory change all sensitive information in /config/settings.inc.php, including _DB_PASSWD_ - you will need to change password for your database user first _COOKIE_KEY_, _COOKIE_IV_ _PHP_ENCRYPTION_KEY_ _RIJNDAEL_KEY_, _RIJNDAEL_IV_ Delete all modules that you don't use. Even if they are not installed, they can pose security risk. Delete them. Stage 3) figure out attack vector updating your store to latest version and deleting unused modules may or may not fixed the vulnerability. If not, attacker can use it once again to get access to your store. You need to figure out how they got access look into your server Access logs It will help if you know the approximate time of attack (from file modification time) search for group of weird requests. Something like this nginx_1 | [29/Apr/2023:03:43:02 +0000] "GET /.git/HEAD HTTP/1.1" 403 153 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /nmaplowercheck1682739782 HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /localstart.jhtml HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /CSS/Miniweb.css HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /5Mrh HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /Portal0000.htm HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET / HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET / HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "\x0E\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00bbbb0100000001" 400 157 "-" "-" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "POST /sdk HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /Portal/Portal.mwsl HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /robots.txt HTTP/1.1" 200 36 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /__Additional HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /HNAP1 HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "GET /?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000 HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" nginx_1 | [29/Apr/2023:03:43:03 +0000] "POST /scripts/WPnBr.dll HTTP/1.1" 302 5 "-" "curl/7.54.0" "-" within this group, search for requests that succeeded - response code 200. POST and PUT requests should be the first to investigate. check the php scripts for requests that succeeded check requests with response code 500. it can be indication of some vulnerability If you are unsure how to do all that, you can and should hire somebody to help you with all that.

While the idea behind this module is nice, I think it has a potential to cause a lot of trouble. And doesn't solve any actual problem, really. When you use this module, you should edit your templates and strip all microdata from them. Otherwise, search engines would see two sets of metadata. For product and organization info metadata this is ok, as json+ld format already contains this info. Problem occurs if you have some module that emits additional metadata (like reviews from revws module, author metadata, FAQ, related content, etc). Because of missing product metadata we just removed, these additional information will not be attributed to anything. And google search console will raise a lot of errors. In this case, the proper solution would be to integrate these third party modules with jsonmodule. Jsonmodule would expose some API that other modules could use to render json-ld metadata. This api does not exists. And even if it did, nobody will modify these third party modules to work with jsonmodule. So, if you don't use any module that emits metadata, you can use the jsonmodule. The end result will be, however, the same as if you just keep the html based markup

You should check files permissions. Maybe some of your files are not readable/writeable and were not updated delete file cache/class_index.php clear cache disable all overrides

Note: previous suggestion no longer works for bleeding edge / thirty bees 1.5. Employee record in database now contains 'signature' column that ensures employee password/email/role is not modified externally. This is to prevent attackers from accessing your back office in case of SQL injection vulnerability. If you are locked-out, you can use auto login script from this thread:

Here's a helper php script force-login.php Upload it to your admin directory, and then open it in your browser, ie https://your.domain.com/admin-dir/force-login.php This should log you in without need for password. Then go to core updater. In settings, enable Developer mode. Then click on Developer icon in upper right corner. In the developer tool, execute "Execute processes" That should complete the failed migration, and you should be able to log-in again. Don't forget to remove the force-login.php script again force-login.php PS: if you tried the suggestion from https://forum.thirtybees.com/topic/6081-locked-out/#comment-46072 thread, then don't forget that your password is already changed to changeme1234

sorry, that's classes/ConfigurationTest.php

This is an issue with TLS12 check. It stopped working due to external changes. In version 1.5 / bleeding edge, this test does not exists anymore. Edit file and delete line 130. Original code public static function getDefaultTestsOp() { return [ 'Gz' => false, 'Tlsv12' => false, ]; } should look like this public static function getDefaultTestsOp() { return [ 'Gz' => false, ]; }

Indeed, that's a bug. Javascript method that translates string is in this case called before the translations are provided. I have to delay this, and translate string only when error happens.

My guess is that your server raises some warning/error very early because of server misconfiguration -- maybe relate to that tempname() notice that should not be there. Thirty bees tries to handle the error, and during that error handler tries to access database. This fails, because db connection is not configured yet. The original error is not reported, and instead new error regarding database connection is raised. If true, it is obviously bug in thirty bees. Unfortunately, I can't reproduce this issue, so I'm not sure what to fix. @Alexander001 could you assist? Please edit file classes/db/DbPDO.php Find line die(sprintf(Tools::displayError('Link to database cannot be established: %s'), utf8_encode($e->getMessage()))); And replace it with die("<pre>$e</pre>"); That should tell us the origin of the problem. That's not real server, that's a joke. Their free plan severely limit number of concurrent connections to the server. Modern browsers can easily trigger a lot of concurrent requests, and their server just can't (won't) handle it.

No, that's correct. There shouldn't be this file. I asked because if this file existed, it might explain your issue.

Hard to tell. Do you have existing file /config/settings.inc.php ?

Hi everyone, I've just released a new module to strengthen back office security - two factor authentication module. https://store.getdatakick.com/en/modules/back-office-two-factor-authentication With this module, your store employees will have to enter authentication code during login to back office. The code changes every 30 seconds, and the only way to obtain current value is to use Authentication app on your phone -- there are many free authentication application available, for example Google Authenticator or FreeOTP. This functionality makes your back office more secure. It protect your store against brute-force attacks, mitigate impact of weak or leaded passwords, etc.

You have entered invalid server name for your "database server address"

This issue is usually caused by product miniatures listing. Product miniatures are displayed on category pages, but they can be elsewhere as well. For example, related products or crossseling on product pages. Some theme adds rich snippets metadata to these miniatures with itemType="Product", so google consider these as a full-fledged product description section. Which they are not -- they don't contain all the data google needs, hence the warning. In my opinion, the best fix is to modify your theme, and remove these rich snippets from product listing template. Relevant file is product-list-item.tpl. Remove all itemprop="***" itemtype="***" itemscope

You have to modify the module code. Replace all references to Attribute class with ProductAttribute.

Enable debug mode and (or) install collectlogs module. That will tell you what's wrong. Probably some module that is using Attribute class. That was renamed in 1.4 for php8 compatibility reasons

It's not possible - current database table schema doesn't permit this. It's not possible to have two rows in table tb_image with the same id_image, hence it's not possible to associate the same image with different products.

I bet it's about link. Spammers these days don't post link immediately, they simulate "engaged discussion" with hope their post will not be deleted. If not, they will return after few days or weeks and edit the message ti contain link. You can spot these quite easily, as they don't know what they are talking about. It's usually "thank you this helped me very much" kind of reply. AI helps them a lot, unfortunately . They just ask the original question, and copy-paste whatever AI generates. It's smarter than anything they could come up with themselves. It will make moderator work harder. We are thinking about disabling edit functionality for post older then few hours.

These are not errors, but warnings. And all of those are already fixed in bleeding edge. I saw in other thread that you downgraded to 1.3. That's not the right solution. Using PHP7.4 on 1.3 will not fix these warnings, it just masked them. You should update to bleeding edge, install collectlogs module, and keep track of all these warnings. Report those that originates in the core as github issues and we will fix them -- you can then install newer bleeding edge to check that the issue was fixed. Warnings that originates from third party modules should be fixed as well, otherwise you will not be able to safely update to new PHP versions in the future. Once all warnings has been fixed, it's safe to switch to higher PHP version. Bleeding edge thirty bees core + most native modules runs without any warnings even on PHP8.2. I have this php version on my production server and I didn't see any notice in the error log for a few weeks now.

If you are on 1.3, then you had to downgrade your PHP to 7.4. I think it's the PHP downgrade that fixed this problem, not tb version -- see this comment: I recommend you upgrade to bleeding edge (1.5) using core updater and install new mail transport module. That should fix this issue, and will allow you to use PHP8.1

Yes, it was deprecated in 1.6 or in 1.5, I'm not sure. The functionality was kept in the core, but enabled only for uses that had some scenes active, with the intention to remove it completely. I agree with this, actually -- there is no reason why this should be part of the core. If it's useful for somebody, we could extract the functionality to some module. But it should be removed from core.