PhenixTweet

diff_product_controler.txt

5 h.

Je continue.
Pour pouvoir afficher le fournisseur sur la fiche produit

et dans le tpl

{$product_supplier->name|escape:'html':'UTF-8'}

8 h.

On fera une "réunion" pour savoir si on se cogne le reclassement en catégories à la mode "prestashop" peut être même avec un script suivant des règles...
mais il n'y a que 2 lignes à changer dans un seul fichier je ferais le changement à la main pendant quelques mises à jour en attendant de voir comment cela va se goupiller, peut être même que je ferais un script de patch ;-)

8 h.

a répondu au Message de herve_02 il y a 8 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 🐱

8 h.

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

Je suis intimement persuadé que personne (sauf à la marge) ne gère individuellement produit par produit sauf à avoir 200 produits Si vous en avez 5000, vous allez le faire au début et seulement à la création des produits , mais personne ne récupérera un historique.
Ensuite cette "manip" ne sert qu'à gérer les gens qui remontent dans le fil d'ariane car aucune catégorie parente (vide) n'est exposé dans le bloc catégorie et même le top menu.
donc même si la sous requête est sous optimale, elle n'est pas destiné à servir.
../..

8 h.

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

Il n'y a pas de bonnes solutions je récupère un presta 1.7 qui était une migration d'un 1.5 qui qui lui même était une migration d'un 1.3 ou 1.4
Le résultat est merdique :le BO est un peu cassé et tenter des trucs c'est le risque de voir une page blanche, la paramétrage de certains modules donne une page json et pour faire tomber en marche le module paypal, j'ai du modifier à la main dans ps_configuration.
Donc l'association des produits dans plusieurs catégories (juste pour l'affichage) me semble sous-optimal ../..

9 h.

a répondu au Message de Eolia - 9 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.

../..

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.

9 h.

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

diff_class_products_display.txt

23 h.

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

Il faut l'oeil du maître

le nouveau diff (le bon)

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

diff_class_controle_product-category.txt

1 jour

Dernière modifs afin de pouvoir (ou pas) afficher les produits des sous catégories de la catégorie en cours. Là encore cela ne change rien si ce n'est pas paramétré

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)

Atchworks @atchworks

1 jour

a répondu au Message de Gil6688 - 1 jour

1.7 sec en mobile et 1.1 sec sur PC

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 ?

1 jour

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

Cet ajout sera inclus dans la v37 👍

diff_class_products_display.txt

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_product_contoler.txt

1 jour

Ajout du fournisseur dans les produits

diff_class_products_display.txt

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.

1 jour

moi j'ai 1.1 et 5.3
theme enfant de default-bootstrap

Gil6688 @gil6688

2 jours

Hello à tous, serait-il possible de connaitre vos scores Largest Contentful Paint sur googlespeed test, car pour ma part, j'ai :
1.3s bureau et 4.0s sur mobile.

Merci

2 jours

a répondu au Message de herve_02 il y a 2 jours

bien entendu je ne cherche aucun crédit pour ce code et abandonne mes droits lol dessus

2 jours

J'ai fais une micro modif pour permettre d'afficher pas le même nombre de nouveaux produits dans la page et dans la colonne gauche (ou droite) est-ce que cela peut intéresser du monde et je fais suivre mon code (quitte à l’intégrer - peut être plus proprement dans la v37) ? ou j'override tout seul comme un grand à la maison ?

2 jours

J'ai une question un peu idiote

je veux modifier un comportement du contrôleur nouveaux produits, ne faire apparaître ceux qui sont juste sur le catalogue.
je sais faire _mais_ cela me gène de faire un overdrive de toute la classe/fonction pour juste un mot
$sql->where('product_shop.`visibility` IN ("both","catalog")');
==> $sql->where('product_shop.`visibility` IN ("both")');

il y a un moyen de faire cela plus "chirurgicalement" ?

Atchworks @atchworks

2 jours

a répondu au Message de Eolia - 2 jours

Non actuellement je suis sur Cloud... avec plus de ressources serveurs mais peut être que ça n'a aucune incidence du coup.

2 jours

a répondu au Message de Atchworks - 2 jours

C'est la même offre que ce que tu as actuellement, la seule chose qui change est le nombre de lunes (instances Cpanel) mais tu n'en as pas besoin.

Atchworks @atchworks

2 jours

a répondu au Message de Eolia - 2 jours

ça m'a l'air beaucoup moins performant sur le papier. Après j'ai pas une très grosse boutique, à voir.

2 jours

a répondu au Message de Eolia - 2 jours

Oui une solution serait de cocher toutes les catégories parents et comme les catégories ont des sous catégories qui ont des sous catégories....

je vais réfléchir à ça...

3 jours

a répondu au Message de Eolia - 3 jours

Category::getProducts():

INNER JOIN `'._DB_PREFIX_.'category_product` cp
ON(p.`id_product` = cp.`id_product`)
WHERE cp.`id_category` = '.(int)$this->id.

3 jours

a répondu au Message de herve_02 il y a 3 jours

Ok, les produits des sous-catégories appartiennent aussi aux catégories parentes ? Car en front ça ne ramène que les produits liés à la catégorie en cours.