[spip-dev] Bug recherche native => le retour.

Dev
1

Bonjour tout le monde,

Je reviens à la charge avec mon histoire de bug du moteur de recherche.

Pour faire bien les chose j’ai créé le site http://caossak.phpnet.org/test/

(install que je viens de faire via spip loader + création d’une rubrique + publication un seul article. + activation mots clefs avancé.)

J’ai associé ce seul article aux deux mots clefs qui existent. (POESIE ET RONSARD)

Test :

Recherche de : maison prairie ð trouve l’article

Recherche de prairie maison ð ne trouve pas l’article

(nb l’article s’appelle la petite maison dans la prairie).

Ca fait pareil si on prend des mots du texte bien sûr.

Test2 sur les mots clefs

Recherche de poesie ð trouve l’article

Recherche de RONSARD ð trouve l’article

Recherche de : POESIE RONSARD ð ne trouve pas l’article.

C’est un bug on est d’accord ?

Adresse du site de test :

http://caossak.phpnet.org/test/

Merci de vos retours.

Catherine Ossakowsky

2

Et avec le plugin FULLTEXT ? :slight_smile:

3

Peut-être mais c’est pas ma questiooooooooooooooonnnnnnnnnnnnnnnnnnnnn !!! :wink:

En plus fulltext renvoie les articles qui contiennent l’un ou l’autre des mots (d’après la fiche plugin) …

Enfin bref, la question n’est point là…

Catherine Ossakowsky

4

Y'a un rapport, dans SPIP, entre l'activation des mots-clefs et la pertinence ces résultats de recherche ??

Je n'utilise pas les mots-clefs, de moins en moins et de préférence pas du tout.
Hier encore un utilisateur me faisait une angoisse à l'idée que son site (que je refais) ne nécessite pas de mot-clefs, persuadé que ses articles ne seraient plus aussi bien indexés (par Google et/ou par SPIP) et qu'on ne trouverait plus ses articles... Y'aurait-il un fond de vérité là-dedans ?

5

J’ai fait le test aussi sans les mots clefs (avant de les avoir créés et utilisés ) c’est pareil, je voulais juste un test complet. C’est pas la faute aux mots clefs…

Par ailleurs les mots clefs sont ‘le’ moyen (que j’ai trouvé) de créer des liens de structure entre les articles, je vois pas trop de moyen de s’en passer. Je ne pourrais pas m’en passer si j’utilise SPIP.

En fait je voudrais juste une confirmation de mon bug par les “pros” et savoir ce qui se passe dans ces cas là.

J’ai l’impression que c’est pas un tout petit bug de rien du tout, en version 192 (je sais je radote) cette recherche fonctionnait.
Contourner le pb avec fulltext ne peut être qu’un solution de secours en attendant de corriger non?

Comment ça se passe dans ces cas là ?
Je ne suis pas une habituée de la communauté. Quelqu’un se dévoue pour corriger le bug ?
Moi j’ai pas du tout le niveau pour l’instant en tout cas pour corriger SPIP. J’en serais plutôt à découvrir comment ça marche.
Je veux bien jeter un coup d’oeil à la fonction qui fait ça mais je ne sais même pas par où commencer. Quel est le code qui gère le recherche ?

6

Sans doute est-ce un bug conceptuel (ie un prérequis fonctionnel qui a échappé au codeur émérite), mais pas un bug logiciel car ce qui est codé fait exactement ce que tu décris, oui, et n’a aucune chance de faire ce que tu demandes, non.

Aucun espoir que ce soit corrigé à court terme sur la branche stable dans la mesure où cela suppose donc une reprise de la conception du fonctionnement de la recherche.

Cédric

7

Catherine Ossakowsky a écrit :

Recherche de : maison prairie * trouve l'article
Recherche de prairie maison * ne trouve pas l'article

oui. la recherche ne 'revient pas en arrière' ; elle se fait dans l'ordre de lecture : par exemple

'marâtre Nature' retournera bien l'article puisque ces deux mots seront trouvés *dans cet ordre*

'Nature marâtre' ne retournera rien, car les deux mots ne figurent pas *dans cet ordre là* dans le texte...

C'est un bug on est d'accord ?

je passe...

8

Une confusion entre le concept des mots clés de SPIP et des keywords des balise meta ne serait pas étrangère à ce type de remarque. Ou l'utilisateur s'imagine que par un savant jeu de vases communicants, les mots clés de SPIP sont injectés dans google via cette fameuse balise keywords que plus aucun moteur de recherche descend n'utilise.

Aucun fond de vérité, mais une vraie légende, assurément.

<meta name="author" value="C&eacute;dric" />
<meta name='keywords' value="Montargis" />

9

J'ai fait le test aussi sans les mots clefs (avant de les avoir créés et utilisés ) c'est pareil, je voulais juste un test complet. C'est pas la faute aux mots clefs.....

Par ailleurs les mots clefs sont 'le' moyen (que j'ai trouvé) de créer des liens de structure entre les articles, je vois pas trop de moyen de s'en passer. Je ne pourrais pas m'en passer si j'utilise SPIP.

En fait je voudrais juste une confirmation de mon bug par les "pros" et savoir ce qui se passe dans ces cas là.

En général on fait un ticket là
http://trac.rezo.net/trac/spip/report/3
en créant un compte pour pouvoir faire un ticket

et un jour un codeur motivé corrigera.
ou pas (d'ici là la fonction peut être complètement revue, repensée, supprimée, déléguée à un service externe, remplacée par FullText ...)

Et quand le bug ne sera plus, le ticket sera fermé.
On reçoit une prime mensuelle fonction du nombre de tickets qu'on corrige, pour nous motiver ... :stuck_out_tongue:

J'ai l'impression que c'est pas un tout petit bug de rien du tout, en version 192 (je sais je radote) cette recherche fonctionnait.

Oui, tout a été refait pour supprimer l'indexation des contenus dans une table séparée avec des avantages (un article publié est immédiatement trouvable, suppression de la charge CPU de la tache d'indexation, charge CPU de la recherche à peu près identique etc ...) et quelques inconvénients. Tu viens d'en trouver un.

Contourner le pb avec fulltext ne peut être qu'un solution de secours en attendant de corriger non?

Ca n'est pas un contournement : FullText est une vrai amélioration de la fonction recherche qui permet en plus des opérateurs syntaxiques du genre

+café -marc "reveille matin"

Cédric

10

denisb a écrit :

la recherche ne 'revient pas en arrière' ; elle se fait dans l'ordre de lecture

mais pour retrouver
   soit 'nature'
   soit 'marâtre'
   soit et'nature' et 'marâtre'
et ce, quelle que soit leur position respective dans le texte :

saisir :
   nature>marâtre
dans l'input de recherche

(oui : on peut utiliser de pseudo regexp dans l'input...)

11

Mnfin ... avec le plugin fulltext on fait tout ce qu'on veut et en plus on peut se fabriquer ses propres filtres pour les boucles avec des expressions regulières même sans #RECHERCHE.

Par contre je me tape un coup de cafard quand je me souviens de la capacité des anciens SPIP en ce qui concerne l'indexation des documents joints et des pages html externes.

Est-ce c'est envisageable de réintroduire ces fonctions dans le core de SPIP 2.1 ou dans un plugin standard ? Sinon pourriez-vous m'indiquer où récupérérer les fonctions d'indexation et de recherche dans l'ancien code ? Pour moi la capacité de rechercher (et trouver) des textes dans les documents et pages externes constituait une des différences importantes entre SPIP. La seule chose qui manquait à ce système unique et super était la capacite d'avertir les auteurs quand le contenu d'une page externe était modifié.

merci pour vos infos,
klaus++

denisb schrieb:

12

Par contre je me tape un coup de cafard quand je me souviens de la capacité
des anciens SPIP en ce qui concerne l'indexation des documents joints et des
pages html externes.

C'est dans le répertoire extract/ du plugin Indexation, et en effet ça
mériterait d'être repris !

-- Fil

13

Si je ne m'abuse, cela plaçait une conversion texte du contenu des fichiers dans la table utilisée pour la recherche, table qui était dans le plugin Indexation mais n'est plus dans le plugin Fulltext, non ?

En tout cas ça m'intéresse, je serais peut-être amené à en avoir besoin prochainement, auquel cas je bosserais sur la migration de cette partie.

-Nicolas

14

C'est dans le répertoire extract/ du plugin Indexation, et en effet ça
mériterait d'être repris !

Si je ne m'abuse, cela plaçait une conversion texte du contenu des fichiers
dans la table utilisée pour la recherche, table qui était dans le plugin
Indexation mais n'est plus dans le plugin Fulltext, non ?

Il y a deux étapes : d'abord l'extraction du contenu, puis son
indexation ; dans extract/ ne figurent que les extracteurs,
c'est-à-dire les fonctions qui prennent un doc et renvoient son
"contenu" en texte. On trouve une de ces fonctions aussi
(extract/quark.php) dans le plugin "convertisseur", ce qui permet à ce
plugin d'importer (et non d'indexer) le texte d'un fichier quark.

L'indexation, ensuite, elle se fait soit en découpant ce contenu en
mots pour les tables spip_index (ancienne méthode), soit en recopiant
le contenu dans une table spip_indexation (méthode du plugin
"Indexation"), soit encore en recopiant le contenu dans un champ
"contenu" de la table spip_documents (méthode que je préconiserais
dans le cas du plugin Fulltext).

En tout cas ça m'intéresse, je serais peut-être amené à en avoir besoin
prochainement, auquel cas je bosserais sur la migration de cette partie.

OK dans ce cas je n'y touche pas.

-- Fil

15

C'est dans le répertoire extract/ du plugin Indexation, et en effet ça
mériterait d'être repris !

Si je ne m'abuse, cela plaçait une conversion texte du contenu des fichiers
dans la table utilisée pour la recherche, table qui était dans le plugin
Indexation mais n'est plus dans le plugin Fulltext, non ?

Il y a deux étapes : d'abord l'extraction du contenu, puis son
indexation ; dans extract/ ne figurent que les extracteurs,
c'est-à-dire les fonctions qui prennent un doc et renvoient son
"contenu" en texte. On trouve une de ces fonctions aussi
(extract/quark.php) dans le plugin "convertisseur", ce qui permet à ce
plugin d'importer (et non d'indexer) le texte d'un fichier quark.

OK.

L'indexation, ensuite, elle se fait soit en découpant ce contenu en
mots pour les tables spip_index (ancienne méthode)

Ca je connais, j'ai longuement épluché ce code à l'époque.

soit en recopiant le contenu dans une table spip_indexation (méthode du plugin
"Indexation")

Ce que j'avais vu.

soit encore en recopiant le contenu dans un champ
"contenu" de la table spip_documents (méthode que je préconiserais
dans le cas du plugin Fulltext).

OK, donc ceci reste à faire.

Mais j'ai dû louper une étape, pourquoi avoir mis de côté le plugin Indexation, au profit d'un plugin Fulltext qui fait en gros la même chose, extracteurs en moins ?

En tout cas ça m'intéresse, je serais peut-être amené à en avoir besoin
prochainement, auquel cas je bosserais sur la migration de cette partie.

OK dans ce cas je n'y touche pas.

OK.

-Nicolas

16

soit encore en recopiant le contenu dans un champ
"contenu" de la table spip_documents (méthode que je préconiserais
dans le cas du plugin Fulltext).

OK, donc ceci reste à faire.

Mais j'ai dû louper une étape, pourquoi avoir mis de côté le plugin
Indexation, au profit d'un plugin Fulltext qui fait en gros la même chose,
extracteurs en moins ?

En tout cas ça m'intéresse, je serais peut-être amené à en avoir besoin
prochainement, auquel cas je bosserais sur la migration de cette partie.

OK dans ce cas je n'y touche pas.

OK.

Où en es-tu de ce chantier Nicolas ?

+1 ?

-- Fil

17

Pas avancé, je suis sur CleverMail pour l'instant entre autres (toujours pas trouvé d'autre nom pertinent), mais je devrais m'y attaquer d'ici fin août.

-Nicolas