datakick

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.

https://github.com/thirtybees/niara/blob/af439f01033dd0cd41622a2470813c29dc09453c/breadcrumb.tpl#L12 This is comment text in smarty template breadcrumb.tpl. You have probably modified this file and "uncommented" this, making it part of output

Thanks. This screenshot provides much more information that your first one. We now know the actual error message: Class 'Attribute' not found, and we know that it comes from override. The override is referencing Attribute class that does not exists anymore in thirty bees core, because it's reserved name in PHP8. You have probably installed some some module recently that added this override, or you have updated your store. Anyway, the fix is to edit the override file, and change Attribute::checkAttributeQty to ProductAttribute::checkAttributeQty There might be more usages of Attribute class, you have to replace them all.

The very first image, with error on line 121, is from override, isn't it?

Why not? The only "valid" reason I can see is PHP version. But that's not valid reason anyway, really. Just from security point of view, I would advise everyone to update to latest bleeding edge. https://github.com/thirtybees/thirtybees/blob/d9c85fa9ec25a186494daba2f3eec983ae75c553/classes/ConfigurationTest.php#L326-L348

sudo find . -type d -exec chmod 755 {} \; sudo find . -type f -exec chmod 644 {} \; This changes permissions of all directories and files to be readable and writeable by owner, and read-only to others. It will work properly as long as all files are owned by your php server user, as it needs write permissions.

Looks like a bug. Please create github issue with reprosteps

Do you have some email transport module installed? EDIT - you can use one of these two mail modules Mail via swiftmailer Mail via PHPmailer