musicmaster

What about disabling pretty urls / deleting .htaccess? Without pretty urls you see the real paths of the images. And that means that you can look with FTP on the disk whether they ware there or not.

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.