Yabber

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.

@vir When processing a return, the customer simply selects the items to be returned and, if necessary, adjusts the quantity (they don’t have to return all the items). What is difficult about this interface, and what could be simplified? What aspect of this procedure is inconsistent with EU directives? Is it true that, under EU directives, a customer can cancel an order at any time (even 10 years after purchase), the store must refund 100% of the payment, and the customer does not have to return any products?