edit : le problème ne provient pas de la version de php, mais de la version de la librairie utilisée par le core. Toutes les nouvelles installations pourraient donc avoir le problème. problème que je rencontre sous php8 (debian12) et non en php7 (debian11).
devant le nombre grandissant de post où l’on voit des utilisateurs indiquant migrer sous debian 12, je me permets un petit warning …
sur un scénario, je choisis le mode « programmé », puis j’utilise l’assistant cron pour définir une exécution unique :
je fais donc les choix :
une seule fois
ma date (volontairement dans le passé ici pour l’exemple) → le 11 Juin 2024 à 16h00
c’est aussi la version que j’ai sur ma prod et ma dev principale
le résultat au final n’est pas vraiment un « lancement uniquement » non plus puisque les mêmes inputs donnent déjà actuellement deux dates différentes :
bon ya 6 ans de décalage, donc entre temps mon scénario aura surement été mis à la poubelle
par contre en restant sur ma dev principale (donc php7) et en faisant un composer update → on passe bien sur la derniere version du package 3.3.3 ( → version que j’ai bien eu automatiquement lors de l’install « standard » sur D12/php8 !!)
et sans rien changer, mais simplement en faisant un « sauvegarder » sur le scénario, on retombe bien avec mes premiers screenshots (enfin presque puisque 16h est déjà passé) :
Pour moi ce comportement c’est « normale », CronTab n’accepte pas une année, donc le core le supprime avec checkAndFixCron tu as donc un cronTab 00 16 11 06 2 donc la prochaine fois qu’on sera le 11 juin un mardi c’est bien en 2030.
La par contre j’ai pas la cause, mais la lib est forcémément en cause.
Il semble que la lib lors du composer, soit effectivement la dernière.
Et elle ne semble pas prête pour php > 8.0, il y a d’ailleurs un PR sur celle-ci pour diminuer le require en 8.0.
Il y a donc bien un soucis avec les Cron, pour les fresh install…
@tomitomas a fait pas mal de test pour confirmer ce bug, il donnera sans doute plus d’informations
Justement non, j’espère qu’il vont trouver une solution pour rendre compatible > 8.0, car le PR actuel c’est juste pour diminuer le require a 8.0, donc incompatible avec Deb12.
Je craint quon soit obliger de fixer la lib en 2.3.1, en attendant.
J’ai légèrement modifié mon post initial, puisque le problème ne vient pas de la version de php, mais de la version de la librairie « dragonmantank/cron-expression » utilisée.
A date une fresh install, partira sur la dernière version de la librairie → 3.3.3
alors que les anciennes versions seront (la plupart ?) en → 2.3.1
La gestion de la position « année » a été dépréciée depuis plusieurs versions (et là c’est un peu le bordel car je n’ai pas réussi à trouver laquelle).
Toujours est il qu’avec le core Jeedom et la lib en 2.3.1 => ca « fonctionne » ( modulo le fait qu’on soit quand même à +6ans sur la "prochaine exécution)
Si on passe sur la version toute de suite supérieure 3.0.0 ==> ca ne fonctionne plus et on repasse à la prochaine date à +7 jours → et là c’est problématique !
La PR cité par @Phpvarious ne changera rien, au contraire elle limite l’utilisation à php8.0, mais ca ne change pas le soucis de gestion de l’année. (en plus de restreindre l’utilisation de D12)
Le dev dit à plusieurs reprises dans différents issue qu’il a arreté de gérer l’année pour être plus aligné avec les standard de cron et qu’il ne reviendrait pas dessus.
Deprecated CronExpression::YEAR as a formality, the functionality is already removed (#87)
se limiter à la version 2.3.1 est dommage car les nouvelles versions apportent aussi pleins de petite choses sympathiques !
du coup attendre pour une maj de la lib n’aura que peu d’effet pour moi.
il faudrait plutôt que le core gère les cas où il y a cette 5e position ‹ année › → si c’est le cas, alors vérifier que la date existe et est cohérente et enregistrer cette uniquement date comme précédente/suivante, sans utiliser la class cronExpression.
Bonjour,
Ok merci pour le retour, quand on lancera jeedom 4.5 une revu de composer va etre faite on passera donc a la version 3.X de la lib et jeedom ne supportera plus l’année (a voir comment gerer mais je vois pas comment le faire en interne c’est beaucoup trop lourd).
tu peux juste remplacer le « In php8 » par « From v3.3.0 » du titre pour etre parfait
puisque le problème ne vient pas de la version de php8, et est déjà reproductible en D11/php7
tomtom@debian11:~$ wget https://raw.githubusercontent.com/jeedom/core/alpha/install/install.sh
tomtom@debian11:~$ chmod +x install.sh
tomtom@debian11:~$ sudo ./install.sh version=alpha
Welcome to Jeedom installer
Jeedom version : V4-stable <<<<<-------- ??????
Web folder : /var/www/html
Installation type : standard
Starting installation ...
pourquoi Jeedom version : V4-stable alors que je demande l’install en alpha !?
EDIT :
je m’auto réponds sur ce point, la bonne syntaxe c’est : ./install.sh -v alpha
et non pas ./install.sh version=alpha comme indiqué dans la doc d’install
→ dernière ligne à modifier : Documentation Jeedom
2nd point
FYI : par contre j’ai un msg d’erreur au 1er lancement pour un plugin « introuvable » - fresh install et je ne connais pas ce plugin de base
,
