Yabber

Fixing the Niara template: https://github.com/thirtybees/niara/pull/100

@the.rampage.rado I never use Advanced Stock Management in the shop; I believe it’s a feature that causes nothing but problems and offers no benefits whatsoever. So I haven’t tested "split orders" with ASM. Yes, different carriers must be configured for the products for "split orders" to take place. Yes, with the module I’ve attached, you can change the carriers for individual sub-orders in "split orders" mode. And, as a point of interest, a Prestashop fork called PhenixSuite has fixed this.

As far as "split orders" are concerned, functionally almost everything works correctly. In the back office, orders are created with different IDs but the same reference number. At the bottom of each such order, there is a note stating that it is a combined order. Each of these sub-orders can be handled by a different carrier module. However, on the front office, all templates for all versions of PrestaShop and ThirtyBees are broken, and nothing is displayed for carriers in "split-order" mode. The option is available to choose from, but the customer doesn’t know what they’re choosing. And once this option has been selected, a valid split order is created. The delivery cost, however, is correct; it is the sum of the costs for all carriers.

@DRMasterChief So it’s actually about multi-shipping, rather than simply changing the carrier on an order. The solution you’ve described, using the module you’ve developed, has one major drawback – it won’t work properly with any carrier module or with any external integrations such as Base.com or eMagicOne. Install any DHL, DHL Pickup, DPD, FedEx or UPS module – none of them will work properly. That is why the standard solution available in thirtybees, known as "split-order", is a better option. If a single customer order involves several carriers, that order is split into several separate sub-orders, and in each of these sub-orders, all carrier modules and all shop integrations with external order-handling systems work correctly.

This action is lawful, as the amendment to the terms of the contract – the order – is made by mutual agreement between both parties to the contract. This email constitutes an addendum to that contract.

Multi-shipping and changing the carrier for an order are two different features. In many countries, changing the carrier for an order in this way is against the law. It constitutes an unauthorised alteration by the shop to the contract entered into with the customer. However, many shops do this, and the module for changing the carrier for an order is included in the attachment. tbchangecarrier.zip

This Mollie module for PrestaShop is terribly put together; it contains 99% unnecessary code. It would be better to use Claude to adapt this module: https://github.com/mollie/thirtybees to the latest version of Thirtybees with PHP 8.3 and the latest version of the Mollie API.

In Claude, you enter the prompt: ‘Adapt the attached module for Thirtybees 1.7.0 and PHP 8.3’. You paste in the ZIP file containing the module, and within 5 minutes the module is fixed.

A perfectly crafted template is one that requires no configuration whatsoever, as the layout is controlled entirely by CSS. There are templates sold for PrestaShop that store millions of variables in the configuration. And then people complain that the shop’s pages take half an hour to load.

The problem is that all templates and modules for PrestaShop 1.6 are not compatible with PHP 8. Templates for PrestaShop 1.7, 8, and 9 are not compatible with Thirtybees. Thirtybees is not very popular, so no one is creating templates for it: https://themeforest.net/search/thirtybees There are no templates for Thirtybees, so it’s not very popular. And so the vicious cycle continues.

It is likely that, following the upgrade, neither the ‘Mail via PHPMailer’ nor the ‘Mail via SwiftMailer’ email transport module has been configured. Since version 1.6.0, email is no longer supported via the PHP mail() function.

I found the cause of the product page crashing when there are a large number of attribute combinations and the “blocklayered” module is installed. In the Product class, within the two methods getAttributesInformationsByProduct() and getAttributesParams(), SQL queries have been added with the following condition: if (Module::isInstalled(‘blocklayered’) && Module::isEnabled(‘blocklayered’)) { And these are the ones generating such a huge number of SQL queries on the product page. Interestingly, after removing these SQL queries from the Product class, the navigation filter block on category pages works correctly 🙂 I would report this on GitHub, but there’s no point, because no one has been handling these issues for almost a year now.

After analyzing the profiler logs, I realized that the “blocklayered” module was generating such a huge number of SQL queries. After disabling the module, the number of SQL queries dropped from 21 thousands to 3 thousands. It is puzzling that this occurs on the product page, where no navigation filters are supported. We need to take a closer look at the structure of this “blocklayered” module.

A painstaking analysis, examining 20 thousand SQL queries 🙂 For comparison, a Prestashop 1.6 fork called PhenixSuite. For a thousand attribute combinations, “only” 8 thousand SQL queries. So, to some extent, optimizing this functionality is possible.

Such a huge number of SQL queries is definitely a serious bug in the design of this feature. It results in very long loading times for product pages. That’s why, in PrestaShop 1.6, no one used this feature, and everyone was forced to purchase “Attribute Wizard Pro” module.