trier les articles joomla selon un champ personnalisé

[Niko.Semaphore]

Oui je les suit de près les articles mais soyons francs : installer un plug-in pour afficher son contenu c'est le mode d'utilisation "easy" ;-) Là où ca se corse c'est dès que l'on veut vraiment les utiliser en mode mini-cck : trier/filtrer via des menus, via des modules etc
La quasi totalité des tutos que tous publient (et je ne juge pas car tout le monde n'est pas une agence avec des besoins de dev etc) s'arrètent à cet usage "de base".

Par exemple usage "bête" de vrai situation : utiliser un CF pour séléctionner une adresse dans un article sur une carte OSM pour afficher un module qui les affiche avec par exemple du filtre sur catégorie ou tag voir CF (par par exemple n'afficher que les articles qui aurait un CF précis à sur une certaine valeur) pour éviter d'avoir à installer un composant.

La vrai difficulté pour les CF de J! c'est que peu de personnes compétentes (dont je ne fait pas partie ) investiront en dev dessus car cela nuierait au busines model des composants (phrases entenues de la bouche même de devs). Joomla! reste toujours coincé dans sa position de CMS pour power user : on favorisera toujours l'ajout de composants que de mettre à dispo des helpers/api pour faciliter l'extention par le core. WP à bien réussi là dessus à dépasser son statut de plateforme Blog avec un"god" mode pour les purs dev qui poeuvent plus facilement étendre les content type et le super pack Advanced Custom Field pour eténdre le tout (bien plus puissant que nos CF) même si WP à d'autres biais évidemment.

Perso je rêve d'extention qui necessiteront l'install de CF et qui ajouteront des overrides etc pour construire des extetions avec le max de J! Core dedans.

Poiur en revenir à ta proposition pour larticle : XT search utilise très bien les CF pour la recherche. Nous l'avons massivement utilisé sur ce site déditeur de livres jeunesse : avec d'autres extentions comme les géniaux Articles Anywhete et Articles Fields de Regular labs.

[woluweb]

mais c'est une tuerie cet exemple de filtre+recherche sur l'éditeur de livres jeunesses

tout ça vient de XT Search ?
et en position latérale gauche, c'est sur base de quoi ? Des CF, des Tags ?
C'est d'office avec Algolia ou les filtres latéraux fonctionnent aussi sans ?
Facile à mettre en oeuvre ou plutôt truc de dev ?

Je me dis que ça mériterait bien une petite présentation/démo livre lors d'un JUG mensuel virtuel.
Tu serais partant ?

[Tortue Genial 69]

+1 c'est vraiment top et bien fait.
en effet , ce type de besoin peut intéresser pas mal de monde je pense (moi le premier)

[manu93fr]

+ 1000
elle est vraiment bien foutue cette page

[herve]

Salut Je ne partage pas votre enthousiasme pour Easy layout que je ne trouve pas ergonomique du tout. Par contre je pense qu'effectivement les solutions de type elasticsearch ou Xt search dont je demandais un avis dans le fil https://forum.joomla.fr/forum/joomla...-elasticsearch sont certainement les plus pertinentes pour réaliser le filtrage de CF. Leurs auteurs mentionnaient bien la possibilité de filtrage de CF :-) Je soutiens aussi la demande de @woluweb car je trouve le filtrage sur https://www.elanvert.fr/ très bien conçu (comme l'ergonomie, enfin un beau site joomla :-) ) D'autant que je vais devoir refondre bénévolement lors de la sortie de joomla 4, 2 sites associatif comme la page https://www.clibre.eu/fr/logiciels-libres car j'avai trouvé un bon module de filtrage mais le dev; a triplé le prix à 90$/an, ce qui est pour nous difficilement envisageable !

[Niko.Semaphore]

Salut !
Je ne m'attendais pas à autant de "retours" Ce projet (qui à besoin de finition en terme d'optimisation un peu partout, le temps, les budgets tout ca...) s'est "retrouvé" en Aloglia après avoir sur d'autres projet testé à peu près toutes les solutions de search et filtrage et ordering de J! sans nécessiter de code (on 'est pas des dev Joomla! à l'agence )
Oui le menu à facettes (terme technique offciel des menus avec plein de filtres en tout genre) sont générés en grande partie par l'extention. Là il y a de la surcouche css pour coller à l'ambiance et nos choix d'UI mais techniquement c'est du XT Search. Il y a une limiation (outrepassable avec du dev pas drôle et pas hyper maintenable) : on ne peut pas avoir deux search bar sur la même page : et alors me direz-vous ? Bah sur la page catalogue, le menu du haut via la loupe n'est pas dispo. Il faut revenir à la page d'accueil ou autre. Même si pas grave car il y a déjà une search barre dans le catalogue, ca m'empêche que ca change l'UX est ca, ce n’est pas glop pour nous.

Pour le reste : il n’y a pas de "gros code". La plupart d'entre vous ici on bien bien plus d'XP que moi/nous à vous lire, mais de l'ES6 par contre et ça c'était vraiment nouveau, avec de la syntaxe moderne et inconnue pour nous (je me le suis fait expliqué plus tard par un pote que c'était de l'ES6) Donc a pas mal tâtonné, fait corriger des bugs par Hannibal, le dev, ainsi que joué avec les paramètres pour que certains champs hors J! Core fonctionne avec Algolia (l'article fields de Regular). Car si il y a bien un truc à comprendre c'est que dans ce type de projet il faut surtout se mettre au fonctionnement de agolia pour faire fonctionner le bouzin au mieux. C'est un super outil (français !!) mais le search en mode saas c'est un coup à prendre ;-) Mais Hannibal a vraiment fait un taf de fou pour rendre cela accessible à J!. Le prix est dérisoire (60€ de mémoire) pour une fonction de ce type. On a discuté avec lui pour ajouter qques exemples tutos basés sur notre expérience sur son site.
Le composant utilise un système de hook bien à lui (lié en grande grande partie au framework de Algolia) donc on oublie les reflexes d'overrides à la J! il faut rentrer dans cet univers de Hook et de js.

Donc oui techniquement ca "claque" pour n'importe quel Joomliste, je pense (je veux dire par là que lorsque l'on a construit qques catalogues J!, on mesure bien le truc) mais pour n'importe quel Prestashop c'est quasiment la base. Honnêtement on a fait le choix de J!/Algolia car :

1. je déteste au plus au point Presta (même si j'ai qques clients et qui génère de beau CA annuels)
2. Les extensions de e-commerce J! ont des bakoffice assez rebutant (désolé mais même si les respecte ca reste hardcore pour les users et on avait pas le budget pour refaire l'interface de saisie en front...)
3. On a déjà tout testé ou presque et là c'était du all ine one : search et filtre
4. Algolia seul, offre des options de ouf coté search très prometteur pour le client : gestion de synonymes, pondération des fields dans les results (ca manque grave au CCK de J! ca par exemple), re-ordering des resultats...
5. On reste J!Core (pas de CCK) donc on maitrise bcp bcp mieux les bugs, évolutions, routing, update, overrides etc
6. Comme c'est du com_article on peut jouer à mort avec Article Anywhere !

Désolé j'ai bcp écrit Honnêtement, acheté et testez-vous verrez que ce n’est pas compliqué du tout. Il vient de sortir une 4.9 avec pris en charge de Hikashop ! Evidemment ce n'est pas pour des projets à 1000€ ou un truc vite fait dans le WE, faut relativiser.

[Tortue Genial 69]

Niko.Semaphore merci pour ton retour ces très intéressant

Je trouve quand même dommage que ce soit si bordélique pour faire un simple tri sur un custom field.

Et via un override de la vue layout_blog ?
Au lieu de trier sur la date de publication ou de création, via un override de cette vue on pourrait pas trier sur le custom field X par exemple ?

[Niko.Semaphore]

Si on parle de coder une vue en dur (pas d'interface user en front) :
c'est toujours possible en hard coded (méthode WP) : car ton $items contient un tableau que tu peux manipuler mais en J! on aime bien avoir des boutons pour tout faire et manipuler le com_content par le biais des jcfields c'est pas hyper intuitif.

Mais si on veut faire un truc simple quand même voici ma solution : Articles Anywhere. Un truc que peu de personnes semble savoir c'est que l'on peut l'utiliser directement dans le code des overrides. Donc concrètement on obtient un moteur de requetage que l'on peut combiner, si on tiens à jouer avec le backoffice, soit depuis les champs du template soit depuis des champs existant dans le menu link (pour récupérer les param$ de la catégorie sélectionnée). Bon évidemment il faut recoder le rendu de la vue layout mais bon perso on la refait systématiquement donc bon...

[Niko.Semaphore]

Pour culture :
Chez Wordpress (toujours regarder comment ca fonctionne ailleurs) c'est WP-Facet (entre autre) qui fait cela très bien (bien mieux que J! maheuresement...) ou WPGridBuilder avec la gestion d'ACF (THE pack de custom fields pour WP là aussi bcp plus évolué que nos J! CF).

[herve]

Bonjour

J'ai fais plusieurs sites avec ACF avant de revenir à joomla pour ce type de fonctionnalité. Je n'y ai pas touché depuis ces 2 dernières années mais mon sentiment que tout n'est pas rose non plus avec ces plugins si on n'est pas dev (mais leur doc est bien faite) et comme ce n'est pas natif, pas tjs facile d'intégrer avec d'autres plugins (même si j'imagine que cela s'améliore aussi)

A noter que dans joomla 4, arrive le mega super champ qui permet de faire des sous formulaires avec d'autres champs personnalisés natifs
J'ai vu aussi dans le mega article de Marc https://magazine.joomla.org/all-issu...ith-extensions qu'il existe des possibilités d'affichage conditionnel de CF . Bref pas mal d'amélioration et ec qui est fondamental pour moi c'est que c'est natif joomla. Un atout que même des dev n'ont pas forcément tous perçu !!

[Niko.Semaphore]

Oui la gestio n'est pas toute facile (après j'y ai à peine touché c'est un collègue expert qui m'a fait des démos surtout) et strès rienté developpeur. c'est d'ailleurs très WP ca : des plug-ins pour les power users mais très souvent faisable par ailleurs en code pour les dev permettant de construire de manière plus robuste. Par exemples pour les champs customs soit c'est intégré au templates soit c'est géré en externes via des plugs soit en code pur de mémoire. Par contre la gestion des content type cest THE truc qui manque à J! et qui est super cool avec WP là aussi soit vie des plugs soit via du code et c'est easy tout plein. Le modèle UCM de J! devait le permettre mais cela n'arrivera à priori jamais.

Tant que j'y pense; un autre exmeple de mini filtre que l'on a put faire avec eayslayout sur cette page pour des séjours.