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 : Ce lien aboutit à une variante d'un produit.
2.
D'autre part, j'ai vu une différence entre produits et variantes.
Beaucoup de mes produits doivent être proposés en deux variantes.
J'ai donc trois objets à gérer, les trois étant de la classe Produit :
- Un méta-produit [A ou B] qu'on ne peut pas acheter (choix non effectué entre les deux variantes) et n'a pas de stock
- - Une variante A qu'on peut acheter, qui a un stock
- - Une variante B qu'on peut acheter, qui a un autre stock
Je trouve dommage que l'explorateur ne liste que la structure jusqu'aux catégories, sans afficher les noeuds de type méta-produit puisqu'on pourrait alors naviguer jusqu'à la liste des variantes d'un produit sans passer par une édition différente (bouton Gérer les variantes).
Un méta-produit se comporte en effet beaucoup comme une catégorie ET comme un produit, non ?
S'y ajoute la notion d'héritage de valeurs par défaut.
3.
Durant ma conversion, j'importe des produits en CSV et je vais ajouter les méta-produits.
Si un produit pouvait changer de parent, je pourrais transformer ce produit A ou B en variante du nouveau méta-produit [A ou B].
Le plus simple serait de pouvoir changer parent : méta-produit [A ou B] prend la catégorie de A et B, variantes A et B deviennent dérivés du méta-produit.
Mais je ne vois pas de commande pour changer le parent...
Une idée ?

Vous n'avez pas besoin de passer par le bouton gérer les variantes. Vous pouvez changez le mode d'affichage du listing pour afficher que les variantes dans le listing de produits du back end.

Il n'est pas possible d'avoir plusieurs niveaux de "méta produits". Le système a été fait fait pour gérer des variantes et des produits, et pas autre chose. Si vous mettez un parent à un produit principal, cela va soit être ignoré, soit casser quelque chose vu que les produits ne sont pas sensés avoir de parent.

Merci, c'est dommage mais clair : on n'est pas en programmation orientée objet ! :lol:
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...

Bonsoir,

Au niveau de l'importation, il est tout à fait possible d'importer des variantes en spécifiant le "product_parent_id" qui sera soit le product_id, soit le product_code (étant une donnée unique, s'il s'agit d'un texte HikaShop ira récupérer le product_id à partir du product_code).

Cordialement,

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 !
:pinch:

Bonjour,

1. Les caractéristiques doivent être pré créées dans la base de données (table hikashop_characteristic). Sinon le système d'import ne sais pas si c'est une colonne que vous voulez ignorer, une colonne de champs personnalisé, ou une colonne de caractéristique. Du coup il ignore la colonne et affiche cette erreur. Et si le système d'import ne trouver aucune caractéristique pour les variantes, et bien du coup cela ne se passe pas bien...votre soucis est surement là.

2. Oui en effet. Disons que vous pouvez tout simplement ignorer le message.

3. Vous avez la colonne categories_ordering pour définir l'ordering des catégories dans le CSV.

5. L'export fourni toutes les colonnes possible, mais en effet, si vous ne voulez pas écraser les catégories, autant ne pas les spécifier au début du fichier et simplement les "pointer" dans la colonnes "categories" des produits.
La suppression des produits est possible oui mais seulement 500 par 500 (pour éviter les crashs de PHP). Si vous en avez beaucoup il est plus simple de juste vider les tables hikashop_product hikashop_product_category hikashop_price hikashop_variant et hikashop_product_related

6. Ah oui il faut faire attention avec les descriptions car il faut que ca reste un CSV valide. Sinon le système n'arrivera pas à le parser.

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. :pinch: