Précédent et suivant sur les fiches produits Virtuemart

[RobertG]

Bonjour,

Faute de réponse sur le forum Virtuemart FR, je me permets de reposer la question ici.

Sur une boutique (VirtueMart 3.8.8 10472 Joomla! 3.10.3 et PHP 7.4), les boutons précédent et suivant affichés sur la page de détails des produits restent figés sur le dernier produit de la catégorie comme "précédent", le premier comme "suivant" et n'affichent pas les noms ds réels produits précédent et suivant.

Dans la page de catégorie, le tri est fait sur le nom. Dans l'administration, la position des produits, dans la colonne "réorganiser", est à 0 pour tous. Lorsque certains avaient un nombre supérieur dans cette colonne, le tri se faisait sur le nom de ceux ayant 0, puis les autre s'ajoutaient, le tri était donc incorrect, d'où la remise de tout à 0.

(Certaines catégories comportant des dizaines de produits, je ne vois pas comment pourrait se gérer, dans VM, l'ajout d'un produit dont le nom le positionnerait au milieu des autres mais avec un numéro de position incorrect. Je n'ai jamais trouvé de moyen de réorganiser correctement cet ordre.
Sachant que demander un affichage en ordre alphabétique tient d'abord compte de ce champ d'ordre, c'est à coup sûr la galère !)

Je ne sais pas où chercher ce qui peut déclencher cette erreur de repérage des produits précédent et suivant.
Qui aurait une idée ?

Merci de votre aide !
Robert

PS : L'anomalie se retrouve aussi sur des sites neufs utilisant les données de démo.

[RobertG]

Bien, ça vous laisse indifférents !

Question, si un pro des requêtes SQL passe par ici : est-il possible avec une requête sur la table des produits (FR) de VM de la trier dans l'ordre alphabétique du nom de ces produits et dans le même temps de définir dans un champ un n° qui sera celui de la ligne lue ? Ou faut-il pour ça une routine PHP ?

Merci de votre aide !

[dolmenhir]

Bien, ça vous laisse indifférents !

Désolé Robert, mais je n'ai qu'un seul client utilisant Virtuemart, et ce site ne rencontre pas le problème que tu évoques.
Donc impossible pour moi de t'apporter un semblant de début de réponse (d'autant plus que moi et VM on n'est pas très copains et qu'il est convenu que je ne mette pas plus que ça les mains sous le capot).

[RobertG]

Merci de ta réponse.

J'avais monté ce site il y a plusieurs années pour un client, site vitrine, à une époque où j'avais une certaine expérience de VM suite à de l'aide apportée ici puis en direct à des (déjà) utilisateurs et utilisatrices de ce système de boutique. Depuis, je n'ai guère touché à VM et j'ai un peu de mal avec son interface vieillotte.

Je crois me souvenir qu'il y a toujours eu des difficultés à classer les produits, d'autant que VM n'utilise pas le glisser-déplacer, ce qui rend impossible le reclassement quand il y a beaucoup de produits.

Ce client semble décider à rester sur VM et veut que ses produits (des plantes) soient classés par ordre alphabétique, mais comme je l'ai dit, VM classe alors d'abord sur le champ "pordering" de la table des produits, puis dans l'ordre alphabétique.

Si donc on a bien le champ pordering défini dans le même ordre que l'ordre alphabétique, on a toutes chances pour que les produits précédent et suivant soient corrects. Cela voudrait dire que si on ajoute un nouveau produit, malgré le tri alphabétique, il devrait se retrouver soit en tête de liste si pordering et par défaut défini à 0, soit tout à la fin si le champ est auto-incrémenté, ce qui n'est pas le cas...

J'ai créé hier un script pour affecter le n° d'ordre en fonction de l'ordre alphabétique (qui ordonne les produits indépendamment de leur catégorie, contrairement à ce qu'on peut faire dans la page de liste par catégorie), il me faudra tester ce qui se passe en cas d'ajout.

Je ne désespère pas de convaincre ce client/ami de passer à Hikashop...

[dolmenhir]

Pour le tri, tu peux normalement intervenir depuis la configuration, onglet "tri des produits"
voir image

[RobertG]

Oui, mais justement, pour utiliser le tri des produits, il faut avoir défini le champ correspondant, et quand dans une catégorie on a des dizaines de produits, et qu'il faut changer un par un le numéro, ce n'est pas gérable.
Le champ en question (pordering dans la table virtuemart_products) apparaît lorsqu'on est en affichage de liste des produits d'une catégorie

Dans une des catégories, il y a plus de 400 produits !

[RobertG]

Je me suis trompé de table et de champ pour l'ordre ci-dessus, c'est la table `uysf1_virtuemart_product_categories` et champ "ordering" qui le gèrent.

[dolmenhir]

Sinon faut faire une moulinette en php pour lister les catégories et/ou les produits, les trier dans l'appel sql selon le(s) critère(s) voulu(s) et lancer une boucle pour les mettre à jour en leur attribuant un numéro incrémenté.
C'est brut et radical, j'en conviens, et en plus ça ne sera jamais aussi fin qu'un tri manuel.
Mais sur des centaines de produits, je vois pas comment faire autrement, à moins d'avoir beaucoup de temps à perdre...

[RobertG]

C'est ce que j'ai fait : lecture de la table des produits dans la langue, et pour chaque ligne, attribuer son ordre au champ ordering de la table virtuemart_product_categories, mais ce sera à faire après chaque ajout !
Lorsqu'on ajoute un produit, ce champ est défini à 0 et si on force ensuite à un numéro correspondant au précédent ou au suivant dans l'ordre alphabétique, l'enregistrement conserve le numéro, ne recalcule pas, on a un doublon.

[dolmenhir]

tu peux pas modifier la table pour que ce champs soit en auto-incrément ?

[RobertG]

Je ne pense pas, parce rien ne dit que VM lors d'une mise à jour ne changera pas la structure, et puis mettre en autoincrément veut dire ne plus pouvoir reclasser.
J'ai dupliqué un produit : VM lui affecte 0 comme n° d'ordre et le place en tête côté site. Si c'est 10 qu'il faudrait lui attribuer pour que le tri soit bon et que le champ est en autoincrément et a attribué le numéro 2598, jamais je ne pourrai mettre 10 au lieu de 2598, puisque le champ sera alors verrouillé.