Lien HTML sur un produit dans un article

-- HikaShop version -- : HikaShop Business: 2.2.1
-- Joomla version -- : Joomla! 2.5.14
Bonjour d'un débutant
Dans mon site qui fonctionnera bientôt sous Hikashop, j'ai de nombreuses références à mes produits dans des pages d'article et j'ai construit une conversion de ces liens pour traduire les pages de mon ancien site en un texte HTML qui fonctionne en tant qu'article Joomla.
J'ai vu dans Hikashop la commande "Lien HTML ajouter au panier".
J'ai besoin de quelque chose de similaire pour non pas ajouter au panier, mais pour afficher la page du produit comme si l'utilisateur l'avait sélectionné par l'arborescence de la boutique.
Une idée ?

Bonjour,

Le lien dépendra de vos menus. Le plus simple pour savoir qu'elle allure aura votre lien, est de créer un menu de listing de produits qui va lister tous vos produits, puis à partir de ce menu visualiser une page produit.
C'est là que vous verrez à quoi ressemble l'url, ensuite il suffit d'adapter cette url avec le bon nom du produit.

Vous pouvez cacher ce menu, mais il ne faut pas le dépublier, sinon vos liens ne fonctionneront plus.

Merci et d'accord
C'est presque ce que je voulais faire, mais pas tout à fait...
1.
Je découvre que si la fenêtre Hikashop listant les produits est assez large, la colonne ID finit par apparaître, ce qui me permet enfin de connaître l'ID d'un produit donné.
Pour ma conversion, j'utilise donc les liens HTML de la forme :

http://www.apogee-vapeur.ch/nouveau/index.php?option=com_hikashop&ctrl=product&task=show&cid=699

Merci, c'est dommage mais clair : on n'est pas en programmation orientée objet !
Actuellement, l'importation des produits a été faite en une fois.
Imaginons que les méta-produits soient définis normalement en tant que produits avec leurs caractéristiques.
Est-il possible d'importer des variantes en seconde étape, en leur associant proprement leur produit parent par son ID et des valeurs pour les caractéristiques ?
Pour moi, cela reviendrait au même et me dispenserait de beaucoup de travail d'édition.
L'affichage des variantes en table est en effet une bonne aide, mais ne permet pas l'affectation d'un parent, et sauf erreur l'identité du parent n'est même pas visible...
Il est évident pour moi que l'affectation de plusieurs caractéristiques à un produit conduit à une combinatoire de variantes qu'il faut gérer, et que deux variantes distinctes ne doivent pas avoir la même combinaison de valeurs dans leurs caractéristiques.
L'affectation de caractéristiques à un méta-produit doit créer les variantes configurées, et toute importation de variantes doit se contenter de remplacer ou mettre à jour les enregistrements existants.
Ainsi, on devrait éviter de tout casser...

Alors la vie est belle : si le product_code dispense donc de connaître le product_id, c'est parfait !
Peut-on dire de même que le nom d'une variante permet sa sélection sans connaître son ID ?
Merci d'avance

Bonjour,

Le code d'une variante oui, mais pas son nom.
Un nom peut être dupliqué, le code lui est unique.

D'accord, donc on doit utiliser l'ID et pas le nom.
Je vais essayer sur une base sauvegardée :
- export d'un produit sans caractéristique et du même produit avec caractéristique pour voir la différence de champs,
- création externe des méta-produits avec une caractéristique instanciée,
- transformation externe des produits actuels en variantes de ces méta-produits,
- importation des méta-produits,
- réimportation des produits transformés en variantes.
Souhaitez-moi bonne chance...

Je suis parvenu, avec un programme de mon cru, à lire la table des produits exportée par Hikashop, à la manipuler et à la réimporter dans Hikashop.
1. Erreur à l'importation
Quand je tente d'importer cette table, modifiée ou non, le backend me signale une erreur : la ligne de syntaxe des champs comporte des entrées non prévues.
Je n'en suis pas surpris puisque les deux derniers champs décrivent les caractéristiques et d'autres champs créés par la requête décrivent les associations du produit à d'autres tables.
Ce message d'erreur pourrait être évité si l'import reconnaîssait sa propre syntaxe...
2. Avertissements à l'importation
Les enregistrements du début, qui contiennent les catégories et qui sont découverts par la lecture, génèrent des avertissements car ils ne sont pas reconnus comme des produits (heureusement !).
Cet avertissement pourrait être évité si les catégories étaient reconnues comme des produits particuliers : il y a déjà les types "main" et "variant", il suffirait d'en faire des enregistrements de produits de type "category" et d'enregistrer ce type, qu'il suffit alors de détecter à la relecture.
Ceci permettrait d'ailleurs de restaurer une arborescence quelconque de catégorie pour autant qu'on sache manipuler les tableaux d'indices de la table, ce qui est mon cas.
3. Heureusement, ça marche quand même
Les catégories sont relues et la structure est rétablie, la séquence que j'édite avec mon programme est presque restaurée par l'ordre de recréation que je peux manipuler de mon côté.
Presque, car dans la séquence manipulée, un indice est mal reconstruit : l'avant dernière catégorie fille d'une catégorie à séquence modifiée passe en premier !
Pas grave, ce sont quelques clics dans le backend.
4. Encore un peu de travail
Les produits variants sont reconstruits et les variantes leurs sont bien réassociées.
Me reste à manipuler les ID avec des pincettes (unicité) et à combiner deux produits sous forme de variantes d'un troisième à recréer par clonage prudent du premier sélectionné, cela ne va plus tarder.

5.
J'oubliais : en réimportant les produits, faut-il vraiment respecter la syntaxe de l'export ?
Par exemple, en ne réimportant pas les catégories, j'ai évité d'écraser les images et textes qui leur sont associés.
Je peux supprimer tous les produits d'un coup depuis le back-end en passant par la liste depuis la racine, ainsi je sais qu'il n'y aura pas d'erreur à la réimportation avec les ID que j'aurai manipulés...
Est-ce que ce genre de manipulations est documenté quelque part ?
Enfin bref, je me sens un peu moins perdu...

Pour l'instant cela ne marche pas...
Je constate que les liens HTML dans les champs de description peuvent contenir deux guillemets consécutifs.
Je constate que les descriptions peuvent contenir des <CR>.
Je corrige les deux problèmes par mon code et réinjecte une table propre, mais rien n'y fait : pas moyen d'importer des produits !

Bon... après un mois de bagarre, j'ai pu transformer le HTML de mes 700 produits et 200 articles pour qu'enfin l'import CSV soit possible.
J'ai pu transformer comme je le désirais la plupart de mes produits en variantes de produits génériques.
Je considère ce sujet clos plutôt que résolu, mais évidemment d'autres problèmes sont apparus, pour lesquels je vais ouvrir d'autres sujets.