herve_02 sur PhenixTweet

herve_02 @herve_02

1 jour

Et la modification dans la classe pour décider ce que l'on peut afficher dans le blocknewproduct.

Le changement n’impacte pas la configuration de la boutique, c'est transparent. si on ne touche rien dans la config du module blocknewproducts où si ce module n'est pas installé le site fonctionne de la même manière.

diff_class_products_display.txt

1 jour

a répondu au Message de herve_02 il y a 1 jour

Par contre, là j'ai pas bien compris le use case ?

herve_02 @herve_02

1 jour

a répondu au Message de Eolia - 1 jour

En fait je prends l'exemple de chez nous. On veut avoir en permanence le block (left) des nouveaux produits sur la page ET avoir la liste des nouveaux produits en premier page. Si on veut 12 produits sur la première page, cela implique alors.. 12 produits _tout le temps_ dans le bloc nouveaux produit.

cela fait lourd.

plus tard, je ferais une amélioration pour que le block right/left affiche les nouveaux produits de le catégorie en cours et des sous catégories..

et le tri both/catalog cela permet de supprimer de ces nouveaux produits les versions numériques (conf du 1.7)

1 jour

a répondu au Message de herve_02 il y a 1 jour

ok, mais dans ce cas n'oubliez pas de modifier également la ligne 3050 de Product.php

herve_02 @herve_02

1 jour

a répondu au Message de Eolia - 1 jour

Il faut l'oeil du maître

le nouveau diff (le bon)

diff_class_products_display.txt

14 h.

a répondu au Message de herve_02 il y a 14 h.

Mettez-le en override car je ne l'intègrerai pas dans le cœur, cela irait contre la logique initiale du code: On n'affiche que les produits qui sont associés à la catégorie en cours. C'est au commerçant de faire le choix des produits qu'ils associe ou pas.
Un exemple: j'ai une catégorie parente qui a des sous-catégories avec au total 2000 produits. Afficher 2000 produits n'a aucun sens et personne ne va scroller ou chercher dans les pages au-delà de la page 3 ou 4.
L'idée est donc de n'associer à la catégorie parente que certains produits (ceux qu'on veut mettre en avant ou écouler).

De plus le IN(SELECT... est loin d'être optimal, il serait préférable de faire une jointure sur ps_category.

herve_02 @herve_02

13 h.

a répondu au Message de Eolia - 13 h.

comme on le met en ligne (sans retour possible) de 30 dernier cara je pare au plus pressé : que cela marche.

Le fait de "décider" quoi afficher est le serpent qui se mord la queue, qui va gérer à la main sur 2000 produits ? un par un avec un back-office "assez lent". Trouver le produit (recherche par référence) puis affichage, puis onglet association puis scroll dans l'arbre.

../..

herve_02 @herve_02

a répondu au Message de herve_02 il y a 13 h.

Enfin je ne suis pas 100% persuadé qu'une jointure soit meilleure. la jointure multiplie le nombre d’enregistrements entre eux :
joindre deux table de 1000 enregistrements expose 1 millions de lignes si je fais 3 tables c'est 1 milliard, 4 c'est un trilliard (les index permettent de ne pas tout lire cependant)Il faudrait voir comme mariadb traite la requête dans son analyse.

Pour défendre mon code il ne change le comportement QUE pour les gens qui décident de l'utiliser. C'est juste un plus qui permet _pour ceux qui veulent_ et n'induit même pas une surcharge cpu c'est un bête if 🐱