champ perso limités par un autre champ

-- HikaShop version -- : 4.2

Bonjour

J'ai un problème sur l'affichage des champs perso (qui ne vient pas de mon overrides)


chaussures =0
accessoires = 1

sur les produits de types accessoires = 1 je ne veux pas montrer des champs comme hauteur de talon i le produit est du genre accessoire, or dans certain cas ca marche et d'autres non


merci pour l'aide

Bonjour,

Cela ne serait pas car vous avez quelque chose d'entré dans ces champs alors que vous n'avez pas le champs dans le formulaire du backend pour remplir le champs ?
L'affichage sur le frontend prend en compte les champs uniquement s'ils sont rempli et que leur affichage sur le frontend est activé. L'option "affichage limité à" n'est pas pris en compte mais cela ne devrait normalement rien changer vu que vous n'êtes pas sensé avec quelque chose dans le champs vu qu'il ne s'affiche pas dans le backend.

oui ca doit etre ca ! j'avais modifie par SQL pour avoir une valeur par defaut dans les tables

merci

il y a quand meme un gros problème
quand j'ai un champ perso de type liste simple il garde une valeur par default et donc n'importe quel nouveau produit aura cette valeur par default
car pour pouvoir créer un nouveau produit dont les champs perso ne s'affichent pas que si son product_genre = 1 il faut d'abord l'enregistrer
et donc le champ qui ne devrait pas être là est rempli a l'enregistrement

l'ideal serait de pouvoir creer des produis d'un certain genre et non de creer uniquement un nouveau produit
de meme pour les champs perso qui sont tous dans la table product , j'ai 10 champs perso pour les chaussures qui ne servent qu'aux chaussures , si j'ai 20 types de produits différents avec chacun 10 champs perso ca fait 100 champs dont 90 sont inutiles pour la plupart des cas

virtuemart dans ses premieres versions avait deja une table séparée pour les champs perso

Bonjour,

Je n'arrive pas à reproduire ce dont vous parlez de mon coté. Lorsque je sauvegarde un produit, si le champs enfant n'est pas affiché, alors il n'est pas sauvegardé, même avec une valeur par défaut, et du coup la valeur du champs enfant reste à NULL dans la base de données, et le champs n'est pas affiché sur le frontend.
Etes-vous sûr d'avoir ce soucis ?

Concernant la localisation des champs dans une autre table, comme le fait VM et Joomla, cela a des avantages et des inconvénients.
L'avantage majeur de faire ce changement serait de ne pas avoir des colonnes qui ne servent qu'à quelques produits dans la table hikashop_product et donc cela réduirait la taille de la table. Cela pourrait faire que certaines requêtes soient un peu plus rapides. Mais bon, je trouve que l'avantage n'est pas fou (et je n'en vois pas d'autre ?)... surtout comparé aux inconvénients:
- chaque filtre sur un champs personnalisé rajouterait un LEFT JOIN sur cette nouvelle table. Cela pourrait lourdement ralentir les requêtes de chargement des produits dans les listings, surtout lors de l'utilisation de plusieurs filtres en même temps.
- la traduction des champs personnalisés test, textarea et WYSIWYG avec Falang serait impossible (est plus complexe à mettre en place avec un autre système de traduction dans le future)
- le chargement des données des produits serait plus complexe car il faudrait faire des requêtes additionnelles.

J'en oubli surement, mais déjà rien qu'en prenant tout cela en compte je ne vois pas l'intérêt de changer cela, d'autant plus que cela demanderait pas mal de boulot pour modifier tout cela, et qu'il serait plus intéressant de travailler sur d'autres améliorations qui apporteraient vraiment quelque chose.