datakick

These are not texts from thirty bees. It is browser native validation support. The html input is marked as 'required', and browser will display these balloons automatically when nothing is entered.

Try to delete your browser cookies, or use incognito mode. Looks like something is remembering your db settings somewhere from previous installation

delete settings.inc.php file from config directory, if it exists. During installation, enter name of your db docker container as database server.

you need to install/enable PDO_MYSQL php extension

check php.ini configuration in your php docker, specifically sys_temp_dir. Make sure your php user has write access to this dir.

Regarding native mollie module - this is approved project. We also need this module. We investigated and decided to backport latest version of ps17 module to ps16 platform. Most of the functionality was written back in the days when ps16 was supported, so backporting those parts will be trivial. Some new functionality (like subscription/recurring payments) were unfortunately written for ps17 only. It will be possible to backport this as well, but with significantly more effort. So subscriptions may not be part of the first native version, we will see. Ultimately, we want to backport this functionality as well, as we have plans to use it for 'tb backers' ourselves. Regarding warehousing module. In short, it is a set of tools to handle after-sale processes. At its heart, there is a warehouse stock management system that is using double-entry accounting principles. Everything is modelled as a stock movements between locations (location is something like account). Locations can be physical or virtual. We have input locations (suppliers), output locations (customer sales, lost, wasted, etc), warehouse/regular locations, transient locations (picking and packing stations, etc). Every location has set of capabilities -- for example, if one can use this location for picking, if the products on location are sellable, etc. We don't track quantities of individual products on every location, we only track stock movements. Every movement belongs to some sort of 'warehouse operation document', for example picking, packing, stock intake, stock reservation, etc. Within this document, sum of quantities must equal to zero. For example, when picking products, we can take 3 items from Shelve1 and 2 items from Shelve2, and put 5 items into PickingBin1. sum(-3, -2, 5) == 0. This ensures that we can track where every product came from, and that nothing is lost. At location level, we do not track quantities. Instead, current quantities of products at location is SUM of stock movements for this location. This all allows us to answer a lot of interesting questions about our inventory: how many products we have for sale (sum of all sellable locations) how many products we actually have (sum of all locations - this can include returns, products in pick'n'pack process) On top of this core, there are implemented few processes - product intake, order fulfilment. In the future product returns, etc. For example, order fulfilment process: available quantity for sale is automatically calculated from warehouse info -- store shows actual quantity available for sale. order is placed by customer, and goes through the standard order validation process. employee mark order as validated, and switch it to 'Ready for warehouse' status module will try to automatically reserve stock on locations available for pickers. This can fail, for example if stock is at location that does not support picking (external warehouse, high location, etc) In that case, employee will create internal 'Stock movement order' to transfer stock to location available for picking. Once all stock is ready at picking locations, it will be reserved. When all products are reserved, system can (automatically or manually) print 'picking order'. Pickers will take this employee, and will use our picking app inside barcode reader or phone they will scan order it will tell them location where to go, and what to take from there they will scan barcode at location, and barcode of product, enter quantity one everything is picked, they will move the picked items to packing station packer will take the list, and will use our other application to ensure everything is packed. It will print the shipping labels etc. packages are handled over to carriers Internally, there will be multiple documents. Reservation document will mark product at location as reserved. Picking document will move product from location to temporary picking bin. Packing document(s) will move products from picking bin to package location. Carrier document will move products inside packages to customer location. It's all very complex and complicated, but also quite powerful. It's designed for bigger shops that have multiple employees and that want to streamline their warehouse processes. Pickers/Packers will not have to think, really, they will just do what they are told by the system. in office, you will have overview of what is where, what needs to be ordered/moved/etc Hope this makes it more clear. I know it probably raised more questions than it answered,... it's really hard to explain.

I apologise for the late reply, I was on a vacation last two weeks and I'm slowly burning through my unread mails and threads now 🙂 Regarding the @wakabayashi image rewrite -- this is scheduled to go to bleeding edge after the release of 1.5 (which will be very soon). We talked about pros and cons and risks about putting this into 1.5, and decided it's too risky to do so. While this is very nice functionality, it also brings some backwards compatibility problems and issues. The main (but not only) issue is that friendly urls of product images changed. We need a backwards compatibility solution for this issue, one that would work on both nginx and apache. We have to be sure that if store update to new version their images will still be displayed. That's not the case with current code, if deployed on nginx server. I've tested it on my demo server and it broke very fast. I understand that it can be very disheartening that it takes so long for us to merge this. I know @wakabayashi put a lot of effort into that. But we can't just merge is as it is and hope for best. It probably works nicely for his store, but we need to be sure it will work for everyone else as well. We need to be sure there are no visible bugs. We have to do core review to check for security and other issues. And this all takes a lot time -- if you look at this change, you will find that it touches 72 files, a lot of addition and deletion. I've already spend around two days of my time on code reviews, on fixing various small issues. There are still some issues that we need to work on before we merge it. But it will be merged. Just not into 1.5

Even on PHP7.4 your server is screaming these warnings at you. You (and most others) just decided to ignore it. You should look into your server error logs (or install collectlogs module if you can) and fix every warning / deprecation that you find in there. This one would definitely be listed there - on PHP7.4 as a warning still. PHP8 increased this problem to error level. Only AFTER all warnings are fixed is it safe to update your php version. This particular bug in module code is very easy to fix. Simply change the order of parameters of implode function from $products = implode($products_arr['href'], ','); to $products = implode(',', $products_arr['href']);

You can enable / disable modules per customer groups. You can have this disabled for visitors / guests, and enabled for customer or any other group you have.

I also haven't encountered any issues on my production server so far. Granted, I don't use that many modules, but its encouraging anyway. This is a tricky one. Do not turn off Stringify fetches on production server. Back in the days, MySql returned numbers (and other native types) as string. PHP would receive text value '100.45' instead of float value 100.45, even though in database it was stored as decimal number. PrestaShop / thirtybees didn't convert the data to expected data types, and work with the strings. PHP is funny enough to support operations with mixed data types without complains, for example $result = '100.45' * 10.65; Of course, this is little bit slower than doing operations with floats directly. And there are some gotchas and corner cases that make developers go mad. Newer db servers can return data in correct types, so we would receive floats or ints from mysql server directly. For developers this would be a big relief, because we wouldn't have to remember that the data we work with might be float of string or null. A lot of code could be simplified. Unfortunately, this can cause a backwards compatibility issues. And what is worse, it can just change the behaviour of system without any exceptions being thrown. Imagine there is a code if ($address->id_country === Configuration::get('PS_COUNTRY_DEFAULT')) { // do something } method Configuration::get() returns string, and there is a strict comparison used === instead of normal comparison ==, so types of operands will be checked as well. With stringify fetches, this condition returns true, because $id_country property contains string, so the condition is actually if ('1' === '1') { } Without stringify fetches, the condition would be if (1 === '1') { } and that evaluates to false. The result is difference in evaluation of logic. We are trying to weed out these kind of things from core, but it's hard and slow process. We will probably never get to the point where this option could be disabled safely. It's probably a good idea to hide this switch for normal users, or move it to some sort of 'Experimental' tab. I will do that.

No, subqueries are integral part of parent query. I'm talking about multiple independent sql statements executed in one call. With this option enabled, you could do $conn->execute('delete from a; delete from b; delete from c'); and it would be the same as $conn->execute('delete from a'); $conn->execute('delete from b'); $conn->execute('delete from c'); Theoretically, the first would be a little bit faster, because you save two calls to db server. It's nice, but very dangerous.

Hard to tell. There were few places even in core that used multiple sql queries. Thise were fixed. But if that's all, nobody knows. Static code analysis is mostly useless here.

If you update to bleeding edge / 1.5.0, you will find new option Allow multi statements queries in Advanced Parameters > Performance. For backwards compatibility reasons, this option is enabled. That means that multiple sql queries can be executed at once. This is very dangerous, because it can be exploited by attackers if they find SQL injection vulnerability. For example, if some module contains code with SQL injection like this one: $conn->executeS('SELECT * from '._DB_PREFIX_.'orders WHERE id_order = ' . Tools::getValue('id_order')); Then attacker can post request to your server with parameter id_order=0%3B%20UPDATE%20tb_employee%20SET%20passwd%20%3D%20%27pwd%27 which is url-encoded equivalent for 0; UPDATE tb_employee SET passwd = 'pwd' PHP code would then execute following SQL query: SELECT * FROM tb_orders WHERE id_order = 0; UPDATE tb_employee SET passwd = 'pwd' Attacker just changed password for all administrators, and can log in to your back office. When you disable multiple statements, that SQL query would throw an exception. So it's very good idea to block this. Of course, there can be some modules (or even core code) that depends on this multi-statement functionality. I recommend installing collectlogs module before your disable this, and watch for any new errors. Note that this is not some silver bullet that solves SQL injection attacks. Even with this option enabled, attacker can use the SQL injection to extract information from your store by constructing smart queries. But it significantly reduces the options they have

no, ps17 or ps8 modules can't run on thirty bees.

Thirty bees 1.4 is still compatible with all versions of PHP7. Upcoming release 1.5 will be compatible with PHP7.4 and higher only -- so if you run on PHP7.3 or lower, you will indeed have to update. Nowadays it's very hard to find hosting provider that still support even PHP7.4, let alone older versions. New accounts usually have to use PHP8. Old accounts are often temporarily granted exception to use PHP7, but it's implied that they should update. PHP7 is no longer developed, and not even security issues are fixed. This is the primary reasons why we want thirty bees to be PHP8 compatible. However, compatibility with PHP8 also means that we had to drop compatibility with some older PHP versions. We were forced to do so, actually. Some third party libraries (smarty template engine, or pdf rendering library) were not PHP8 compatible. When they released PHP8 compatible version it was not compatible with PHP7.0 So we faced the decision, whether we want to have PHP8 compatibility, or maintain PHP7.0 compatibility. We chose the PHP 8

This version of module could have never work with thirty bees or with prestashop 1.6. It uses prestashop 1.7 specific hooks, and calls methods that exists in ps17 only. You must have used different version of the module.

Create read-only user in your Matomo, and then use this account to generate auth token

Hi everyone, I just wanted to let you all know that javascript/CSS minification functionality was removed from core. It was replaced with new module tbminifier - this module contains almost identical implementation of original code form core. If you update to bleeding edge, and if you are using CCC functionality, please install this module as well. Otherwise, combined css/js assets would not be minified (but they would still be combined into one big bundle) The reason behind this change is to reduce dependency of core code on third party composer libraries. These dependencies causes a lot of troubles recently. If you install some module that depends the same library (but different version), core version of library will be used because it was loaded first. We know about at least one problematic module -- mollie -- but there will be others as well. Another reasons for this change is to have more flexibility -- you can implement different minification algorithms using different libraries. Who knows, maybe somebody will come up with something new and better.

You have changed thirty bees core php file. This modification will be lost when you update your store to new version in the future. Core updater will warn you that there are some local changes, and that they will be overwritten during update: classes/pdf/HTMLTemplateInvoice.php modified In the future you will not remember what changes you made. The solution for this problem is to use overrides. It's technical process, but not that hard 1) create file (if it not exists yet) in /override/ directory with the same path as the file you want to override, in this case /override/classes/pdf/HTMLTemplateInvoice.php If the file already exists, go to step #3. Initial content of the file should look like this: <?php class HTMLTemplateInvoice extends HTMLTemplateInvoiceCore { } 2) delete file /cache/class_index.php -- this will force thirty bees to reindex overrides, and it will start using the newly created one 3) copy entire function from original class to override. Override should now look something like this: class HTMLTemplateInvoice extends HTMLTemplateInvoiceCore { protected function computeLayout($params) { $layout = [ 'reference' => ['width' => 15], 'product' => ['width' => 40], 'quantity' => ['width' => 8], 'tax_code' => ['width' => 12], 'unit_price_tax_excl' => ['width' => 0], 'total_tax_excl' => ['width' => 0], ]; if (isset($params['has_discount']) && $params['has_discount']) { $layout['before_discount'] = ['width' => 0]; $layout['product']['width'] -= 7; $layout['reference']['width'] -= 3; } $totalWidth = 0; $freeColumnsCount = 0; foreach ($layout as $data) { if ($data['width'] === 0) { ++$freeColumnsCount; } $totalWidth += $data['width']; } $delta = 100 - $totalWidth; foreach ($layout as $row => $data) { if ($data['width'] === 0) { $layout[$row]['width'] = $delta / $freeColumnsCount; } } $layout['_colCount'] = count($layout); return $layout; } } 4) now you can modify your override to match your needs. And that's it. It's a little bit more work, but makes your life easier in a long run.

This is an issue in integration between jsonmodule a and productcomments In jsonmodule, you can choose to emit reviews information retrieved from productcomments module. To do that, jsonmodule uses productcomments internal classes. These classes are not available when productscomments is disabled (module autoloader is not initialized). https://github.com/thirtybees/jsonmodule/issues/8

Also, remember not to modify core files, you would loose your modification during update. Instead, create override for this computeLayout method.

As @the.rampage.rado suggested, you can disable moving javascript to the end. I would recommend to do this anyway, as moving javascript to the end can cause a lot weird issues. You can also add data-keepinline attribute to script tags to instruct core to not try to move it <script data-keepinline> window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'G-***'); </script>

Because you used 'email' as a custom submit, every time any form that contains 'email' field is submitted the captcha validation is performed. Chex sends request with 'email' field during checkout. And there will be many other forms that will do the same. This is definitely not the right submit name to use. Unfortunately there is no other field send when submitting 'forgot your password' form: You can modify your theme password.tpl template and add 'name' attribute to button, for example name="submit_recover_password" That way, this submit will be send to server: and you can use it to attach your captcha validation

I don't think this is issue in core, or at application level (of course I could be wrong) Most likely you have some security apache/nginx module (mod_security maybe) that evaluated request as threat, and blocked it. You should check your server logs, to make sure that request made it to PHP level, and was not blocked by apache/nginx before

Your store works for me as well. Adding products into cart works properly. I also tried to login as a customer, without any issues.