musicmaster

Is this really necessary? I never before heard of a software package refusing installation because an expired certificate - a quite common problem.

Experience learns that even minor revisions can bring errors. So when someone reports an error it is always good to know exactly what version he used. You cannot ask someone to have a look in his database for what _TB_REVISION_ he has.

Isn't it possible to use normal subversions instead of revisions? Like 1.03.01 and 1.03.02?

One little other thing: the modified files. It seems to me extremely unlikely I changed all these files. Maybe one or two, but my impression is that most were changed in some system operation.

Updating indeed allowed it to go further. Thank you. The database software is MariaDB 10.4.8

When you asked for feedback about the Core Updater I reported too that it remained stuck at 42.86%. There was never a report that that was solved. I just checked for the log files from those tests: 4.3 and 8.9 GB. So Slick_303 is right. By doing a new "upgrade" that I broke off almost immediately after it got stuck at 42.86 I managed to get a shorter log file. I have it attached coreupdater-20211019.log

For a database export and import should work ok. Don't forget to cleanup the database before you start.

I am not sure whether AWP supports your second scenario. I doubt it. So you should ask them. You can do that on the Prodcombi page of Prestools.

You can use Prestools for managing the price of large numbers of combinations. It allows you to set prices on attributes. It is free However, the database structure can only handle a few thousand combinations. Otherwise it becomes too slow. The alternative is the module Attribute Wizard Pro but that is far from free.

I had it once again running and got this. I am afraid it is not a good idea to have so many ajax calls (the counter is here at 1684). On Windows computers they attract anti-virus checks and as a consequence they are slow.

It looked like CHECKING YOUR INSTALLATION stayed forever at 42.86%. I did it on a bleeding edge webshop that probably already was up-to-date.

Is it really necessary to declare this kind of stuff as "critical"? It seems to me that that word should be reserved to things that are likely to cause errors in your shop. I also found the buttons at the top right hard to find.

I made something similar here: https://www.topsnoep.nl/relatiegeschenken/2863-notenmand-zelf-samengesteld.html In it you select a basket and one or more products to insert into it. It uses customizations and involves about a hundred lines of code.

Just a little trick: The problem is well known. Searching for more than one word gives all products that contain at least one of the words. It is rather easy to change that. You need to change just a few lines in classes/Search.php On line 232 of Search.php you will find: $eligibleProducts2 = []; foreach ($intersectArray as $query) { foreach ($db->executeS($query, true, false) as $row) { $eligibleProducts2[] = $row['id_product']; } } $eligibleProducts = array_unique(array_intersect($eligibleProducts, array_unique($eligibleProducts2))); if (!count($eligibleProducts)) { return ($ajax ? [] : ['total' => 0, 'result' => []]); } You should change that to $eligibleProducts2 = []; foreach ($intersectArray as $query) { foreach ($db->executeS($query, true, false) as $row) { $eligibleProducts2[] = $row['id_product']; } $eligibleProducts = array_unique(array_intersect($eligibleProducts, array_unique($eligibleProducts2))); $eligibleProducts2 = []; } if (!count($eligibleProducts)) { return ($ajax ? [] : ['total' => 0, 'result' => []]); } This was done in TB 1.02. If you have a different version the line numbers may be slightly different.

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?