musicmaster

About the other error: the order that cannot be submitted. Here is how a timeout looks: I put some code in it to see what queries are processed. The first 152 queries look to be normal processing. But then it gets in an endless loop sending the following two queries again and again: SELECT `AUTO_INCREMENT` FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'snoeptb9' AND TABLE_NAME = 'ps_orders' LIMIT 1 SELECT * FROM `ps_orders` a0 WHERE (a0.`reference` = '0')

That is a choice and I can live with that. But I want to share my impression that Prestashop after the transition to 1.5 may have concluded that they had overdone it. That too many things had shop options and that as a consequence the software became too complex and too hard to understand for people who worked with it. And that as a consequence the development of modules might suffer. They couldn't undo the addition of the ps_group_shop table. That might break modules. But I doubt that is a coincidence that my shop always kept working with just one entry in this table.

Yes, I really claim that my ps_group_shop has only one entry at all. And I have kept all the old versions of the database and they all have it so. And it has never given a problem - until recently.

Yes Sure, there was only one shop. But there were already 3 groups in 1.4. And there was only one entry created: for group 1.

Prestashop 1.4 is monoshop. So it doesn't have _shop tables. They are added when you upgrade to 1.5. And that upgrade process created tables with only one entry - connecting shop 1 with group 1.

I explicitly mentioned ps_group_shop. ps_shop_group has nothing to do with groups. It is about bundling shops in multishop for common stock. The one entry I have in ps_group_shop was created by the Prestashop update process. So I wouldn't be surprised when every shop that old had the same.

This shop dates from PS 1.4 and since its transition to 1.5 it has had one entry in the ps_group_shop table. If you have suddenly changed the rules that this becomes a problem than you can expect more people complaining. But thanks for pointing out what is likely the problem.

I am testing the bleeding edge under PHP 7.3. I get some serious issues that happen only under Windows: - I get irregularly the warning Warning on line 66 of /modules/cheque/cheque.php [2] count: Parameter must be an array or an object that implements Countable in many different pages. The module is present but not installed. Line 66 says: if (!count(Currency::checkPaymentCurrencies($this->id))) and I have no idea what could go wrong there. - the second problem is a first class showstopper: I cannot submit an order. I test with bankwire. When I press the final button to confirm the order/payment I get a timeout. The error screen isn't helpful: it only lists the database module.

In the bleeding edge the category form shows only one group. The consequence is that when you save a category it will end up belonging to only one group: 1=default. This applies both to new groups and to groups that used to work but are saved after some change. For registered customers this means that they will see a screen that says that they are not allowed to access this category.

As for php.ini, Prestools has at the bottom of its Server Settings page a line that shows where you can find it in your file tree.

Oops, a typo. I will correct it.

I am puzzled why it should not work with you. If you pm me access I would love to have a look. I like solving mysteries. Anyway, I have uploaded a new version. Maybe that will solve the problem.

I am not sure what you mean. The minimodule is indeed only to create a link in your backoffice. It looks like in your shop images haven't been generated for all the image formats that you defined. I am working at a solution for this.

We don't know what template you are using and so we don't know your category.tpl file so it is impossible to say what goes wrong. You should open those cache files and look at the indicated line what goes wrong. Then you should look in the category.tpl of your template for the same line (this is at a different line number!)

Why would you want to save the zip file?

You have the reference code field for such info.

Just wondering: is it having problems with the dashes in the ids?

Did you press the "Generate" button? Just pressing OK won't work.

Searching on the forum for "myparcel" I followed one of the provided links and I got a "forbidden" page. Is there something wrong with the forum? This is the link I clicked on: And this is how the page looked like

It is easy to see (in modules->positions) what hooks the Paypal module uses. It could also be an override that causes the effects that you see. Prestools offers an easy way to see which overrides are installed.

This might be just some Paypal picture that says that you support it. You can see what it is by either: - look at the source of your page in the browser (right click somewhere on the page and then choose source code) and then search for "Paypal" - Open the "console" of the browser, choose the network tab, refresh the page and look for the line that concerns Paypal

This looks like a place where html should be used. So the question is what causes that the html is not processed by the browser but rendered raw. The best way to find out is to look at the (html) source of the whole page in the browser.

There are many ways. One is to look for products with active==0 You might also consider further finetuning by using the second search option for date_add and putting there the day you imported the csv.

I have to join wakabayashi. The big question is how you got this problem. Obviously you did something wrong during the migration as this is not a common problem. As a result there may be other tables with similar problems.

You should have one /img/p tree. To which shops images are assigned should be determined in the tb_image_shop database table.