Bonjour @damienfr44 et @nicolas_fr,
Le problème ici est lié à la façon dont le panier est initialisé et validé dans un contexte de contrôleur frontal, surtout quand il y a une tentative de basculer entre un id_cart fourni et le $this->context->cart. Dans le code original, si new Cart($idCart) échoue (par exemple, si le panier n'existe pas ou n'est pas accessible), il tente de revenir à $this->context->cart. Cependant, si ce dernier n'est pas non plus un objet Cart valide dans ce contexte spécifique (par exemple, si aucun panier n'est attaché à la session actuelle ou si la session de l'employé n'a pas un panier frontal associé), alors Validate::isLoadedObject échoue.
Pour rendre cela plus robuste, il faut s'assurer que le panier est toujours un objet Cart chargé et validé. Voici une approche plus explicite pour shipmethodrules/controllers/front/simulate.php :
function postProcess()
{
if (!Validate::isLoadedObject($this->context->employee)) {
$this->ajaxDie(json_encode(['success' => false, 'error' => 'Unauthorized']));
}
$idCart = (int) Tools::getValue('id_cart');
$cart = new Cart($idCart); // Tente d'abord de charger le panier par l'ID
if (!Validate::isLoadedObject($cart)) {
$cart = $this->context->cart; // Sinon, utilise le panier du contexte
if (!Validate::isLoadedObject($cart)) {
Cette modification ajoute une vérification explicite pour le panier du contexte après l'échec de l'ID fourni, et gère le cas où aucun des deux n'est valide. De plus, pour des besoins de gestion de règles de livraison complexes et pour utiliser une solution pour set conditional carrier availability rules de manière propre et maintenable, je recommande souvent l'utilisation d'un module dédié plutôt que des modifications directes dans le code des modules tiers, surtout pour les mises à jour.