Méthode import de la class eqLogic

Phpvarious · Août 7, 2026, 6:01

Bonsoir a tous,

Petite réflexion sur cette méthode de la class EqLogic,

Chaque appel de cette méthode provoque un postSave, devrait-il pas y avoir un argument supplémentaire ($_direct = false) pour permettre de ne pas déclencher le PostSave ?

	public function import($_configuration, $_dontRemove = false, $_direct = false) {
		.....
		.....
		$this->save($_direct);
	}

source :

github.com/jeedom/core

core/class/eqLogic.class.php

develop


      
          					if ($link_action == $eqLogic_cmd->getName()) {
          						$cmd = cmd::byId($cmd_id);
          						if (is_object($cmd)) {
          							$cmd->setConfiguration('updateCmdId', $eqLogic_cmd->getId());
          							$cmd->save();
          						}
          					}
          				}
          			}
          		}
          		$this->save();
          	}
          
          	public function export($_withCmd = true) {
          		$eqLogic = clone $this;
          		$eqLogic->setId('');
          		$eqLogic->setLogicalId('');
          		$eqLogic->setObject_id('');
          		$eqLogic->setIsEnable('');
          		$eqLogic->setIsVisible('');
          		$eqLogic->setTimeout('');

Mips · Août 7, 2026, 6:56

Salut,

C’est dans une coin de ma tête depuis presque une mois ayant corrigé 2 plugins qui bouclaient lors du save (dont caméra)… je pense que cela devrait toujours être un save(true); c’est beaucoup trop dangereux comme méthode.

Phpvarious · Août 7, 2026, 7:11

C’est justement en préparant une évolution au plugin caméra que je me suis aperçu de ce postSave en doublon.

Loic · Août 8, 2026, 11:20

Bonjour

Oui et non faut laisser le choix certain plugin peuvent avoir besoin de faire des actions après la création d’un équipement. Après il pourrait le gérer lui même après l’importation donc je pense faut laisser le choix.

Phpvarious · Août 8, 2026, 12:58

Bonjour Loic,

Ok, pour éviter de casser certains plugins, il faudrait pas changer le comportement actuel, il faut donc initier l’attribut $_direct par défaut a true

	public function import($_configuration, $_dontRemove = false, $_direct = true) {
		.....
		.....
		$this->save($_direct);
	}

Aurelien · Août 8, 2026, 1:18

Salut @Phpvarious,

Y’a la même chose au niveau du save des commandes dans ce bloc Potentiellement le même impact dans un sens ou dans l’autre que le save eqLogic. Cette méthode est exclusivement utilisée par les plugins, difficile d’y toucher à mon sens même si en théorie le point que tu lèves semble tout à fait justifié. Même juste modifier la signature de la fonction pourrait casser une éventuelle surcharge par un plugin.

Bref tout ça pour dire qu’il serait peut être préférable d’ouvrir une issue à ce sujet plutôt que modifier directement, tu en penses quoi ?

Phpvarious · Août 8, 2026, 1:38

Hello,

Je pense pas que le save des commandes soit impactant.

Je te fais confiance, je n’est pas les connaissances nécessaires, je pensais pas que cela pouvait casser une éventuelle surcharge d’un plugin. Je pensais que chaque méthodes (surcharge ou parent) pouvaient avoir ces propres attributs.

Pas de soucis pour moi, c’était juste pour avoir votre avis.

Edit :

J’aurai appris une chose aujourd’hui, merci

Pour qu’une redéfinition fonctionne et ne lève pas d’erreur (Fatal Error), vous devez respecter les règles suivantes :

Même signature : La méthode enfant doit avoir exactement le même nom et les mêmes arguments (nombre et types) que la méthode parente.

Aurelien · Août 8, 2026, 1:47

Pourtant c’est exactement le même principe que pour les eqLogic, ça va vraiment dépendre de chaque plugin. En théorie y’a plus de commandes donc plus de pre/post appelés potentiellement. Les impacts sont multiples et totalement dépendants de chaque plugin c’est pour ça qu’il est difficile de savoir quelle voie prendre ici (me concernant en tout cas).

Phpvarious · Août 8, 2026, 2:13

Le dev en utilisant la méthode import a de risque que de multiplier les pre/post de la class Cmd.
Je comprend très bien ton point de vue, coté pratique il devrait tout autant avoir le choix du déclenchement des pre/post.

en revanche coté eqLogic, la méthode ne peut-être utilisé que dans le PostSave, c’est donc dommage que d’un postSave on déclenche un import pour ainsi redéclencher un postSave.

Mips · Août 8, 2026, 2:53

Selon moi le risque est réel pour eqlogic car la probabilité de boucle est très importante (je suis tombé sur 2 cas qui était là depuis des années récemment)
Pour les commandes il y a risque d’appeller 2 fois sans la vouloir le postSave mais pas de boucler.

Ca non par contre, l’import peut être appelé par une méthode faisant une découverte d’équipement, le crée (juste un new myEqlogic()) et ensuite appel l’import dessus pour faire le setup.
Du coup dans ce cas là, il faut probablement faire le postSave etc

Perso, vu que ce save() est encapsule dans le import() il faut au minimum avoir le paramètre $direct qui remonte sur la méthode import() et je trouverais ca moins risqué qu’il soit par défaut à true mais ca serait un breaking change pour les devs tiers (à communiquer et à passer sur un core v5)
L’alternative pour ne pas avoir d’impact c’est de l’avoir par défaut à false, on aurait le même comportement qu’aujourd’hui.
Mais l’impact dont on parle ici pourrait être plus bénéfique que néfaste car si une requête boucle jusqu’au timeout php comme les cas que j’ai vu, ca fait mal à la box… pour peu qu’on clic plusieurs fois sur save parce qu’on ne comprend pas pourquoi ca ne fonctionne pas, la charge explose, c’est du vécu

Mais on peut documenter tout ca et statuer dans une issue, c’est le mieux

Phpvarious · Août 8, 2026, 2:59

Je suis tout a fait d’accord avec toi, ma réflexion ce portait sur les méthodes parent existantes dans la class eqLogic sans pour autant monter d’autres méthodes (comme le plugin caméra par exemple)

Phpvarious · Août 8, 2026, 3:08

alternative pour éviter de modifier la signature, on pourrait éventuellement avoir cette notion de save direct dans $_configuration utilisé par l’import ?

exemple :

{
  "saveDirect": "1",
  "configuration": {},
  "commands": [
    {
      "eqType": "camera",
      "name": "Relai 1",
      "type": "action",
      "subType": "other",
      "isHistorized": "0",
      
      "configuration": {
        "request": "\/cgi-bin\/remctrl.sh?id=relay1"
      },
      "isVisible": "1"
    },
    {
      "eqType": "camera",
      "name": "Relai 2",
      "type": "action",
      "subType": "other",
      "isHistorized": "0",
      
      "configuration": {
        "request": "\/cgi-bin\/remctrl.sh?id=relay2"
      },
      "isVisible": "1"
    }
  ]
}

Phpvarious · Août 8, 2026, 3:11

Je pense que c’est la meilleure solution

Mips · Août 8, 2026, 3:17

Franchement ?

Phpvarious · Août 8, 2026, 3:18

Ouais je suis de ton avis aussi , d’où mon message précédent.

Aurelien · Août 8, 2026, 3:23

Je suis à fond dans un autre sujet en ce moment donc j’ai pas vraiment regardé ce que fait le code concerné en détail. J’ai sûrement pris un raccourci concernant les commandes, l’idée était surtout de pointer qu’elles ont le même behavior même en partie. Je n’ai pas vraiment pris en compte le cas du loop postSave eqLogic dans mes réponses effectivement mais quoi qu’il en soit on semble tous d’accord que ce code doit être analysé en détail, optimisé le cas échéant et bénéficier d’une communication auprès des devs en cas de changement

Phpvarious · Août 8, 2026, 4:51

J’ai finalement ouvert une issue :

github.com/jeedom/core

Risk of infinite postSave loops in eqLogic class import() method

ouvert 04:50PM - 08 Aug 26 UTC

Phpvarious

### Lien vers la discussion communautaire Cette demande fait suite à un échange …sur le salon des développeurs : https://community.jeedom.com/t/methode-import-de-la-class-eqlogic/150289 ### Description du problème Lors de l'utilisation de la méthode `import()` de la classe `eqLogic`, un appel systématique à `$this->save()` est réalisé en fin de traitement. Cet appel déclenche l'ensemble du cycle de sauvegarde, y compris les hooks `preSave()` et `postSave()`. Dans plusieurs cas de figure (notamment lorsqu'un plugin utilise `import()` à l'intérieur de son propre cycle de sauvegarde), cela génère des doublons d'appels, voire des **boucles infinies de sauvegarde** qui s'exécutent jusqu'au timeout PHP. ### Analyse technique Dans `core/class/eqLogic.class.php`, la méthode est définie ainsi : ```php public function import($_configuration, $_dontRemove = false) { // ... traitement ... $this->save(); } ``` L'impossibilité de passer l'argument `$direct = true` à la méthode `save()` empêche le développeur de bypasser les hooks de sauvegarde lorsque la situation l'exige. Lors de l'utilisation de la méthode `import()` de la classe `eqLogic`, un appel systématique à `$this->save()` est effectué à la fin du processus. Cet appel déclenche l'intégralité du cycle de sauvegarde, y compris les hooks `preSave()` et `postSave()`. ### Piste d'amélioration proposée (Issue de la discussion) Pour résoudre ce problème sans casser le comportement actuel des plugins existants, il est proposé d'ajouter l'argument `$_direct` à la signature de la méthode `import()`, avec une valeur par défaut à `false` : ```php public function import($_configuration, $_dontRemove = false, $_direct = false) { // ... traitement ... $this->save($_direct); } ``` ### Impact et Breaking Change potentiel * **Comportement :** Aucun impact négatif direct pour les utilisateurs ou les plugins existants si l'argument reste à `false` par défaut. * **Compatibilité PHP (Surcharge) :** Modifier la signature d'une méthode parente impose que les classes enfants respectent la même signature (PHP 8+). Si un plugin a surchargé la fonction `import()` dans sa propre classe sans ce troisième argument, cela lèvera une `Fatal Error`. Au vu de ce risque de *breaking change* sur la signature pour les développeurs tiers, cette modification devrait idéalement être planifiée pour une future version majeure (Core V5) ou faire l'objet d'une communication dédiée auprès des développeurs si elle est intégrée à la branche `develop`.

system · Août 9, 2026, 4:52

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.