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.