musicmaster

Is this is the only javascript error? This type of errors often happens as a follow-up error after some prior error has caused problems loading jquery.

Depends. If you can export them as csv you can import them as csv. So it depends on your present setup. There are many tools available that will do the job for you to transfer the data from other webshops. But you will need to provide more details if you want a prescription that fits on your situation.

Different column names are no problem as you can assign columns when you import a csv file. If you want to insert directly into the database you face a big challenge. At the most basic level products and categories are each present in four tables.

Looks nice! I had a bit trouble getting started. You have a link to a test shop but I couldn't find username and password. An install under 1.07 failed ("controller not found"). It is a testshop so maybe these was something broken by me. On my 1.08 test shop it then worked ok. What I would like the module for is follow up discounts. I sell individual plugins and I sell a package that contains all the plugins. When a customer first buys an individual plugin and then the package I want to give him a discount related to the price of what he bought previously. I had such a thing under PS 1.6.0 but it didn't work under TB and I never came to building an alternative. As far as I can see I will need to build my own sql. However, it is not clear to me how I can include the prices of the products. One suggestion for improvement. When I click on "Select Action" I would like to go back to a list of all the possible actions. Now I stay within my selection (execute custom sql).

My guess would be a javascript error. Did you check for that?

1 is not always the root. When you have an upgrade from Prestashop 1.4 "1" is Home and the root has some high id number. In 1.4 Home was the base level. In 1.5 multishop was introduced and Root was added to come under the Homes of the different shops. Given that id_category is an auto-increase field that meant that it got the next free id_category. So my guess would be that 60 could be your Root. But you don't show it so we can't see its parent.

Hi Stephanie One option is not yet mentioned: attribute combinations. One option is one piece. The other is three pieces in whatever combination you like. I use something similar in a webshop where you have weight options of 200 gram and 1 kilo.

Any errors in the php logfile of the server?

Could it be that you had defined a home category for that shop that no longer exists?

If you buy 4 (or more) 25% discount?

What is your setting for Smart cache for css?

The backslash serves of course also as an escape character. So you might need to double (like "\\") to have the desired effect.

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?