musicmaster

Without showing an url or telling us exactly what you have tried it is impossible to help you.

This sounds like an Ajax error. You have to look in the error log to see what they are about. You can see it in the browser too but that is a bit complicated. I have explained it here: https://www.prestashop.com/forums/topic/994407-how-to-debug-ajax-errors-jqxhr-unexpected-token-technical-error/

I would start regenerating .htaccess and cleaning the cache. When the problem is solved when you turn off pretty urls this should solve the problem.

Your report left me with lots of questions: - your first post mentions going to quick order. That suggests that the links go to "quick_order", that you can see that when you move your mouse over the links and the link_rewrite field is filled with "quick_order". Of course that raises the question what value your csv import file had for that field. - you say that "importing into the production site and I get errors". Which errors

I went to the translations page for pdf's and got the attached error message popup. It is puzzling in several ways: why should the coreupdater module be accessed at all in this situation? What is the problem with those directories?: this is a Windows pc without access restrictions. I got this after I upgraded my shop to 1.2.0. The error does not happen on the original server. It only happens on the copy that I made of that shop after the upgrade on my local pc. PHP 7.3

As the.rampage.rado said, this could be a cache issue. Otherwise one needs to have a look in the database whether these combinations are still there and then one can look why they aren't shown. But for that one needs database access. You can pm me if you want. Then I can have a look.

Copy_shopdata doesn't copy modules. So deleting them from the ps_modules tables is not needed. For knowing which modules were in the old shop - so that you later can install them in the new shop - you should either look in the backoffice or at module-info in Prestools. If you look at the database you should combine that with a look at the modules directory as deleting the files is a rather common way to delete modules (and that leaves them in the database). I once had a look: there are two "countries" in the TB database that don't have VAT: Guernsey and Gibraltar. If 21 is in the id_tax_rules_group table there must be another explanation for this warning. I am not sure what else it could be.

This may have to do with faulty data in your database. It says that some product has an id_tax_rules_group value of 21. And that value may be not or insufficiently defined. If you don't use VAT the id_tax_rules_group would be expected to be zero. BTW: VAT is not a module. It is a fundamental part of the software.

The point of Github is that it is the work stack for the development of the software. So it is good to add clear bugs there. Whether you also post it on the forum I would make that dependent on whether it is of interest there. Will it help other people to be aware of a problem or is it too obscure? And might they have suggestions for a work-around? In most projects you will get a message like "thank you for the report. we will look at it" after a Github report. But the actual fix almost always takes much longer. It is a pity that you didn't get such a message now. But that doesn't mean that the issue will be ignored.

Strange, I didn't change anything in this part of the code for ages. Maybe you changed some setting in Prestools. It is the display of the VAT. Do you see any problem there?

I uploaded a new version. Zip files is somehow an imperfect technology that keeps giving problems.

Did you try what happens when you set quantities with Prestools?

This is starting to sound like you have a problem with the naming that leads to confusion.

Don't worry. You don't have any character set/collation problem. utf8mb4 is just preferred for Thirty Bees. There is no obligation. Anyone who has migrated from Prestashop has an utf8 variant. Prestashop only switched to utf8mb4 with 1.7.6 or 1.7.7. That latin_swedish collation isn't a problem either. Some modules that have their own tables make them in the format that they prefer. And that is ok.

The Alter Table command tells me that two records have been added to this table. But I don't see those added records in your list. The "wrong/swapped" issue is only becoming fuzzier to me. What is the problem? Do you have wrong values for quantities or are they only swapped between variants?

I don't see anything suspicious that could explain anything. But I am puzzled by the tags, the initially empty redirect field in the ps_product_shop table and by the Alter Table command. It looks like more is happening than you tell. That "wrong/swapped" is a kind of fuzzy language that doesn't help.

Thank you for your report. I fixed it.

A trick that might help is comparing database exports. - Export a shop database. - change a quantity in the backoffice - export the database again - compare the two exports with a program like Winmerge. - now do the same when changing a quantity in Store Manager

I don't have time to research this myself. But it shouldn't be that difficult if you are prepared to get dirty hands in Phpmyadmin: - in the first post of this thread you mention a product that shows 1799 stock while it is not in the settings. So do a database search for any field in any table with the content "1799". - stock is in many tables: ps_product, ps_product_shop and ps_stock_available. Only the last should count. But in cases like this it might be that things get mixed up. So you should check for that. - with profiling you can see the database queries that were made. That can provide leads were things go wrong.

On closer look I saw that it is the module psseobooster that contains a call to mysql_error(). What happened was that there was some kind of error in this module. This module had proper error handling but it used this outdated function for it. And so you saw only the error that this outdated function didn't exist instead of the real problem that this function should have displayed. I don't see what Thirty Bees could have done to help you in this case.

First step: look in the HTML code in your browser whether those images are linked there or not. Second step: look for a shop with the WH theme that does have those images (might be their demo shop) and look how those links go.

I don't understand why TB flags these "problems". As far as I can see none is really a problem. The order of the fields doesn't matter and a field size of "int" instead of int(11) will only become a problem when you sell more than 2 billion products.

Short analysis: - It looks like it comes from the module ets_superspeed. Try removing it from below the /modules directory and then clear the cache. - A call to a function mysql_error() looks really weird. The standard has become mysqli_error() years ago.

I don't see any problem here. The highest id_cart in ps_orders is lower than the highest id in ps_cart - as it should be.

If you are exporting you don't need to truncate. You can also just export the structure and not the data of those tables.