Quelques idées pour améliorer le moteur de recherche :

• (FrancoisSchreuer) Permettre l’utilisation de critères booléens. A priori, c’est possible avec l’actuel système d’indexation : il suffit ( !) de faire autant de requête sur l’index qu’il y a de parties à la recherche complexe puis de les croiser (sans doute le plus efficace consiste-t-il pour ce faire à stocker les résultats intermédiaires dans des tableaux puis à comparer les tableaux).
  • (Fil) Quelles recherches booléennes ? Avec le moteur actuel AND et OR sont gérées dans la même requête, en bidouillant les scores, et c’est largement suffisant ; peut-être que NOT/-/SAUF (« Fromage -chèvre ») serait utile, en revanche ? Ca ne devrait pas être très compliqué à implémenter non plus, ça, sans booléens mais toujours en rigolant avec les scores (tu enlèves 200 points aux articles contenant «chevre») ???
    • (Fil) Je viens de faire des tests pour que "-motnul" enlève 200 points aux articles contenant le mot refusé («motnul»), et ça fonctionne plus ou moins : les articles ont bien un score négatif, mais je n’arrive pas à les éliminer avec points>0... à suivre. _**** (Philippe) De toutes façons : même si la syntaxe "-" ou "+" ou autre variante existait il faudrait absolument que cela se traduise dans le formulaire standard de recherche par des boites à cocher/listes : rechercher le mot exact, la phrase exacte, uniquement dans les texte, les titres. Actuellement avec les AND et OR mélés dans les réponses sur mon site principal les recherches avec spip n’ont pas d’intérêt car j’ai tout de suite 200 réponses. C’est sensible mais pas du tout spécifique dès qu’on utilise deux mots ce qui fait que je passe par phpdig pour avoir des infos pertinentes. En me relisant je pense que pour le #FORMULAIRE_RECHERCHE il ne faut pas le modifier, il faut plutôt proposer un #FORMULAIRE_RECHERCHE_AVANCEE avec les options car le formulaire simple suffit pour des petits sites.

• (FrancoisSchreuer) Permettre la recherche d’expressions entières. Là par contre, on entre en conflit violent avec l’actuel système d’indexation (basé sur les mots pris individuellement).
  • (Fil) Non, pourquoi ? Il «suffirait» de chercher les articles contenant tous les mots demandés (requête classique + score > n*100 mots) et d’ajouter un critère fulltext du genre AND (CONCAT(titre,chapo,texte, ....) like '%moteur de recherche%'

• (FrancoisSchreuer) Faciliter d’une manière ou d’une autre la création de formulaires de recherche avancés (par mot-clé, par date, par auteur,...).

• (NicolasHoizey) : ajouter la possibilité d’utiliser un moteur de recherche externe (mnoGoSearch, Swish-e, ht ://Dig, Index Server, etc.) pour indexer les documents joints (MS Office, Open Office, PDF, etc.), fait dans SpipAgora via l’abstraction SevenSeas*. Une autre piste serait celle de Maxime qui utilise une version transformée en texte et stockée en base. C’est je crois une solution utilisée à la Mairie de Boulogne Billancourt.
  • Antoine : pour l’indexation des documents attachés (PDF, Word, OpenOffice...), c’est faisable en PHP pur. Si si.
    • (NicolasHoizey) Tu peux préciser ???
      • Antoine : parser du .pdf, .doc ou .sxi en PHP. J’ai le code quelque part sur mon disque dur. Ca marche assez bien (le .pdf est plus capricieux que le reste).
        • (NicolasHoizey) Si effectivement le code, que tu as, arrive à extraire uniquement le contenu de ces charabias que sont les formats cités, c’est très intéressant !

• (FrancoisSchreuer) Question. Est-ce que l’idée d’amélioration de l’indexation proposée par Fil a dépassé le stade de l’idée (il me semble avoir vu passer quelque chose dans la liste mais je ne le retrouve pas et il ne me semble pas que la 1.7.1. contienne des nouveautés de ce point de vue).
  • Réponse : Bien au contraire !
    • (FrancoisSchreuer) Euh non, sorry, j’ai vu toutes les nouveautés ajoutées au moteur de recherche et signalées dans la doc. En fait, je voulais parler précisément de la proposition faite ici, dont il semble qu’une partie a été réalisée même si c’est une fonctionnalité cachée (admin_index.php3). Il s’agissait de créer une boîte (de plus) dans l’admin des objets permettant de demander pour chacun qu’il soit réindexé/qu’il ne soit jamais indexé et de connaître son état d’indexation (et éventuellement la date de sa dernière indexation).
      • Si si, tout fonctionne, mais il n’y a pas d’interface pour dire ce qui ne doit pas être indexé (car en fait ça se règle mieux en SQL qu’avec une interface : update spip_articles set idx='non' where date<'2001-01-01'). Le seul truc qui peut être intéressant c’est de faire une belle page admin_index ; l’actuelle ressemble plus à un truc de debug (c’est à ça qu’elle sert, d’ailleurs).
        • (FrancoisSchreuer) Ok, mais la page admin_index, aussi belle soit-elle, ne gérera que l’indexation de façon fort générale. Ne serait-il pas malgré tout utile de prévoir dans les pages de gestion des objets une petite fenêtre permettant :
            D’avoir l’info. Savoir si la ressource est ou non indexée et si oui, depuis quelle date.
            D’interdire explicitement l’indexation de cet objet (ce qui ne semble pas exister pour le moment). Ca peut être franchement utile, à mon sens (même s’il faudrait sans doute creuser le concept pour pouvoir appliquer le traitement par rubrique, par secteur,...) pour nettoyer les résultats rendus par le moteur de recherche et/ou protéger des données (par exemple, actuellement, si l’on ne prend pas garde à placer des instruction explicites dans les squelettes pour l’empêcher, le moteur indexe aussi des données placées dans une rubrique "membres" et ce genre de choses).
            De demander une (ré)indexation ciblée de cette ressource (là, comme je ne maîtrise pas le système d’indexation, je dis peut-être une bêtise : est-ce qu’une ressource est systématiquement ré-indexée dès qu’elle a été modifiée ? Si oui, cette proposition n’a pas beaucoup de sens). Quand on vient de faire une grosse modif, ça peut être utile de forcer la réindexation d’une page.
          • (Antoine) Si on applique ce genre de raisonnements à toutes les fontionnalités, on se retrouve avec un cockpit d’Airbus (je sais, il y en a qui aiment). Le moteur d’indexation devrait être le plus transparent possible, et même la page admin_index ne devrait normalement pas exister. A nous de mettre en oeuvre ce fonctionnement simple, transparent et sans bugs ;)
            • (Fil) La page admin_index n’est pas indispensable, mais étant donné les mythes qui traînent sur l’indexation, il vaut mieux que les gens l’aient quand même, qu’on puisse leur dire quoi regarder pour se rassurer.

(NicolasHoizey) Une idée pour favoriser la présence de plusieurs termes recherchés, plutôt que plusieurs occurences de l’un des termes. L’idée est, si on cherche "langue spip", que "spip langue" soit plus en avant que "mauvaise langue ou langue de boeuf". Il faudrait que l’on augmente les points de "langue" si on le trouve plusieurs fois, mais sans jamais aller au delà de 2, et on serait plus proche de ce qui est attendu.

Soit nb("langue") le nombre de fois qu’on trouve le terme "langue", on pourrait dire que le nombre de points est :

points("langues) = 2 - 1 / nb("langue")

Du coup, avec les exemples ci-dessus :

et

• Pourriez vous m’indiquer une doc pour savoir comment utiliser ce moteur de recherche. J’ai besoin de rechercher dans les documents PDF et de les présenter lors de l’affichage de résultats. C’est bien de cela qu’il s’agit ?