ni pagination ni scroll infini

Bonjour,

Ce n'est pas possible je pense.
D'après ce que je comprends vous ne voulez pas de pagination mais que tout les éléments soient chargés sur le listing.
Pour cela, c'est lors du chargement des éléments depuis MySQL qu'il faut agir, et donc avant l'affichage des vues.
Ce que vous voulez faire, c'est simplement augmenter le nombre de lignes dans l'onglet "Products options" de votre élément de menu.
Par exemple, si vous avez un élément de menu listant vos produits sur 10 pages de 20 produits chacune avec 4 colonnes, cela veut dire que vous avez 5 lignes * 4 colonnes de configuré. Si vous passez cela à 50 lignes * 4 colonnes, il n'y aura ni pagination ni infinite scroll, et tous les produits seront affichés d'un coup.

Notez cependant que :
- le but de lazy loading, c'est de charger les fichiers (les images principalement) dont la page à besoin plus tard, ce qui permet d'afficher le morceau visible de la page sans attendre que toutes les images soient récupérer par votre navigateur.
- le but de CSS flex / grid, c'est d'avoir un affichage en grille ligne/colonne.
- le but de la pagination / infinite scroll, c'est de ne pas charger les données de tous les éléments d'un coup et de limiter cela à quelques dizaines par page (ou par chargement de l'infinite scroll).

Ce que je veux c'est que :
- le CSS flex / grid n'aide en rien à ne pas avoir de pagination / infinite scroll
- le lazy loading va améliorer les performances d'affichage entre le moment où le navigateur récupère l'HTML de la page et le moment où la page est affichée à l'utilisateur
- la pagination / infinite scroll va améliorer les performances entre le moment où vous demandez l'affichage d'une page et le moment où le navigateur récupère l'HTML de la page.
Donc tout cela est complémentaire et avoir du lazy loading ne permet pas de se passer de pagination. Si vous essayez d'afficher 2000 produits sur une page, avec lazy loading ou pas, ce qui va surement se passer, c'est que votre serveur moulinera pendant un moment jusqu'à retourner une page d'erreur car il aura consommé trop de mémoire ou trop de temps CPU pour générer l'HTML de la page.

Bonjour,

Oui, vous pouvez forcer les colonnes. Pour les lignes, cela ne va rien changer car c'est pris en compte lors du chargement des produits avec la requête MySQL, donc avant votre forçage dans l'override de la vue.

Bonjour,

Dans la configuration, ce sont les options par défaut pour de nouveaux modules/éléments de menu.
Et donc, lors d'un affichage sur le frontend, les valeurs de la table hikashop_config ne sont pas prises en compte.
Le $this->params->get('columns') vient directement de la table où sont stockés les options des éléments de menu / modules par Joomla.

Encore une fois, vous pouvez augmenter les valeurs comme vous le voulez dans votre override de vue, mais les données des produits et catégories sont chargés avant. Et heureusement d'ailleurs. Sinon, cela voudrait dire que HikaShop devrait charger tous les éléments possibles, pour ensuite filtrer et n'afficher que les éléments de la page courante dans la vue, ce qui ferait surement planter la page à cause d'une utilisation trop grande de la mémoire et / ou du CPU.
Donc, comme je disais, vous ne pouvez pas augmenter le nombre d'éléments chargés avec un override de vue. Un autre $this->params->get('columns') (et pareil pour les rows) est fait dans le view.html.php lors de la requête MySQL avant le chargement des vues.

Si vous voulez faire cela, il faut développer un plugin system pour précharger une copier modifiée de la classe du view.html.php où est faites la requête MySQL.

Mais je pense que ce n'est pas par là qu'il faut prendre le problème. Vous dites que vous n'arrivez pas à "écrire dans l'admin dans les cases row column". Je ne vois pas de quoi vous voulez parler. Pourriez vous décrire ce que vous voulez dire avec des captures d'écran ?
Je n'ai personnellement pas de problème à créer un élément de menu avec 4 colonnes et 999 lignes. Je peux utiliser les boutons plus et moins, ou directement écrire la valeur que je veux dans les deux champs :
i.imgur.com/sqFRN7L.png
Cet élément de menu affichera un listing avec 3996 catégories par page sur le frontend, ce qui est énorme.

je clique sur une catégorie du listing je n'ai que 8 elements et non 72

Ca, cela veut dire que dans les options de l'élément de menu qui est utilisé sur la page courante, dans l'onglet Products options ou Categories options vous avez 8 éléments et non 72. Donc il faut voir quel est l'élément de menu utilisé sur cette page, pour ensuite vérifier ces options dans le gestionnaire de menus de Joomla. Encore une fois, la configuration d'HikaShop n'intervient pas à cet endroit.

Bonjour,

Ok, donc c'est un problème de CSS dans le backend ?

Pourriez vous fournir, via notre formulaire de contact, l'URL de la page en question pour votre second point et un accès backend pour étudier la situation ?
www.hikashop.com/support/contact-us.html

Ca devrait nous permettre de trouver ce qui cloche.

Bonjour,

Je vois le souci sur votre site.
Vous avez fait un override du fichier media/com_hikashop/css/backend_default.css pour media/com_hikashop/css/backend_custom.css avec HikaShop 4.2.1
Du coup, sur votre backend, il vous manque tout le CSS que nous avons rajouté dans media/com_hikashop/css/backend_default.css depuis la 4.2.1, et notamment, le CSS pour corriger l'affichage suite aux changements fait par Joomla dans le backend pour Joomla 5.
Une solution serait de récupérer le CSS qui a été changé / ajouté dans le fichier par défaut dans votre fichier custom.

Ce que je vous recommande, c'est de garder le CSS par défaut d'HikaShop dans l'option "CSS backend" de la page de configuration d'HikaShop. Et si vous voulez rajouter du CSS, ajoutez-le dans le user.css de Cassiopeia:
docs.joomla.org/J4.x:Cassiopeia_Template...Customise_Cassiopeia
Ainsi, lorsque vous mettrez à jour HikaShop, vous aurez automatiquement les ajouts de CSS que nous faisons pour les nouvelles fonctions, et le support des futures versions de Joomla.

Oui, vous pouvez utiliser un import du backend_default.css dans votre backend_custom. Cela revient au même. L'avantage, c'est que cela continuera de fonctionner même si vous changez de template dans le backend (ou si une mise à jour Joomla change le template du backend comme ce fut le cas avec le passage de Isis à Atum).

Concernant le nombre d'éléments dans le listing, il n'y a pas de bug. C'est juste votre configuration d'HikaShop qui fait cela.
Vous avez activé l'option "Forcer les URLs canoniques sur les listings" de la configuration page. Donc, au lieu de générer l'URL des catégories dynamiquement, HikaShop va utiliser l'URL canonique de la catégorie dans les listings.
Par exemple, sur la page votresite.fr/chaussures-grandes-tailles-femmes-marques vous avez par exemple la marque "A SAKO" avec l'URL votresite.fr/1233-chaussures-marque-a-sako qui vient de l'URL canonique de la marque. Or, l'URL par défaut, si HikaShop la génère dynamiquement serait: votresite.fr/chaussures-grandes-tailles-femmes-marques/1233-chaussures-marque-a-sako
Si vous utilisez l'URL générée dynamiquement par HikaShop, vous verrez bien votre listing de produits de cette marque avec tous les produits chargés d'un coup.
En fait, avec votre URL canonique, Joomla demande à HikaShop de générer le listing des produits avec l'élément de menu par défaut de votre site, c'est à dire l'élément de menu avec le nom "Accueil". Or, cet élément de menu est justement configuré pour avec un listing avec 8 produits par page:
i.imgur.com/JHWo3Qm.png

Non, vous ne perdrez pas le référencement.
Vous pouvez laisser l'URL canonique de vos catégories tel quelle. C'est elle qui fait le référencement.
L'option "Forcer les URLs canoniques sur les listings", c'est uniquement pour que les utilisateurs normaux du site passent par la même URL que celle référencée.

Mais oui, vous pouvez aussi changer les options de l'élément de menu par défaut. Ca fonctionnera également, et ça vous permettra de garder l'URL canonique pour les utilisateurs du site.