prix spécifiques et règles de prix catalogue qui ne fonctionnent pas

[Tech-Nova]

Bonjour,

 

après une mise à jour sous la version 1.6.1.17, je rencontre le problème suivant :

1) il est impossible de supprimer des prix spécifiques qui avaient été mis avant. La poubelle fait bien disparaitre la ligne avec un message de succès, mais au rechargement de la page produit + onglet titre, on retrouve les bloc "prix spécifiques" exactement comme avant.

2) Les prix spécifiques qui sont affichés ne sont pas pris en compte

3) J'ai essayé en créant des règles de prix catalogue. On peut créer une règle. Je l'affecte à un groupe d'utilisateurs. OK. Mais si je veux rajouter une nouvelle condition (par exemple en croisant avec la catégorie "promo"), je retrouve ce même type de problème : cette nouvelle condition n'est pas sauvegardée lorsque je clique sur le bouton "enregistrer"

 

Est-ce que c'est un bug connu ? Est-ce que vous avez des pistes pour que je puisse débugger cela ?

 

J'ai bien regardé le code source,

Dans controllers\admin\AdminProductsController.php, fonction initProcess(), le commentaire juste avant

if (Tools::isSubmit('submitPricesModification')

est ..

// Product specific prices management NEVER USED

 

argh..

 

[Aletren]

fait un F12 dans l'onglet prix de la page produit au backoffice et regarde s'il ya un message d'erreur qui s'affiche dans la console du navigateur 

[doekia]

Peux-ton savoir en quelle version tu étais avant?

[Tech-Nova]

@Aletren : J'ai effectivement commencé par tester la console.

 

Le clic sur les corbeilles génèrent un appel du type index.php?controller=AdminProducts&id_product=62&action=deleteSpecificPrice&id_specific_price=141&token=1232&ajax=true, qui retourne un objet json {status:ok, message:"Suppression réussie"}

 

De toute manière cette suppression ne semble pas effective tout de suite. Peut-être à cause du bouton Annuler.. Mais le hic c'est que les boutons "Eregistrer' et "Enregistrer et rester" ne fonctionnent pas.

Je ne détecte aucune erreur javascript.

 

J'ai cherché dans les logs mysql, mais pour l'instant je n'ai rien trouvé. Je continue à piocher..

 

@doekie : je vais voir. Est-ce qu'il y a un moyen de le savoir dans le code source ? Je ne sais pas si j'ai accès à l'ancienne base de données.

Edited September 20, 2017 by Tech-Nova (see edit history)

[Aletren]

version prestashop  table ps_configuration et chercher la valeur "PS_INSTALL_VERSION" dans la colonne "name"

pense à vider le dossier cache/smarty/compile et cache/smarty/cache 

[Tech-Nova]

@doekie : according to setting.inc.php, the previous version was 1.6.1.1

Je ne pense pas que ça vienne de là.

 

Tiens, je cause franglais lol.

Je n'ai plus accès à Mysql, mais seulement aux anciens fichiers via ftp. Bon, je dois avoir un backup mysql sous le coude

Edited September 20, 2017 by Tech-Nova (see edit history)

[Tech-Nova]

Pour ce qui est des règles de prix catalogue, j'ai bien trouvé celle que j'avais créé dans ps_specific_price_rule.

J'ai aussi trouvé les trois essais pour ajouter des conditions dans les tables  ps_specific_price_rule_condition et  ps_specific_price_rule_condition_group.

Mais cela ne m'explique pas pourquoi ces conditions n'apparaissent pas dans le backoffice, sous le bloc principal de la réduction :/

J'ai fais l'essai en désactivant le cache smarty.

 

Je pense que c'est le même type de problème qui a pour effet de ne pas prendre en compte ces règles dans la partie publique.

[doekia]

Le code de la 1.6.1.1+ de cette partie est a quelques détails prés le même que celui de la 1.6.1.17. Donc ton problème est ailleurs

[Tech-Nova]

Le problème semble venir d'un cache de la base de données.

 

J'ai remarqué que dans la page produit | onglet prix, les attributs id_specific_price des liens liés aux corbeille ne sont pas bons.

 

La fonction _displaySpecificPriceModificationForm() de controllers/admin/AdminProductsController.php, est chargée l'alimenter les données pour le formulaire.

Ces données sont récupérées via un appel  à SpecificPrice::getByProductId((int)$obj->id);

Mais la valeur récupérée est un tableau qui contient des id_specific_price qui n'existent plus

 

Côté SpecificPrice::getByProductId(), j'ai vérifié que l'objet Db::getInstance(_PS_USE_SQL_SLAVE_) est bon (attributs user, password, database corrects)

Ce uqi me fait tilter est d'un de ses attributs est is_cache_enabled, qui est à 1.

Et je suis quasi certain que le problème vient de là. Car si je lance manuellement la requête mysql permettant de récupérer la liste, j'obtiens les bons identifiants.

 

Du coup, je change la valeur via le fichier de config

define('_PS_CACHING_SYSTEM_', 'CacheApc');
define('_PS_CACHE_ENABLED_', '0');

 

Et là le fonctionnement dans le backoffice redevient normal !!

 

Comment est-il possible que le cache du résultat de la requête soit resté alors que les données avaient changé ?

Est-ce que ce comportement a été rencontré ailleurs ?

 

Je suis en PHP 5.6.16

 

[root@prestashop]# php --info |grep apc
Additional .ini files parsed => /etc/php.d/apcu.ini,
apc
apcu
MMAP File Mask => /tmp/apc.XXXXXX
apc.coredump_unmap => Off => Off
apc.enable_cli => Off => Off
apc.enabled => On => On
apc.entries_hint => 4096 => 4096
apc.gc_ttl => 3600 => 3600
apc.mmap_file_mask => /tmp/apc.XXXXXX => /tmp/apc.XXXXXX
apc.preload_path => no value => no value
apc.rfc1867 => Off => Off
apc.rfc1867_freq => 0 => 0
apc.rfc1867_name => APC_UPLOAD_PROGRESS => APC_UPLOAD_PROGRESS
apc.rfc1867_prefix => upload_ => upload_
apc.rfc1867_ttl => 3600 => 3600
apc.serializer => php => php
apc.shm_segments => 1 => 1
apc.shm_size => 32M => 32M
apc.slam_defense => On => On
apc.smart => 0 => 0
apc.ttl => 0 => 0
apc.use_request_time => On => On
apc.writable => /tmp => /tmp

[doekia]

Toute la section des cache externe (apc, memcached, filesystem, ... ) est notoirement buggué sans oublier qu'elle est totalement inutile sauf pour lancer de la poudre aux yeux dans les démo marketing.

Edited September 21, 2017 by doekia (see edit history)

[Tech-Nova]

Pour le cache des requêtes, c'est bon à savoir

 

Maintenant que j'ai trouvé pourquoi ça buggait sévère dans le backoffice, j'ai compris en quelques logs d'où vient le calcul du prix qui est affiché sur le site.

 

Prestashop teste si la signature des arguments de SpecificPrice::getSpecificPrice() est trouvée dans le tableau retourné par SpecificPrice::$_specificPriceCache()

 

Mon utilisateur était dans les groupes client (3) et adhérents(4) - avec 3 comme groupe par défaut.

Le prix spécifique portait sur le produit et le groupe des adhérents avec une réduction.

 

La signature des arguments de SpecificPrice::getSpecificPrice() (exemple "73-1-1-8-3-1-0-0-10215-0") ne correspondait pas au groupe des adhérents. 

C'est le prix correspondant à ce groupe (donc le prix de base) qui était affiché et appliqué, et non pas le prix correspondant au second groupe.

 

Pour résoudre le problème, il m'a suffit de mettre le groupe par défaut de l'utilisateur à 4.

A ce moment la clé calculée avec les arguments de SpecificPrice::getSpecificPrice() devient "73-1-1-8-4-1-0-0-10215-0" et est une clé du tableau retourné par  SpecificPrice::$_specificPriceCache()

Du coup, le prix spécifique est pris en compte.

 

La subtilité entre groupe et groupe par défaut me semble étrange - mais c'est probablement un comportement normal.

 

Hop, je marque comme résolu.

 

.Gilles

[robin71]

Hello,

Je remonte le sujet, voici ce qui ce passe sur mon PS;1.6.1.15 voir image jointe, peut être une idée,e suis à votre écoute et merci de votre aide.

Cdt

Robin

Capture-1-1.pdf