Nota SPIP-Contrib : Un plugin qui explore les évolutions du (des) moteur(s) de recherche de SPIP. Il faut bien prendre garde aux conditions de compatibilité définies ci-dessous.

À propos du plugin

 Il exploite le mode FULLTEXT SEARCH IN BOOLEAN MODE de MySQL, cf. http://dev.mysql.com/doc/refman/5.0...
 Avec ses extracteurs, ce plugin permet d’indexer les fichiers PDF etc.
 un tableau de bord exec=admin_index permet de voir la progression de l’indexation
 une balise #EXTRAIT permet d’afficher dans les boucles {recherche} un extrait du texte contenant les mots recherchés ; et cela y compris pour les documents indexés (PDF, rtf etc).

Conditions de compatibilité :
 SPIP SVN révision >= 10182 [1]
 MySQL >= 5 ? ou en tout cas 4 avec une option utf-8 (à préciser)

Installation

Ce plugin est encore en développement aussi vous pouvez le récupérer :
 soit via un client SVN, Plus d’explications ici
 soit au travers des paquets zip d’ensemble du site miroir > plugins/ plugins_stable.zip

L’installation se déroule ensuite comme pour tous les autres plugins, cf. http://www.spip.net/fr_article3396.html

Raccourcis de recherche

Recopier ici la doc de MySQL ; trouver une manière sympa d’expliquer les subtilités de la syntaxe :

 +Allô ; exiger le mot Allô ;
 -Allô ; refuser le mot Allô ;
 ~Allô ; minorer le score des articles contenant le mot Allô ;
 Allô Habibi ; les articles contenant Allô ou Habibi ou les deux mots ;
 "Allô Habibi" ; les articles contenant la phrase "Allô Habibi" ;
 (>Allô <Habibi) ; les articles contenant Allô ou Habibi, en privilégiant ceux qui contiennent Allô ;
 etc.

Fonctionnement

Chaque fois qu’un article est modifié, son texte, nettoyé des raccourcis typographiques (il y a un pipeline dédié, pour les plugins qui veulent en ajouter), est recopié dans la table spip_indexation. Les données associées (nom des auteurs, titre des mots-clés etc) sont recopiées aussi. On exploite ensuite une requête MySQL FULLTEXT pour fouiller cette table spip_indexation

TODO

 proposer une balise #EXTRAIT qui afficherait un extrait pertinent (on l’a dans spip_indexation).
 rétablir les fonctions de configuration de l’indexation (recherche avancée, indicazzione tabelle) ; la structure de ce qu’on met dans spip_meta est identique à celle d’avant (bien qu’on n’utilise plus les poids, du moins pour le moment), ça devrait faciliter le retour de ces fonctions
 dans admin_index lister toutes les table éventuellement indexables avec une case à cocher
 retomber sur la recherche inc/rechercher pour les tables non indexées (ex : spip_syndic_articles)
 optimiser en supprimant les spip_indexation liés à des objets disparus
 indexer à part le titre et les meta-infos (surtitre, mots liés...), noter la date de l’objet
 mode d’indexation à l’ancienne (mots, dico etc) ??
 repérage automatique des incompatibilités
 indexer des articles de plusieurs sites SPIP avec le mode « distant » des connexions bases de données
 pour la balise #EXTRAIT :

• si on donne deux mots, ne pas donner deux extraits si le second mot est dans l’extrait du premier
• si on recherche "x y", surligner sans se faire manger par le "
• ne pas couper les mots salement ("ampoule" => "poule")

 autres...

Note sur les jeux de caractères

Pour que le mode FULLTEXT de MySQL fonctionne bien, et gère proprement les accents, il faut absolument que la base elle-même sache qu’elle contient de l’utf-8. Or SPIP a longtemps été « sale » de ce point de vue, et les anciennes bases conservent un héritage où les tables contiennent de l’utf-8, mais croient qu’elles contiennent de l’iso-latin-swedish (jeu de caractères standard de MySQL).

Donc, pour que ça fonctionne vraiment, il convient d’exécuter ecrire/ ?exec=convert_sql_utf8

ATTENTION À FAIRE UN BACKUP AVANT

Il est possible qu’il faille ensuite demander une réindexation complète du contenu, cf. la page exec=admin_index

Sur un serveur de tests (MySQL un peu vieux : version 4.0.26-standard), j’ai un message d’erreur « Le charset SPIP actuel utf-8 n’est pas supporte par votre serveur MySQL ».

Remarque sur les performances

Ou : « du bon usage du plugin indexation »

D’un côté :
 le moteur de recherche qui attaque directement les tables marche, selon mes tests, aussi bien que l’ancienne indexation des mots. Il économise aussi une grosse tâche cron et beaucoup de données en base. Donc moins de choses à charger en RAM par le serveur, donc moins souvent des requetes qui mettent 2 minutes à arriver, moins de swap etc.

De l’autre :
 la nouvelle indexation crée et remplit une nouvelle table spip_indexation, en y collant une copie (nettoyée) des données textuelles de toutes les tables. Avec l’index FULLTEXT en sus, ça occupe environ deux fois la taille des données. Et rajoute une tâche cron (plus légère que l’ancienne). On ne peut pas penser que ça n’a pas d’impact en termes de perfs (si on a peu de RAM par exemple). Mais en contrepartie les recherches se font à la vitesse de l’éclair, puisque faites « nativement » par le moteur de MySQL. Donc une petite perte à chaque hit normal, et un gros gain à chaque recherche.

À partir de là il faut voir ce qu’on veut. Pour un petit site je pense qu’il n’est pas nécessaire d’utiliser Indexation, la recherche « bête » est suffisante. Pour un gros site où la recherche peut retourner des centaines de documents, ou si on veut indexer des PDF, etc, ça vaut le coup de se charger de cette complexité supplémentaire. Et si on a des millions de documents, il faut probablement encore autre chose.