Upgrade from v16 to v17 broke things

Maintaining my Dolibarr
1

After upgrading to v17, a lot of things regarding orders/invoices/shipping has broken. The errors are consistent.

See image 1 for an example order where customer reference is added as well as one object. Here we click “Create invoice”.

Image 2 looks normal

Image 3, the reference is gone as well as the added objects. We have to re-add things again.

This is the same behaviour everywhere:

Sales Order → Shipping (all is gone and shipping cannot validate)
Sales Order → Invoice (all is gone but objects can be added and validated)
Proposal → Sales order (all is gone)
Proposal → Invoice (all is gone)

Etc. We set “7” to debug log level but cant find any errors and we dont get any error messages.

1
11343×729 24.1 KB

2
21285×756 22.1 KB

3
31325×690 32.7 KB

2

This is how it looks when we go from Sales Order to Create Shipping. Everything is completely bonkers.

2023-06-14_171847
2023-06-14_1718471164×514 17.9 KB

3

First guess: which php version are you using?

4

PHP 8.0.29 (cli) (built: Jun 13 2023 11:28:12) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.29, Copyright (c) Zend Technologies

5

So, it appears all errors appeared when our web hoster upgraded from PHP 8.0.28 to 8.0.29. We don’t know why, but we tried to wipe the database and revert to a version 16-backup that was made one day before the hoster did the upgrade, but now the error appears there as well so it has definately to do something with 8.0.29 so we tried to upgrade to PHP 8.1 but the error remains there as well.

Then we added PHP Error messages and atleast now we get a hint:

Untitled
Untitled1353×663 17.9 KB

The last error line is interesting so we dive down in expedition/card.php so see what’s going on. In the bottom part of the file (under the if ($action == 'create')) we find this:

$object = new $classname($db); if ($object->fetch($origin_id)) { // This include the fetch_lines

However, $origin_id is NULL, despite the URL has got “origin_id=nnn” in it. It seems some variables get their values lost in the way. Right after the object->fetch we added a print_r($object) and a lot of values are empty:

[id] => 
[entity] => 
[error] => 
[errorhidden] =>

(cut)
[fk_element] => fk_expedition
[ismultientitymanaged] => 1
[picto] => dolly
[fields] => Array
(
)

[socid] => 
[ref_client] => 
[ref_customer] => 
[brouillon] => 
[entrepot_id] => 
[tracking_number] => 
[tracking_url] => 
[billed] => 
[trueWeight] => 
[weight_units] => 
[trueWidth] => 
[width_units] => 
[trueHeight] => 
[height_units] => 
[trueDepth] => 
[depth_units] => 
[trueSize] => 
[date_delivery] => 
[date] => 
[date_expedition] => 
[date_shipping] => 
[date_valid] => 
[meths] => 
[listmeths] => 
[fk_incoterms] => 
[label_incoterms] => 
[location_incoterms] =>

No wonder why the Create Shipment page looks bonkers.

However, we are not skilled enough on PHP so we cannot understand why all these variables were wiped out and why there was an uncaught exception for this, and why all these errors appeared after the web hoster was upgrading PHP. There are so many questions, and we are stuck here because we cannot perform any work in our Dolibarr when it does not work.

This is very frustrating since upgrading Dolibarr or PHP doesn’t solve the problem either.

6

@gurksallad did you solve this ? same problem here.

7

No, problem is not solved but we made a backup of everything and moved to another server (running PHP 7) and there everything works as it should. I am therefore 100% confident that PHP 8.0.29 is the culprit here so I have added a Dolibarr-ticket on Github with the hope that the developers take a look because this bug is a major blocker.

8

The problem is not Dolibarr 17; it’s PHP +8 (8.0, 8.1, or 8.2). Although Dolibarr 17 has been “prepared” to be compatible with PHP 8.X, it will continue to encounter new issues due to incompatibility.

The reason is that from 7.X to 8.X, the PHP team decided to deprecate “a lot of” things (forbidden to use, causing an error if used). These are usually minor things that can be easily replaced by the current approved syntax. However, these small issues are scattered throughout the code, especially in a large codebase like Dolibarr.

Please note that this situation also affects third-party modules. So, usually, Dolibarr (or any other CMS) becomes broken due to certain third-party modules that have not been properly upgraded!

In these cases, the best recommendation is to DISABLE all third-party modules BEFORE UPGRADING. Well, in fact, the best suggestion is to TEST THE UPGRADE ON ANOTHER SERVER and address any issues that arise there before making the same changes on your production system.

I don’t want to be a spoilsport, but let me say that the HARD PART of using open-source server software is not downloading and installing it… the hard part is dealing with updates!! Especially major updates like this one for PHP. That’s why some of us provide value as providers to other companies by installing and administering servers and the software installed on them :sweat_smile:

Having said that, just this week, I had to change my hosting provider to gain access to a VPS with root access where I could run an obsolete PHP version (7.4, which no longer receives security updates since January 2023!!) due to these kinds of “minor” incompatibilities between Dolibarr (and third-party modules) and PHP 8.X :wink:

Honestly, I don’t have much time these days to deal with these kinds of errors in my customers’ Dolibarr installations. So, I prefer to migrate to PHP 8.1 in the next few months.

But hey, I’ll try to provide some help to other users here if I can :grin:

9

Hello,

thanks for this post, we had the same issues with V17 and ONE.com. They didn’t allow us to go back to PHP 8.0.28 or lower. We switched this weekend to hostinger provider and everything works fine.

The only thing which got missed during restore was that the payment are no longer connected with the customer invoices. Anybody an idea how to resolve this? the payments are still there just not connected.

using now PHP 7.4 and D V 17.0.2 ( strange is also with new provider Dolibarr works fine with PHP 8.1 as well when we test it :D)

thanks
Albi

10

@AvonKury We use One.com as well. Good to see (in a bad way) that we weren’t the only ones having problems with 8.0.29.

11

@AvonKury Doli works fine with 8.1 on a new provider? Interesting, I wonder what at One.com is the thing that breaks everything then. It would suck to have to change provider but since nothing has happened for two weeks with this bug (noone has assigned to it on Github) it seems we have no other option because this bug is completely hell.

12

Hi Gurkensalat,

yes under HOSTINGER it works even with PHP8.2. I just tested it. One is co hosting only, they dont have their own servers…

13

@AvonKury The issue with One.com is now resolved. @eldy digged into the problem and found that One had some sort of filter layer which removed variables that Dolibarr needs. I contacted them two days ago and they fixed it today, exactly one month after the issues began.

See (BLOCKER) Dolibarr breaks after upgrading from PHP 8.0.x to 8.0.29 · Issue #25117 · Dolibarr/dolibarr · GitHub for all the details.

14

Hi Gurksallad,

thanks for the info, yes correct now it works with Dolibarr again too. I will stay on my new providers server since they have much better support than ONE.

Albi