Windows problems

[musicmaster]

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.

Edited November 11, 2019 by musicmaster

[datakick]

Regarding cheque module -- there's obviously error in the module itself. It

- instructs system that the module instance needs to be created, for example when rendering module list -- need_instance attribute in config.xml

- in constructor, it uses module ID to perform check. This id exists only when module is installed

Put these two thing together, add strict php 7.3 warning, and you know the root cause of the issue. The simple solution is remove this module from the filesystem, if you don't use it.

Of course, we could modify the Currency::checkPaymentCurrencies method so it always returns array. Unfortunately, this is compatibility issue itself -- there can be some code that do strict comparison on return value, ie:

if (Currency::checkPaymentCurrencies($this->id) === false)

And such code would stop working. Following checks would still work, though:

if (! Currency::checkPaymentCurrencies($this->id))

if ((bool)Currency::checkPaymentCurrencies($this->id) === false) 

 

With second problem I can't help you, because I can't reproduce it, and you haven't provided any actionable details.

[Occam]

I couldn't reproduce this issue either. The bankwire module works properly, there must be something else causing this error.

You can avoid warnings like this by changing the count() function to is_countable():

7 hours ago, musicmaster said:

if (!is_countable(Currency::checkPaymentCurrencies($this->id)))

Or, like I would prefer, too, by just deleting unused modules.

[Traumflug]

4 hours ago, Occam said:

You can avoid warnings like this by changing the count() function to _iscountable():

Not really. An empty array has a count of zero, but is countable:

    php > echo count([]);
    0
    php > echo is_countable([]);
    1

[Occam]

In any case it helps to avoid the warning, but I understand the problem. You should discuss this with the developers of PHP 7.3.

So what would you suggest as replacement: is_array ... || instanceof ... ?

[datakick]

They already fixed this

https://github.com/PrestaShop/cheque/commit/1401149dbb6fa08e65c2b43d9f88df970635a8f8

 

[datakick]

2 minutes ago, datakick said:

They already fixed this

I take it back. This commit is not a fix, it is a brand new bug 🙂

The proper fix would be

if ((int)$this->id && !Currency::checkPaymentCurrencies($this->id)) {
...
}

 

[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')

[datakick]

6 hours ago, musicmaster said:

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')

There is no place in the core that queries information schema in this way. This must come from some module.

My guess would be some module that generates custom order reference numbers, and it probably can't handle situation when there are no orders in the database yet...

[musicmaster]

4 hours ago, datakick said:

My guess would be some module that generates custom order reference numbers, and it probably can't handle situation when there are no orders in the database yet...

Quite a good guess. After some search I found that the origin of the first of the two queries was the Order.php override file from Greenmouse's gmnumeric.

However, the real cause appeared to be a faulty import. There were orders in the database but the auto-increase index was zero.