musicmaster

Those are exactly the areas where Prestashop is improving. In 1.7.3 they introduced multifeature and as far I understand they are now busy improving layered navigation. As far as I can those improvements can be made while maintaining backward compatibility. Unfortunately neither will be easy. Layered navigation is notoriously complicated (and for a long time had bugs with Prestashop) and when I implemented multifeature in Prestools and used - if I remember well - PS 1.7.3.2 as reference I found that there still were bugs in the implementation. My other wish would be discounts. At the moment you can't offer 3 for 10 euro. You get 9.99 or 10.02.

Having seen more extra space trouble (with the Mollie module) I wonder whether this might be a bit too radical. Did you consider alternatives such as warnings instead of errors or having an error message that explicitly tells you that there is an extra space problem? The latter might be a check for a space at the start or the end of the string after the error has been discovered and an extra message "It looks like you added a space to the key." behind the default message.

I used to have something similar for years. And then suddenly the blacklisters became aggressive. Sendgrid just serves as an alternative SMTP server (see https://sendgrid.com/docs/for-developers/sending-email/joomla/).

I had similar problem. In the end I gave up and started sending via Sendgrid. It is free up to a certain volume. They make money with mass mailings but you can do your normal mails via them too.

Having multiple products on a page is not really rocket science. See here for an example: https://www.topsnoep.nl/relatiegeschenken/2863-notenmand-zelf-samengesteld.html But there are many different scenarios where this would be welcome. Some are enhanced category pages - where people can enter quantities or select attributes. Others are enhanced product pages - where you can immediately order associated products. Yet others aim to be an alternative to the combination system, where some options are offered as separate products rather than attributes. There is also the question of presentation. In some cases you want the cluster to appear in the cart as one product that you can delete, change quantity or change composition. In other cases you prefer to see each product separate in the cart. In some cases you want one buy button for the cluster. In other cases one button for each product. Also related is the option to have "free" buy buttons that you can place on cms pages and pages that are not part of the webshop. It is this complexity that makes it hard to formulate a solution. And given the needed reconstruction it is best to make one big step instead of many small ones. You can set weights for combinations - but not lengths/widths.

Are you sure your Elastic 5 is running at port 9200? Couldn't it be that it chose another port because there was some remainder of the 6 version still occupying that port? In my installation the search uses also about 2.5 times the size of tb_product_lang. I guess that is the normal proportion. Elastic may be faster, but I doubt it will use less space.

How big is your tb_product_lang table? Did you have a look at the Preferences->Search entry in your backoffice. Maybe you can set some weights to zero...

Another approach is too look at your blacklist. Thirty Bees/Prestashop maintains a list of common words that are not indexed because they are too common. The English version begins with "a|about|above|after|again|against|all|am|an|and|any|are|aren|as|at|be|because|been|before|being". In other languages that blacklist is not always set. The blacklist is in the tb_configuration_lang database table. To find it you look first in the tb_configuration_table for PS_SEARCH_BLACKLIST. With that id you look in the tb_configuration_lang table.

That new rows are added to tb_carrier is normal. That way when you change your carrier prices existing orders aren't affected. The Prestashop bug you mentioned has a fix: https://github.com/PrestaShop/PrestaShop/pull/12946/files Did you try implementing that in your Thirty Bees file? Instead of line 695 you should read line 1089.

Glad to hear you like Prestools. Thank you for your suggestions. I will consider them - but at the moment I have some other priorities that come first.

Two times: yes. The first thing is easy to test.

A database as a whole has a char set. But individual tables in it can have different char sets. Can you check what char sets the blog tables use?

Did you try using it in product names too?

The difference between UTF-8 and utf8mb4 is marginal. All shops migrated from Prestashop use utf-8

Try copying text from a source that is guaranteed utf-8 and not latin, like this: https://www.bbc.com/russian/vert-fut-48422051 What happens when you try such texts in product names?