Bonjour @juliestore et @clement_hub27,
@clement_hub27 a mis le doigt sur le problème. L'implémentation actuelle de getEngine() crée une instance ShipmethodrulesEngine une seule fois par instance de module. Si votre script (synchronisation ERP, par exemple) manipule le contexte de la boutique (Context::getContext()->shop->id) et appelle getEngine() plusieurs fois, le moteur retourné sera toujours celui créé avec le premier contexte, et non le contexte actuel.
Pour corriger cela, la solution la plus simple, bien que potentiellement un peu moins performante si getEngine() est appelé des milliers de fois (ce qui est rare pour des règles de livraison), est de toujours instancier un nouveau moteur, ou du moins de le faire si le contexte de la boutique a changé. Étant donné la simplicité du code, on peut forcer une nouvelle instance à chaque appel.
Voici une modification directe du snippet dans shipmethodrules/shipmethodrules.php:
function getEngine()
{
// Instancier toujours une nouvelle version du moteur
// pour s'assurer qu'il utilise le contexte actuel du module.
// Cela évite les problèmes de contexte obsolète.
$this->engine = new ShipmethodrulesEngine($this);
return $this->engine;
}
En supprimant la condition if (!$this->engine), vous garantissez qu'à chaque appel de getEngine(), une nouvelle instance du moteur est créée, et celle-ci recevra le $this du module qui, à ce moment-là, devrait refléter le contexte de boutique actif. Pour des solutions plus robustes et maintenables, surtout en multi-boutique, il est souvent plus sûr d' utiliser une solution pour hide express carriers for bulky product categories qui gère ces aspects de contexte de manière plus granulaire et optimisée.