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.

Thirtybees inherited a completely useless attribute combination feature from PrestaShop 1.6, which generates a huge number of SQL queries on the product page. After running tests with a profiler, it’s clear that this serious bug in the store engine’s architecture has been fixed in the latest versions of PrestaShop. I believe that fixing this bug should be a priority in Thirtybees, because in its current form, this feature is completely useless, except perhaps for a few or a dozen attribute combinations. The screenshots show profiler data for a product with a thousand attribute combinations.

Diagnostics: - are there any PHP errors (module: Collect PHP Logs), - are there any JavaScript errors (browser Firefox: Ctrl+Shift+K), - are there any overrides of ContactController (module: Override check), - is any anti-spam security module installed (reCaptcha, hCaptcha, Cloudflare Turnstile, etc.).

I use "Email Templates Manager" module: https://addons.prestashop.com/en/email-marketing-automation/25939-email-templates-manager.html To build email templates compatible with module, use Emails SDK: https://github.com/PrestaShopCorp/email-templates-sdk Like any Prestashop module, this one has a lot of bugs and needs to be fixed first. The screenshots show a sample email and the email configuration in the module.

With an outdated version like PrestaShop 1.6, you shouldn't change the PHP version, as it will cause a whole host of errors. The maximum supported PHP version for PS 1.6 is 7.1

No store in the world offers a "nicht registrierte Gastbesteller" option. The "Guest Checkout" option involves the standard registration of a customer account with the store, including all personal and address information. The only difference is that the customer does not have access to their account. Shopping without registration would mean that, during the checkout process, the customer would not provide ANY personal or address information, and a psychic employed by the store would provide all the customer information needed to complete the delivery. Such stores do not yet exist anywhere in the world. Many fraudulent stores mislead customers by labeling this option as "Shopping without registration" or "Shopping without creating an account", when they should provide the correct information: "Shopping without access to your account". Additionally, in this "Guest Checkout" option, everything is in violation of the General Data Protection Regulation (GDPR). In the "Guest Tracking" option, the customer also logs in to view their order. The customer logs in using their Order Reference and Email address.

Since there had been absolutely no activity on GitHub for over six months, I assumed the project had been abandoned and stopped submitting pull requests, considering it a waste of time.

Currently, the returns feature only works for orders with the statuses “Shipped” and “Delivered,” which makes sense, since it would be difficult for a customer to return products they haven't received. Therefore, adding the ability to cancel orders to the returns feature would require a major overhaul of that functionality.

Database, PREFIX_employee table, campaign_disabled field. Set the date 100 years in the future.

@DRMasterChief Whether a customer sends an email via the contact form or through an email client, it’s always just sending emails with no integration with the store’s functionality. This doesn’t automate any operations in the store and requires labor-intensive handling by store staff. There are industries where the return rate reaches as high as 40%. At a company like Zalando, they have to process thousands of returns every day. So the number of canceled orders will also be enormous.

@vir The module you're promoting includes the following description: “This module adds a withdrawal request button to the order detail page in the customer account.” So I assume that the customer must be logged in to submit a request to cancel an order. There isn't a demo of the module, so it's hard to say much more about how it works. I provided the WooCommerce and Shopware examples to show that in every e-commerce application, the customer must be logged in to manage their orders. Without logging in, the only option is to send emails to the store.