Passer de la version 17.3 à la version 18 - mise à jour de php avant ou après

Bonjour,

J’ai voulu vendredi mettre à jour ma version de Dolibarr qui est en 17.3 à la nouvelle version 18.
Grace à « Ksar » qui m’a beaucoup aidé récemment pour faire les mises à jour, j’ai suivi toute la procédure et la mise à jour s’est faite… sauf que juste avant de finaliser la mise à jour, il a été affiché que 2 lignes dans la base de donnée n’a pas pu etre mise à jour (désolé, je n’ai pas noté les noms des 2 lignes dans la BDD).
N’y connaissant pas grand chose, j’ai coché la case « forçant » tout de même la mise à jour (c’était sans risque, j’avais fait une sauvegarde avant).
J’étais donc désormais sur la version 18, mais j’ai vite rebasculé sur ma sauvegarde de vendredi sur la 17.3 car je ne pouvais plus copier ou créer de nouveaux produits !
Ma question est la suivant : Je pense que cela est lié à ma base PHP qui est en 7.8 alors que la version 18 de Dolibarr est sous PHP 8.2. Faut-il donc mettre à jour PHP en 8.2 sous Dolibarr 17.3 avant de passer en version 18? Ou tout autre chose? Ou même ça n’a peut être rien à voir?
Merci d’avance,

Bpnjpur,
La V18 est comptatible php8 mais tournera egalement en php7. Il serait interessant de refaire votre maj et de noter les 2 tables en erreur.

Bonjour Manunord, si j’ai pas trop de boulot demain, je relance un essai de maj et si j’ai le même problème je te listerais les 2 tables en erreur.

Bonjour, je ne sais pas si c’est le même problème mais je suis bloqué sur la mise à jour 17.2 vers 18 avec l’erreur suivante:

Erreur DB_ERROR_1452 (Req 23): ALTER TABLE llx_product_stock ADD CONSTRAINT fk_product_product_rowid FOREIGN KEY (fk_product) REFERENCES llx_product (rowid);
Cannot add or update a child row: a foreign key constraint fails (dolibarr.#sql-c6c_4eb5, CONSTRAINT fk_product_product_rowid FOREIGN KEY (fk_product) REFERENCES llx_product (rowid))

Si quelqu’un a une idée pour me dépanner avant de revenir en 17.2.

Merci par avance.

Il y a une ligne fantôme dans llx_product_stock à corriger/supprimer. Il faut l’intervention d’un expert.

Je confirme, c’est bien ces tables qui coincent, et si on force la mise à jour, elle se fait mais on ne peut plus (entre autre) cloner un produit… pas top quoi.
Oui si un développeur lit ce message, merci de faire remonter l’info.

Bonjour,

Cloner un produit ne vient pas de la non migration de la base, c’était une erreur de code qui a été corrigé sur GitHub et qui sera disponible dans la V18.0.1

Bonjour,

Ok merci Ksar pour l’info, tant mieux si c’est pas lié au clonage des produits et que ça va être corrigé rapidement, mais il y a donc quand même toujours ce problème de table qui, même si je n’ai pas vu de conséquence encore de cela, est un peu gênant…

Bonjour Ksar, je viens de mettre ce matin à jour Dolibarr 18.0.1.
Pour le moment je ne vois pas de bug impactant à revenir sur la 17.3, et en effet, le problème du clonage de produit a été corrigé.
Néamoins, je tiens à souligner que lors de la mise à jour, j’ai quand même eux à forcer la procédure car il y’avait encore une fois (comme pour la 18.0.0) 2 erreurs, ce qui m’inquiète un peu.
Voici l’imprim écran :

Bonjour,
Comme Benoit, je suis actuellement sous v17.3 et j’envisage la mise à jour vers 18, mais lisant ce poste je crains de subir quelques ennuis techniques.
Je suis en php 7.0.33 (synology DS718) et je ne sais pas comment le mettre à jour.

J’ai bien lu manunord qui disait « La V18 est comptatible php8 mais tournera egalement en php7… » mais avant de me lancer, je serais plus rassurer si on me confirmait que mon instance continuera de bien fonctionner ?

Merci, bonne soirée.

Pour ma part, sur mon Syno, je suis en PHP 7.4.30 et doli V17.0.3 et pas de soucis
J’ai une instance de test en V18.0.1 qui pour l’instant passe tous les tests

Bonjour Magicglide et Tonio-APEIF,

Je vous confirme que pour le moment ça marche bien. J’utilise la 18.0.1 en pleine activité d’entreprise et je n’ai pas constaté d’autres bug à part celui que j’ai mis en imprim’ écran au moment de la màj.
Je tiens à signaler toutefois qu’il peut y avoir des options dans les modules à « recocher à la bonne place » par rapport à notre manière d’utilisation. Je pense particulièrement à la déduction et ajout de quantité de produits lors de création d’expéditions ou réception de produits. La mise à jour m’avait automatiquement coché les cases de mouvement de stock (module Workflow) qu’au moment de la facture et non au moment de la création du bon d’expédition/réception… Ça m’a fait une sacré frayeur au bout d’une semaine d’utilisation de la 18.0.1, ne voyant pas les stocks bougés… La plupart de mes clients, je leur crée une facture en fin de mois de tout ce que je leur ai vendu dans le mois. Sans m’en etre aperçu au bout d’une semaine, j’aurai pu avoir les mouvements de créés uniquement à la fin du mois !
Mais bref tout ça pour dire que tout à l’air de plutôt bien fonctionner, sous réserve de revérifier ses paramètres de fonctionnement juste après la màj.
PS : je suis sur PHP 7.4.30

Pour Magicglide personnelement : Si tu souhaite faire une mise à jour, que tu n’en a jamais fait, et que tu es comme moi (un peu bidouilleur informatiquement parlant mais pas développeur), je t’invite à lire le post que j’avais publié et les réponses de Ksar qui a développé un script pour simplifier les màj pour les « noobs » comme moi :yum:

Bien que Dolibarr soit un logiciel franchement top et accessible à tous, je trouve que niveau màj y a un vrai travail des développeur à faire dessus car c’est loin d’être simple. Le script de Ksar simplifie énormement la démarche (et je le remercie encore) mais il y a encore la démarche de déposer le script en ftp au bon endroit, ce qui peut être un peu délicat pour un simple utilisateur.
Je pense que ce script (ou un module similaire) devrait être intégré de base sur Dolibarr pour pouvoir faire les màj par tout le monde, peu importe son niveau informatique.

Je pense au contraire que la mise à jour ne doit pouvoir se faire que si on maitrise l’administration d’un serveur en ligne. Comment quelqu’un qui ne sait pas dans quel répertoire déposer un fichier peut-il raisonnablement assurer la sécurité d’une application hébergée en ligne ?

De plus télécharger un script et l’éxecuter sur un serveur sans analyse préalable du script pour savoir ce qu’il fait est une aberration du point de vue sécurité.

Bonjour,

Comme indiqué ici : Doli_Install : Script d'installation/Mise à jour de Dolibarr
Le code source est ici : https://github.com/ksar-ksar/doli_install/blob/2ec9520523e97e1a25c3588367bf086c4342efd2/doli_install.php

merci Benoit pour ton retour.

j’ai pas de soucis pour mettre à jour Dolibarr. De mémoire, j’arrive de la version 4.
Ce que je ne sais pas faire c’est mettre à jour mon php. Mon instance Dolibarr utilise la version 7.0.
Sur mon Synology co-existe la version 7.4 mais je sais pas comment dire à Dolibarr de l’utiliser :frowning:

Un fois des backups réalisés, je tenterai bien la mise à jour vers Dolibarr V.18 mais si jamais ça caffouillait, le retour arrière est-il facile ? (jamais eu à le faire)

Merci pour vos retours.

Bonjour « hop ». Comme t’as répondu Ksar, son script a été « validé » et accessible sur Github. Ksar est un modérateur agréé de Dolibarr, je pense qu’on peut honnêtement penser que son script n’a rien de « dangereux », sinon il va avoir de gros soucis par la communauté :yum: !
Sans vouloir épiloguer sur ce sujet, j’estime qu’une mise à jour d’un logiciel ne doit pas être l’affaire d’un expert en informatique : Développer un module ou un script oui, mais simplement mettre à jour son Dolibarr clairement non. Très souvent, les mises à jour peuvent corriger des failles de sécurité, donc autant faire en sorte que les mises à jour soient les plus accessibles à tous, même au plus néophytes, pour éviter des catastrophes.
Pour Magicglide : Honnetement, j’en suis au même niveau que toi, à ne pas savoir faire une mise à jour de mon php. Je regarde pas mal de tuto mais ça me parait pas simple.
De toute façon, la règle d’or elle est simple : faire une sauvegarde de tout avant de se lancer là dessus. Moi j’ai eu déjà à faire retour arrière après une màj de Dolibarr qui déconnait (pas PHP). Mon Dolibarr étant sur un server Ionos, j’avais fait une image du server avant de faire la màj. Il m’a simplement fallu « écraser » tout le server par l’image que j’avais fait pour revenir en arrière. Je pense que mon PHP est situé dans ce même server, donc théoriquement, si c’était la màj de PHP qui aurait déconné, j’aurais procédé de la même manière pour revenir en arrière.

Je vous invite à lire le paragraphe « mainteneurs github compromis » sur cette publication
https://medium.com/@sonya.moisset/guide-de-sécurité-pour-les-logiciels-open-source-meilleures-pratiques-pour-sécuriser-vos-projets-c7ea78acb615