Details of order don't display in backoffice

[clx81]

Hello,

Since the update to 1.7.7, the details of the ordered products no longer appear (the list is empty), the others informations are correct.

On the last command before the update, the click on the small arrow under the command ID is of no effect, the window does not unfold.

On orders placed before the update, the display is correct and the ordered products are well listed.

Now, to have the details of the ordered products, we have to go to "Baskets" and do a search by date which is not very convenient for tracking and can lead to errors.

The problem is also present in invoices and delivery slips. For orders placed after the update to 1.7.7, there are no more product details.

On the frontend, the number of products in the basket only updates when you change the page or when you refresh the page by F5.

Is there a possibility to go back to the old version of order management?

Cordially.

[jetway]

Which Theme are you using? Most likely is a custom one that is not compatible with 1.7.7. Are you using any custom shopping cart or checkout modules?

[clx81]

Hello,

We use the original theme and the shopping card supplied with Prestashop.

We avoid the use of external modules to avoid any problems during update, we have very bad experience with that in the past.

Our IT administrator has updated our server (Debian 10 - PHP 7.3.26 - Maria DB 10.4.17) and installed the last Nginx version but nothing change.

We have try to deactivate the cache, but the problem is always present.

We must say also that we have a big database with around 10 000 products. When starting the backend, it take about 2 or 3 minutes before accessing the functions but we live with it. During this time, the frontend is also blocked. But that situation is not new for us, we know that since some years. So nothing to do with the related problem.

When examining the "informations" in the backend, we see these message: (sorry it's in french)

Liste des fichiers modifiés

Des changements sur vos fichiers ont été détectés.

Fichiers manquants (6)

vendor/composer/installers/src/Composer/Installers/TaoInstaller.php

vendor/composer/installers/src/Composer/Installers/Redaxo5Installer.php

vendor/composer/installers/src/Composer/Installers/MantisBTInstaller.php

vendor/composer/installers/src/Composer/Installers/KnownInstaller.php

vendor/composer/installers/src/Composer/Installers/DframeInstaller.php

vendor/composer/installers/src/Composer/Installers/SyliusInstaller.php

Edited February 3, 2021 by clx81 (see edit history)

[musicmaster]

So it says "missing files". Did you try copying those files from a fresh PS 1.7.7 installation?

[clx81]

Thank you for the quick answer.

We will try to retrieve the missing files from a local 1.7.7 installation.

I keep you inform of the result.

[clx81]

Hello,

We have copy the missing files, set the correct rights and reboot the server. Now, we don't have errors in the "Informations", but the problem still the same !

It's very strange, because for the orders received before the update, all informations are correctly displayed but the last one (nothing displayed).

 

[musicmaster]

Check the database. Are the order lines for the new orders present in ps_order_detail?

[clx81]

Thank you musicmaster for your help !

I don't find the way to check the database in the front end, but our IT manager has install a program call Adminer and now I can see the DB content.

In ps_order_detail the last order recorded is the last one before upgrading and these one can not be viewed in the Orders tab.

From the backend, in the basket tab, we can see all the orders. With Adminer, I can see also all the 'cart' in ps_cart.

Our IT manager recommends me to re-index the complete Prestashop database, I'm looking now how to do that... What's yout idea about that ?

[clx81]

Attached a screen copy :

 

Edited February 4, 2021 by clx81 (see edit history)

[musicmaster]

I get the impression that you don't understand the mechanism very well.

Before you place an order the main data are in the ps_cart and ps_cart_product tables.

When you place an order those data are copied (in a slightly different format) to the ps_order and ps_order_detail tables.

It looks like that process isn't going well in your case. Usually the source of such problems is the payment module. So very likely if you use a different module (like bankwire) things will work ok.

 

[clx81]

We accept only bank transfert so when we have received the paiement on our account we click on the icon to select "paiement ok" (on the page Orders) and we continue with the shipping.

We work like that since many years but may be it's not the right method with the new update.

We have check the configuration of 'Paiement' and there is no more options compared with the last version, we have saved the bank information again to be sure.

If i understand our explanation, with the update 1.7.7, the order management must be done in the "Card" but we don't see how to inform the system that paiement is ok to continue the procedure (shipping and so one). We continue to check the way you recommend.

A new problem ! Time to time, some customers ask us an invoice. It was the case this morning, one of our employee has tried to generate an invoice by clicking on the icon at the right (page order) and has received an http 500 error, we have restarted the server but the problem persist !

this is the message:

Unknown column 'ocr.deleted' in 'where clause'<br /><br /><pre>
SELECT *
FROM `ps_order_cart_rule` ocr
WHERE ocr.`deleted` = 0 AND ocr.`id_order` = 693</pre>

I have checked with Adminer, the "ps_order_card_rule"  is empty, but may be we don't use the right options ('orders' instead of 'cards').

 

 

 

Edited February 5, 2021 by clx81 (see edit history)

[musicmaster]

14 minutes ago, clx81 said:

Unknown column 'ocr.deleted' in 'where clause'
SELECT *
FROM `ps_order_cart_rule` ocr
WHERE ocr.`deleted` = 0 AND ocr.`id_order` = 693

This suggest that you upgraded in an improper way. This field was only added in PS 1.7.7.0. So it looks like you upgraded without running the proper Prestashop script that added this field.

This could also explain your other problems. Much of Prestashop's processing happens by Ajax calls so you don't see error messages when things go wrong. But another missing field might crash those scripts.

[clx81]

We never changed upgrade script (we are sellers not programming specialists !), we always used the official one thru 1-Click Upgrade.

Ok,  so we are looking how to run the update 1.7.7.0 to correct the problem.

1-Click Upgrade don't show any options to install an old version. However my collegue found it on internet on https://build.prestashop.com/news/prestashop-1-7-7-0-available/

We look now how to install it.

[musicmaster]

The 

40 minutes ago, clx81 said:

We never changed upgrade script (we are sellers not programming specialists !), we always used the official one thru 1-Click Upgrade.

Ok,  so we are looking how to run the update 1.7.7.0 to correct the problem.

1-Click Upgrade don't show any options to install an old version. However my collegue found it on internet on https://build.prestashop.com/news/prestashop-1-7-7-0-available/

We look now how to install it.

I don't see anything interesting on the page you link. Under the Install directory (if you didn't delete it)  you can find which database changes are made for each version. As you can see in the attached file, the list for 1.7.7.0 is quite long. 

1.7.7.0.sql

[clx81]

My idea was to run "1.7.7.0 install" in the existing installation to come back in this version. But after reading some topics in this forum, it's not probably the best idea.

So may be, after putting the site in maintenance,  we can run the "1.7.70.sql" you send us inside Adminer line by line to receive informations about eventual problems but I have to read more before because it's new for me.

[musicmaster]

3 hours ago, clx81 said:

My idea was to run "1.7.7.0 install" in the existing installation to come back in this version. But after reading some topics in this forum, it's not probably the best idea.

So may be, after putting the site in maintenance,  we can run the "1.7.70.sql" you send us inside Adminer line by line to receive informations about eventual problems but I have to read more before because it's new for me.

Note that "1.7.70.sql" is not really a sql file. It has encoded the prefix. So you need to make some changes.

My primary motive to send you the file is that you can check whether the other changes are indeed missing too.

I don't know from which version your last update came. If it was older than 1.7.6 you may need to apply more changes.

[clx81]

Hello again Musicmaster,

I spoke with the employee who carried out the updates via 1-click-upgrade and he gave me the following information:
The site was in 1.6 until october 2019, it was already impossible to pass it in 1.7 (4000 articles at that time). According the Prestashop team recommandations, he started a new installation without any external templates or modules and reintroduced the 4000 articles manually one by one by copy / paste from the old version via the 2 backends. After 3 weeks of intensive work, the site was operational in version 1.7.
During one year, he added manualy about 5000 articles to be up-to-date with our management program and made the updates as proposed by the backend, the first one was done end 2019 to 1.7.6.1. Therefore, the following updates follow: departure : 1.7.6.1 - 1.7.6.2 - 1.7.6.6 - 1.7.6.7 - 1.7.6.8 - 1.7.6.9 - 1.7.7.0 . It is with the 1.7.7.0 version that the problems appeared.

Believing the update "buggy", he installed the 1.7.7.1 three weeks ago, still as proposed by the backend. This update did not solve anything. His idea was to ask our VPS provider to restore the situation to version 1.7.6.9 but the backup run everyday during the night and only the last 14 days are keeped.

This explanation fits well with your remark about version 1.7.7.0.

In FTP, I can see in "adminxxx/autoupgrade/backup" some files corresponding with the mentionned version from 1.7.6.1 to 1.7.7.0.

We don't know if it will be possible to restart with these files. Prestashop team say that this king of restore will be done manualy but without waranty and without explanation how to do it.

Our boss ask us to stop the modifications until monday evening because more of the sales are done during the weekend and the monday we have to tranfert the orders in our ERP Dolibarr witch is the main software to manage our 3 physical shops (operations done by copy / paste) and in the another side update Prestashop with the stock quantity.

Tomorrow, I visit a company also using Dolibarr ERP since a long time with an e-commerce site. They use the Dolibarr ERP directly as a backend of the web shop with a open-source CRM called Moginto (not sure of the name) acting as a frontend so manual update of each database is not necessary and the stock is up-to-date in real-time, new products and price modifications are also updated automaticaly. The two applications are on two VPS. This is nice but we have to verify !

I keep you inform of the results (I have seen that we have to change the prefix in the SQL file). This week-end, I will learn more about SQL to understand what's I do.

[musicmaster]

Prestashop upgrades are often problematic. So the standard advice is to upgrade only when you really need to do so. Following every new version - as you seem to do - is certainly not recommended.

It is also standard advice to make a backup of your files and database before you do an upgrade. Do not rely on the backup that Prestashop makes when you do an upgrade. Their roll backs very often fail.

The best strategy in the present situation - if the SQL upgrade isn't enough - would probably be to use my free tool Copy_shopdata to move your data to a fresh PS installation of the same version.

Edited February 6, 2021 by musicmaster (see edit history)