Order times out

[musicmaster]

I have a problem receiving orders.

I made a test order with payment by bankwire. When I click to confirm my order the page keeps hanging (you keep seeing the busy pointer) and finally times out.

When I open my browser console I see many times "Third party cookie will be blocked. Learn more in the issues tab.". Unfortunately the issues tab isn't very informative (see below).

I am running a version of TB 1.4.

Customers complain that they place an order and get a confirmation of the payment but not of the order itself. Strangely enough they mention the id_cart number as order number.

This started happening after the move to another server (both PHP 8.1). Most orders do not become visible in the orders list in the back office.

What is happening here? I would be happy to disable third party cookies, but I don't know which modules place them.

 

[musicmaster]

The above was in Chrome. In Firefox there is a timeout too, but this time I get a message that the secure connection failed.

[30knees]

Can you adjust the settings in the browsers to be the most permissive to see which cookies are set?

Can you figure something out via a tool such as https://privacyscanner.aesirx.io/?

Edited February 8 by 30knees

[musicmaster]

30 minutes ago, 30knees said:

Can you adjust the settings in the browsers to be the most permissive to see which cookies are set?

Can you figure something out via a tool such as https://privacyscanner.aesirx.io/?

I have changed nothing in the browser settings. 

I am amazed to see that https://privacyscanner.aesirx.io/ tells me that I am placing Google Analytics cookies without asking.

[nickz]

2 hours ago, musicmaster said:

Customers complain that they place an order and get a confirmation of the payment but not of the order itself. Strangely enough they mention the id_cart number as order number.

Maybe related:What mail is used for the sending?

As Google Microsoft and Yahoo are having new guidlines
https://www.darkreading.com/cybersecurity-operations/google-yahoo-push-dmarc-forcing-companies-to-catch-up

[musicmaster]

2 hours ago, nickz said:

Maybe related:What mail is used for the sending?

As Google Microsoft and Yahoo are having new guidlines
https://www.darkreading.com/cybersecurity-operations/google-yahoo-push-dmarc-forcing-companies-to-catch-up

DMarc is for mass mailing. Not relevant here.

[the.rampage.rado]

You moved servers - look into that. Configuration of the new server, especially https settings on it as it says that the connection is not secure.

Also those messages in the console are coming from Chrome, not your site. They will ban all third-party cookies soon (https://developers.google.com/privacy-sandbox/3pcd) and your checkout does not care for tracking, etc cookies at this point.

 

[musicmaster]

14 hours ago, the.rampage.rado said:

You moved servers - look into that. Configuration of the new server, especially https settings on it as it says that the connection is not secure.

Also those messages in the console are coming from Chrome, not your site. They will ban all third-party cookies soon (https://developers.google.com/privacy-sandbox/3pcd) and your checkout does not care for tracking, etc cookies at this point.

I have another - much smaller - shop running on the same account and it doesn't give problems. 

Most of the account is fast but some other pages are slow too. I booked some improvement in speed by truncating the ps_log table. But the total block in the validateOrder() function puzzles me.

 

[x97wehner]

The screenshot you shared has only ever happened to me when my SSL certificate expired on the URL. Perhaps verify on your host that yours is still good for that domain?

[musicmaster]

Solved.

It was the GMnumeric module. That is a module that takes care that the reference number is the same as the order number.

The problem was in the function validateOrder() in /classes/module/PaymentModule.php. The following code had become an eternal loop:

 do {
                $reference = Order::generateReference();
            } while (Order::getByReference($reference)->count());

GMnumeric overrides generateReference(). Now it always returned the number of the last order. 

I don't know why this happened on one server but not on the other.

 

[musicmaster]

It appears there is an update of GMnumeric that solves the problem.