Fonctionnement :
– On indexe les contenus au fur et à mesure dans un autre système (Sphinx en l’occurrence).
– Puis on peut requêter ce système de multiples manières, bien plus complètes que dans SPIP ou autre truc SQL par défaut.
Bon ça c’est pour la technique.
Maintenant pour les fonctionnalités justement, la technique utilisée (Sphinx) permet de faire mieux que ce qu’on a actuellement, et il y aurait quelques améliorations possibles :
– Pouvoir chercher par combinaison de tags (on peut déjà combiner plusieurs critères : période, auteur⋅e, tag, mais PAS plusieurs tags alors que c’est un truc multiple pour un même contenu).
– Revoir l’affichage pour mieux afficher les filtres déjà actifs en haut, mieux séparé, plus explicites, avec une croix pour supprimer chacun.
– Revoir l’affichage des filtres sur le côté pour pour n’afficher que les filtres de ce qui reste dans les résultats déjà filtrés : quand j’ai déjà choisi le tag « truc » et qu’il m’avait prévenu qu’il y aurait 51 résultats, alors en colonne centrale ça affiche 51 résultats, et dans les filtres sur le côté, ça doit m’afficher les filtres utiles pour ces 51 résultats restants et uniquement ceux là (ça ne doit pas m’afficher « machin (145) »).
C’est un comportement de base de la recherche-filtrage par facettes, on filtre puis optionnellement re-filtre au fur et à mesure. Et si ça va pas on décoche tel ou tel filtre qu’on avait déjà mis.
– On peut filtrer par tag, mais par tag exact uniquement, alors que dans Seenthis on a un système de tags pseudo-arborescents. Là dans la recherche Sphinx, on peut pas chercher « # ghost » et avoir tous les contenus qui ont plus précis. C’est nul et pas cohérent du tout. Il faudrait que ça marche, y compris si on ajoute du filtrage multi-tags.
