[RESOLU] problème migration 7.0.3 vers 8.0.4

Bonjour,

Après avoir réalisé des essais de la version 8.0.4 de Dolibarr en local, qui se sont révélés concluants, je viens de procéder à la migration manuelle de la V7.0.3 vers la V8.0.4, en production.

Lors de la migration des tables, j’ai obtenu le message suivant (répété plusieurs fois). …
Warning: Division by zero in /home/clients/<mon_rep_client>/web/dolibarr/htdocs/core/class/stats.class.php on line 389
Warning: Division by zero in /home/clients/<mon_rep_client>/web/dolibarr/htdocs/core/class/stats.class.php on line 391

… j’ai poursuivi l’installation et tout semblait normal, sauf que lorsque l’on lance les ‘statistiques’ dans le module « adhérent » le message réapparaît.

image1.png

dans ‘Outils d’administration’ => Infos Web Serveur, je constate également le message suivant :
Warning: exec() has been disabled for security reasons in /home/clients/<mon_rep_client>/web/dolibarr/htdocs/admin/system/web.php on line 65

image2.png

il semble que le fichier web.php ne se soit pas exécuté correctement et que l’identifiant ‘id’ du serveur (utilisateur/groupe n’ait pas été défini) car le paramètre : Serveur web utilisateur/groupe (real, ‹ id › command) ne comporte aucune valeur, alors qu’en local l’utilisateur/groupe est « www-data:www-data »

image_web.php.png

image3.png

image4.png

Comment remédier au problème ? En relançant l’installation ?

Dolibarr donne (configuration infomaniak)
apache ??? (rien concernant la version)
OS : debian 4.9.0.6
PHP 7.0
MariaDB 5.6.35

configuration locale lors des test :
apache 2.4.25/debian
OS : debian 4.9.0.8
PHP 7.0
MariaDB 5.5.5-10.1.37

Après avoir activé la fonction exec() comme préconisé par l’hébergeur, l’erreur serveur web a disparue, voilà ce que donne l’id:

Serveur web utilisateur/groupe (real, ‹ id › command)uid=63837(uid63837) gid=10000(ldapusers) groups=10000(ldapusers)

par contre l’erreur dans le module « statistiques adhérents » est toujours là…

UP ?

J’ai procédé à une réinstallation, mais lors de la migration des bases le message d’erreur apparaît toujours:

bug_migration_base.png

D’après l’hébergeur ce n’est pas un problème de code Dolibarr ni de version de PHP, mais un problème de données dans la base (div/0)
Pourtant lors de l’installation en local, la migration de la base et les test sont tous OK !

Une idée ?

Bjr,

je continue mes recherches, mais sans succès…
l’erreur est générée par le fichier htdocs/core/class/stats.class.php => function_getAllByYear
j’ai vérifié, les 2 fichiers sont strictement identiques en local sur ma base de test et sur le serveur infomaniak. le problème vient donc du calcul des données. Ce que je ne comprends pas c’est le pourquoi, puisque les bases sont strictement identiques. En effet, après avoir ré-installé une copie de la V8.0.4 de Dolibarr pour test sur le serveur ( avec toujours le même message d’erreur lors de la migration de la base, alors que localement tout se passe normalement) j’ai 'injecté la base de donnée locale qui est OK, dans la base de test sur le serveur, et malgré cela l’erreur persiste.
Tout se passe comme si le serveur n’interprétait pas la fonction function_getAllByYear de la même manière que localement.
lignes concernées 389 et 391

function_getAllByYear.png

mes compétences en PHP sont trop limitées, quelqu’un peut m’aiguiller ?

A moins que le problème soit lié à la configuration du serveur: MariaDB notamment qui est dans une version supérieure…

config:
PHP 7.0.33 en local et PHP 7.0.32 sur le serveur
MariaDB 5.5.5-10.1.37 en local et MariaDB 5.6.35 sur le serveur

Bonjour,
$row->total et $row->avg doivent être nuls. Ce sont des résultats d’une requête SQL.
Active les log de Dolibarr depuis les modules.
Moi, j’y trouve cette requête :

2019-01-14 12:06:41 DEBUG 127.0.0.1 CommandeStats::_getAllByYear 2019-01-14 12:06:41 DEBUG 127.0.0.1 sql=SELECT date_format(c.date_commande,'%Y') as year, COUNT(*) as nb, SUM(c.total_ht) as total, AVG(total_ht) as avg FROM llx_commande as c WHERE c.fk_statut > 0 AND c.entity IN (1) GROUP BY year ORDER BY year DESC

@yves57
merci pour ta réponse et voici ce que donne dolibarr. log

sur le serveur:
AdherentStats::_getAllByYear
sql=SELECT date_format(p.dateadh,’%Y’) as year, count(*) as nb, sum(subscription) as total, avg(subscription) as avg FROM llx_subscription as p, llx_adherent as m WHERE m.statut != 0 AND p.fk_adherent = m.rowid AND m.entity IN (1) GROUP BY year ORDER BY year DESC

en localhost:
AdherentStats::_getAllByYear
sql=SELECT date_format(p.dateadh,’%Y’) as year, count(*) as nb, sum(subscription) as total, avg(subscription) as avg FROM llx_subscription as p, llx_adherent as m WHERE m.statut != 0 AND p.fk_adherent = m.rowid AND m.entity IN (1) GROUP BY year ORDER BY year DESC

je constate que m.statut !=0 et non >1 comme chez toi. Par contre je ne vois pas l’origine du problème, et notamment pourquoi l’interprétation des résultats est différente en local et sur le serveur, puisque à priori les bases (donc la valeur des champs) sont identiques et que les requêtes du fichier log sont strictement identiques… :angry:

La seule explication que je vois est que sur l’une des années, 2019 au hasard, le montant des « subscription » est nul.

Essai de désactiver/activer le module concerné

@yves57
j’ai balayé toutes les cotisations, pour commencer. Effectivement, pour un adhérent le champ ‹ libellé de cotisation › ,n’était pas renseigné, mails il ne s’agit pas d’un champ date. De plus après correction, le problème persiste et qui plus est le même oubli sur la base locale ne provoque pas l’erreur…

@wdammak
module adhérent désactivé et réactivé sans effet.

essai de vérifier la structure de ta base avec
/install/check.php?testget=ok

1 « J'aime »

@wdammak

merci pour la manip; tout c’est déroulé normalement et la base est Ok mais le warning au lancement des stats cotisations/adhérents demeure.
J’avais fait une sauvegarde de la base non compressée et téléchargé le fichier pour l’analyser, notamment ‹ llx_adherents › entre autres et je n’ai rien trouvé d’anormal dans les données…donc c’est toujours un mystère pour moi.

dans ce cas tu vas au fichier /htdocs/core/class/stats.class.php à la ligne 387

et tu remplaces les 5 lignes par ce code :

				if($i>0 && $row->nb>0) $result[$i-1]['nb_diff'] = ($result[$i-1]['nb'] - $row->nb) / $row->nb * 100;
				$result[$i]['total'] = $row->total;
				if($i>0 && $row->total>0) $result[$i-1]['total_diff'] = ($result[$i-1]['total'] - $row->total) / $row->total * 100;
				$result[$i]['avg'] = $row->avg;
				if($i>0 && $row->avg>0) $result[$i-1]['avg_diff'] = ($result[$i-1]['avg'] - $row->avg) / $row->avg * 100;
1 « J'aime »

@wdammak

Je suis frileux pour modifier le code en production, sachant que le même code ne produit pas d’erreur en local. Je pense à un problème de configuration du serveur. J’attends une réponse de mon hébergeur sur ce point.

vous pouvez faire une copie du fichier à mettre à coté
de toute façon il y a rien de spécial, juste s’assurer que le nombre de la division n’est pas zéro

1 « J'aime »

@wdammak

effectivement le message à disparu, Mais si je comprends le pourquoi (il ne peut plus y avoir de message concernant une div/0 puisque on ne prend en compte le résultat que si total et avg sont >0), comment se fait-il qu’avec le code original il n’y ai pas de ‹ warning › en local, lors de mes test. A moins, que le paramétrage en local fasse que mysql désactive les ‹ warnings ›, et que sur le serveur ce ne soit pas le cas.

Bref, j’ai encore appris quelque chose…

De toute façon c’est un bug à signaler car le code n’est pas correct!
if($i>0 && $row->total)
$row->total peut être définie mais sa valeur est 0
if($i>0 && $row->total>0)

@wdammak
Tu as peut être raison, mais dans ce cas en local j’aurais dû avoir le même message. Comme c’est un ‹ message d’attention › (warning’) non bloquant et que je suis quasi certain que dans le paramétrage des bases mysql/mariadb ont doit pouvoir activer ou désactiver les ‹ warnings ›, ceci expliquerai celà.

dans ton fichier conf/conf.php sur la production ajoute ces deux lignes :

ini_set(« display_errors »,0);
error_reporting(0);

remet l’ancien script et test

c’est bien ça, confirmé par la réponse de mon hébergeur:
« Cher client…Par expérience cela proviendrait plutôt de la configuration de l’affichage des warnings effectivement. »

En rétablissant le fichier original /htdocs/core/class/stats.class.php et en modifiant le conf.php de dolibarr avec ton code cela désactive bien les messages d’erreur.

merci encore !