Ce plugin permet d’une part d’exploiter le mode de recherche FULLTEXT de MySQL en améliorant ainsi énormément les recherches par rapport au fonctionnement natif (et naïf) de SPIP, et d’autre part d’étendre l’indexation au contenu textuel des documents joints aux articles et/ou rubriques [1].
Indexation FULLTEXT
Performance
Sur une base de test comportant 200 000 articles, la vitesse de la recherche (hors rendu de la page, qui se fait à temps constant) passe de 5 secondes à 10 millisecondes ; sur deux mots, on passe de 15 secondes à 0,1 seconde.
Pertinence
Les résultats sont beaucoup plus pertinents, puisque si on tape deux mots (ou plus), le moteur FULLTEXT va trouver comme avant l’ensemble des articles contenant ces deux mots, mais attribuera un score plus important à ceux qui disposent de ces deux mots consécutifs. Ce score est comptabilisé par la balise #POINTS.
Fonctionnalité
Outre la recherche basique, le mode FULLTEXT permet d’utiliser des opérateurs logiques :
|
La casse (minuscule/majuscule) des mots recherchés est indifférente.
Les accents ne sont pas pris en compte (« déjà » ou « deja », retourneront à l'identique « déjà », « dejà », « déja »...) |
|
| Exemples d'utilisation | |
| ⇢ | Retourne les textes qui contiennent SOIT « enfant », SOIT « étranger », SOIT « enfant » ET « étranger ». |
|---|---|
| ⇢ | Retourne les textes qui contiennent « enfant » ET « étranger ». |
| ⇢ | Retourne les textes qui contiennent « enfant » mais présente en premier les textes qui contiennent aussi « étranger ». |
| ⇢ | Retourne les textes qui contiennent « enfant » mais PAS « étranger ». |
| ⇢ | Retourne les textes qui contiennent « enfant » ET « étranger » ou bien « enfant » ET « Asie » mais présente en premier les textes qui contiennent « enfant » ET « étranger ». |
| ⇢ | Retourne les textes qui contiennent « enfant », « enfants », « enfance », « enfanter », « enfantillage ».... (L'astérisque * doit être terminale ; ainsi « *fant » ne retournera rien.) |
| ⇢ | Retourne les textes qui contiennent exactement la séquence de mots « enfant étranger ». |
Remarque : ce tableau constitue le contenu de l’aide fournie dans ce plugin par la balise #AIDE_RECHERCHE.
Principe de fonctionnement
Concernant uniquement la partie mettant en œuvre l’indexation FULLTEXT, le plugin utilise ces deux fichiers :
- inc/rechercher.php est une amélioration du fichier du même nom livré avec SPIP. À chaque recherche sur une table, ce fichier vérifie la présence d’un ou plusieurs index FULLTEXT sur la table en question (ainsi que sur les tables qui lui sont liées par une jointure, voir ci-dessous).
- exec/fulltext.php vous propose de créer des index FULLTEXT sur la plupart des tables de SPIP. C’est une proposition, qui correspond aux usages les plus « normaux » de SPIP (pour aller plus loin, cf. ci-dessous, configuration avancée).
Jointures
Le moteur natif de SPIP gère les jointures entre les tables. Avec FULLTEXT on les gère aussi, mais à condition qu’il existe au moins un index FULLTEXT sur chacune des tables liées.
Ainsi par exemple, si vous avez un FULLTEXT sur spip_articles, un autre sur spip_mots, mais aucun sur spip_auteurs, une recherche sur les articles avec le terme « Italie » renverra les articles liés au mot-clé « Italie », mais une recherche sur le terme « Robespierre » ne renverra pas les articles signés par cet auteur.
Autrement dit, sauf application particulière, vous avez tout intérêt à passer l’ensemble des tables en mode FULLTEXT.
Indexation du contenu textuel des documents
Ce plugin propose en outre l’indexation (optionnelle) du contenu textuel des documents joints aux articles et/ou rubriques.
Il stocke pour cela dans la table spip_documents une version texte du document, obtenue à l’aide d’un « extracteur ». Cet extracteur peut être un exécutable système lancé depuis le plugin, ou du code purement PHP.
Les formats supportés à partir de la version 0.6.2 du plugin sont :
- Le PDF, à condition que le fichier ne soit pas protégé contre la copie
- Le DOC, PPT, et XLS
- Le DOCX, PPTX et XLSX (nécessite PHP 5.2 au minimum, ainsi que l’option -enable-zip)
- Le ODT (nécessite PHP 5.2 au minimum, ainsi que l’option -enable-zip)
Installation
Mise en place de l’indexation FULLTEXT
Une fois le plugin installé dans le répertoire plugins/ et activé à partir de la page « Gestion des plugins », la recherche fonctionne exactement comme avant. Pour l’installation proprement dite, il faut créer des index FULLTEXT sur les tables ; pour cela, il suffit de se rendre sur la page ecrire/?exec=fulltext, et de valider les opérations proposées.
On peut aussi, alternativement, les créer « à la main » à partir de n’importe quel client MySQL, avec les commandes suivantes :
ALTER TABLE spip_articles ADD FULLTEXT `titre` (`titre`);
ALTER TABLE spip_articles ADD FULLTEXT `tout`
(`surtitre`,`titre`,`soustitre`,`chapo`,`texte`,`nom_site`,`url_site`,`descriptif`);
Le mode FULLTEXT n’étant disponible que sur les tables au format MyISAM, il faut parfois au préalable convertir les tables dans ce format :
ALTER TABLE spip_articles ENGINE=MyISAM;
La page ecrire/?exec=fulltext permet aussi de faire cela.
Indexation du contenu textuel des documents
Pour l’indexation des documents, il faut installer certains logiciels additionnels, et indiquer leur présence au plugin via des constantes à définir dans le fichier mes_options.php ou en utilisant le panneau de configuration de l’indexation des documents sur la page ecrire/?exec=fulltext_document.
Le panneau de configuration de l’indexation des documents permet de gérer la configuration (extracteurs et options éventuels) pour les fichiers PDF, DOC, PPT, XLS, ODT, DOCX, PPTX et XLSX et d’activer ou non l’indexation de ceux. ceci remplace la définition des constantes dans le fichier mes_options.php.
Certaines constantes sont génériques, non liées au type de fichier :
_FULLTEXT_TAILLE: Taille maximum conservée (en nombre de caractères) pour la version texte des fichiers (50000 par défaut). Cette configuration est également disponible dans panneau de configuration de l’indexation des documents.- De même, il est possible de définir l’intervalle (en seconde) entre deux passages du Spip-CRON et le nombre de document traités par itération.
Pour indexer un type de document, il est obligatoire de définir une constante non-nulle de type _FULLTEXT_EXT_EXE (où EXT est l’extension de ces documents) ou d’activer l’indexation via le panneau de configuration.
Il faut également qu’un « extracteur » pour ce type de document soit disponible.
Pour les PDF
- Installer Xpdf
- sur Ubuntu,
- sur Mac OS X via MacPorts ou avec cette version compilée,
- ou sur d’autres OS
- Définir ces constantes :
-
_FULLTEXT_PDF_EXE(par exemple/usr/bin/pdftotext) : Chemin vers l’exécutablepdftotextdeXpdfafin de transformer les fichiers PDF en texte brut -
_FULLTEXT_PDF_CMD_OPTIONS(par exemple-enc UTF-8) : Options d’appel de l’exécutable
-
Pour les DOC, PPT et XLS
- Installer Catdoc
- Sur Ubuntu/Linux,
- Sur Windows
- Définir les constantes correspondantes (
_FULLTEXT_DOC_EXE,_FULLTEXT_DOC_CMD_OPTIONS, etc.) ou utiliser le panneau de configuration de la même manière que pour les PDF.- Exemples pour les DOC :
- Exemple pour utilisation en local sous Windows
define("_FULLTEXT_DOC_EXE","C:\catdoc\catdoc.exe"); - Exemple pour utilisation sous Linux :
define("_FULLTEXT_DOC_EXE","/usr/bin/catdoc"); - Exemple d’option pour extraction de DOC au format « Windows » vers format ISO-8859-1 :
define("_FULLTEXT_DOC_CMD_OPTIONS","-s cp1252 -d 8859-1 ");
- Exemple pour utilisation en local sous Windows
- Exemples pour les XLS :
- Exemple pour utilisation en local sous Windows
define("_FULLTEXT_XLS_EXE","C:\catdoc\xls2csvt.exe"); - Exemple pour utilisation sous Linux :
define("_FULLTEXT_XLS_EXE","/usr/bin/xls2csvt"); - Exemple d’option pour extraction de .XLS au format « Windows » vers format ISO-8859-1 :
define("_FULLTEXT_XLS_CMD_OPTIONS","-s cp1252 -d 8859-1 ");
- Exemple pour utilisation en local sous Windows
- Exemples pour les PPT :
- Exemple pour utilisation en local sous Windows
define("_FULLTEXT_PPT_EXE","C:\catdoc\catpp.exe"); - Exemple pour utilisation sous Linux :
define("_FULLTEXT_PPT_EXE","/usr/bin/catpp");
- Exemple pour utilisation en local sous Windows
- Exemples pour les DOC :
Pour les ODT, DOCX, PPTX, XLSX
- Les « extracteurs » utilisent des fonctions et des classes PHP fournit avec le plugin (nécessite PHP 5.2 au minimum, ainsi que l’option -enable-zip).
- Définir les constantes correspondantes (
_FULLTEXT_ODT_EXE,_FULLTEXT_DOCX_EXE, etc.) ou utiliser le panneau de configuration pour autoriser l’indexation. Il n’y a pas de binaire ou d’option à définir (mais si vous n’utilisez pas le panneau de configuration, une constante non-nulle doit être définie).
Documents protégés
Les documents PDF et XLS protégés ne seront pas indexé et se verront affecter le statut « ptg » dans la base de données.
Une page ecrire/?exec=fulltext_document_ptg permet d’obtenir la liste de ceux-ci.
Les documents PPT et PPTX protégés ne seront pas indexés et seront renvoyés comme erreur (statut « err »).
Les documents DOC, DOCX, ODT et XLSX protégés semblent être indexés.
Suivi
Analyse des recherches
Le plugin fait un suivi de ses opérations liées à la recherche dans tmp/recherche.log ; on voit les index FULLTEXT utilisés, le temps mis pour chaque recherche et le nombre de résultats, etc.
Exemple de log :
Mar 13 15:28:42 1.2.3.4 (pid 21184) fulltext article: titre, full2
Mar 13 15:28:42 1.2.3.4 (pid 21184) fulltext auteur: nom
Mar 13 15:28:42 1.2.3.4 (pid 21184) fulltext mot: titre
Mar 13 15:28:42 1.2.3.4 (pid 21184) MATCH(t.`titre`) AGAINST ('fluor dans l\'eau \"fluor dans l\'eau\"') * 3.1
+ MATCH(t.`surtitre`,t.`titre`,t.`soustitre`,t.`chapo`,t.`descriptif`) AGAINST ('fluor dans l\'eau \"fluor dans l\'eau\"') * 1.4
+ SUM(MATCH(obj1.`nom`) AGAINST ('fluor dans l\'eau'))
+ SUM(MATCH(obj2.`titre`) AGAINST ('fluor dans l\'eau'))
AS score
Mar 13 15:28:42 96.21.135.101 (pid 21184) recherche article (fluor dans l'eau) : 500 resultats 1.187s
Ce log indique que la table article a deux index FULLTEXT nommés titre et full2 ; que la recherche portant sur « fluor dans l’eau » donne un poids de 3,1 à la présence de ces mots dans le titre, 1,4 dans l’ensemble des champs, et 1 pour le nom d’un auteur ou d’un mot-clé lié par une jointure.
Analyse des extractions
Le plugin fait aussi le suivi des extractions de version texte des fichiers, dans tmp/extract.log.
La page de configuration du plugin ecrire/?exec=fulltext indique le nombre de documents indexés, en attente d’indexation, protégés ou en erreurs.
Configuration avancée des index FULLTEXT
Avec n’importe quel client MySQL (ou phpMyAdmin) vous pouvez aller modifier la structure des index pour affiner les réponses, en incluant ou en excluant des champs, selon vos usages.
Ceci est notamment à faire si vous utilisez Extras2 pour ajouter de nouveaux champs : il faut alors créer un index incluant ces champs, pour qu’ils soient cherchables.
Notre recommandation : supprimer le précédent index FULLTEXT de tous les champs standards, et recréer un index FULLTEXT intégrant les champs standards et les champs extras pertinents. Seuls les champs de type TEXT (ou LONGTEXT etc) peuvent faire partie d’un index FULLTEXT.
Il est aussi possible d’aller bidouiller à l’intérieur du fichier pour, par exemple :
Ajouter des pondérations aux différents index
Le code consiste en une somme des scores donnés aux articles par les différents index. La pondération par défaut est une fonction décroissante du nombre d’éléments dans l’index. Ainsi, si on a deux index sur une table, l’un portant sur le titre, et l’autre sur l’ensemble des champs texte de la table, les termes de recherche présents dans le titre auront un poids de 4 environ, tandis que les mêmes termes trouvés dans le texte ne vaudront que 1 point.
Si l’on veut modifier ces poids il est possible :
— soit de modifier cette fonction pour qu’elle soit plus (ou moins) fortement décroissante ;
— soit d’ajouter un système encore plus compliqué avec des options de configuration ;
— soit d’ajouter un index. Par exemple, pour survaloriser les champs surtitre, sous-titre et chapo par rapport au champ texte, créer un index FULLTEXT supplémentaire avec la commande ci-dessous :
ALTER TABLE spip_articles ADD FULLTEXT `titrailles`
(`surtitre`,`titre`,`soustitre`,`chapo`);
Cela dit, les réglages proposés par défaut marchent très bien pour nous, essayez-les :-)
Éliminer de la recherche tout un ensemble d’éléments
Scénario : notre base de données comporte toutes les archives d’un journal depuis 1920. Si l’on veut faire une recherche qui limite aux seuls articles récents, il n’est pas raisonnable de demander à inc/rechercher.php de ramener suffisamment d’articles pour ensuite en éliminer 90 % avec un critère {date>1980} dans la boucle. On peut alors envisager d’ajouter « en dur » un critère WHERE supplémentaire au niveau de la requête MySQL de inc/rechercher.php.
- pour ce faire, on pourra, par exemple, réduire le corpus de recherche pour la table spip_articles, en ajoutant dans mes_options.php une ligne :
define('_FULLTEXT_WHERE_article', ' t.date>"1980" ');
bien noter qu’il ne faut pas le ’s’ final dans le nom de la table, ainsi que l’utilisation des 2 types de quotes (’ et ") dans la définition de la clause WHERE.
Permettre à l’utilisateur de déterminer le corpus de recherche
On peut vouloir donner la possibilité à l’utilisateur de fixer la date de départ de sa recherche (lui permettre de ne chercher qu’à partir d’une date qu’il fixe lui-même).
Rien de plus simple.
- Commençons par ajouter un input dans notre formulaire de recherche (formulaires/recherche.html`) :
<input type="text" class="text" size="5" name="recherche_date" id="recherche_date"[ value="(#ENV{recherche_date})"] />
- Puis, dans notre fichier recherche_fonctions.php :
if ( _request('recherche_date') && preg_match('/\d{4}/', _request('recherche_date')) ) {
$limite = _request('recherche_date');
define('_FULLTEXT_WHERE_article', 't.date>"' . $limite . '"');
define('_FULLTEXT_WHERE_rubrique', 't.date>"' . $limite . '"');
define('_FULLTEXT_WHERE_document', 't.date>"' . $limite . '"');
}
Ceci limitera le corpus de recherche (l’ensemble des données dans lequel s’effectuera la recherche) pour les articles, rubriques et documents aux seuls éléments dont la date (en l’occurence l’année de publication) est strictement supérieure à celle fournie par l’utilisateur.
Étendre la recherche aux mots de 3 lettres
Par défaut MySQL FULLTEXT indexe les mots de quatre lettres ou plus. Pour étendre la recherche aux mots de 3 lettres ou plus, il faut modifier la config du serveur (/etc/mysql/my.cnf sous Debian), et ajouter les deux éléments suivants :
[mysqld]
ft_min_word_len=3
[myisamchk]
ft_min_word_len=3
Attention après avoir effectué cette manipulation il est impératif de reconstruire tous les index FULLTEXT de toutes les bases de données présentes sur le serveur, cf. http://dev.mysql.com/doc/refman/5.1....
Une méthode en ligne de commande (il faut être root) :
# /etc/init.d/mysql stop
Stopping MySQL database server: mysqld.
# myisamchk --recover /var/lib/mysql*/*MYI
... (quelques secondes ou minutes) ...
# /etc/init.d/mysql start
Fulltext et le plugin champs extras
Si vous avez crée des champs extras indexés.
Pensez à supprimer les index existants sur les tables où vous avez créés les champs pour ensuite les régénérer en incluant les champs nouvellement crées.
Exemples d’utilisation
Suggérer des réponses aux questions sur discuter.spip.net
Lire l’article « Forum.spip.org comme base de connaissances » sur SPIP Blog
et aussi
... à vous de jouer !
Discussions par date d’activité
106 discussions
Bonjour,
je viens d’installer fulltext version 0.6.4 sur un spip 2.1.10 (après une migration depuis spip 1.9.2, ça a peut-être son importance).
Quand je crée les index proposés par défaut, celui sur les auteur plante avec le message d’erreur :
Erreur 1283 de mysql : Column ’login’ cannot be part of FULLTEXT index
Après un coup d’oeil dans MySQL, je vois que le champ
loginest de type varchar. Or il est dit dans la doc que seuls les champs de type text ou longtext supportent la recheche fultext.J’ai donc créé mon index à la main en supprimant le champ
login:ALTER TABLE
site_lesia.spip_auteurs ADD FULLTEXTtout(nom,bio,email,nom_site,url_site)Et ça marche bien.
Y a-t-il des installation de SPIP où le champ
loginest de type text ?Répondre à ce message
Bonjour à tous !
J’ai installé Fulltext 0.6.2 sur un site SPIP 2.1.10 ( 1.9.2 à l’origine).
Aprés l’indexation depuis la page ecrire/ ?exec=fulltext, j’ai eu un message me disant quelque chose du genre ’le charset déclaré ne semble pas correspondre à celui de la base. Ceci peut entrainer des erreurs avec les caractères accentués’.
En effet une recherche avec ’+mot1sansaccent +mot1sansaccent’ marche et pas ’+mot1avecaccent +mot1avecaccent’...
Après quelques recherches, j’en ai conclu que c’était l’interclassement qui n’était pas bon : ’latin1_swedish_ci’ au lieu de ’utf8_general_ci’. J’ai donc changer l’intervclassement des tables et ça change rien... L’interclassement du contenu des tables est toujours en ’latin1_swedish_ci’, ceci expliquant sans doute cela !
Voici donc mes questions :
Est ce que tout mettre en ’utf8_general_ci’ réglera le problème ?
Si oui comment faire ?
Si non, est ce que quelqu’un à une solution ?
Merci d’avance de votre aide !
Gilles
Répondre à ce message
Bonjour,
lorsque je me rends sur la page ecrire/ ?exec=fulltext , je reçois le message d’erreur suivant :
Fatal error : Call to undefined function : fulltext_keys() in /homez.221/anciensh/www/plugins/auto/fulltext/exec/fulltext.php on line 77
Je suis sur Spip 2.1.10, avec du mysql 5 chez OVH.
Avez-vous une idée ? Merci,
Eric LM
Répondre à ce message
Bonjour,
j’essaie d’ajouter le champ « credits » des documents à la recherche.
j’ai fait la commande sql :
ALTER TABLE spip_documents ADD FULLTEXT
credits(credits) ;sur la page ecrire/ ?exec=fulltext je vois que le champ « credits » a bien été ajouté à l’index mais lorsque je fais une recherche publique j’obtiens des erreurs sql (ici pour la recherche sur « ronan ») :
vu mes connaissances limitées en sql j’ai sans doute fait une erreur quelque part...
dd
Répondre à ce message
Bonjour
je viens de faire l’installation en local avec spip 2.1.10 et le plugin fulltext
je veux faire des recherches dans des pdfs ajoutés à des articles.
Dans la table spip_documents il y a bien le contenu qui se rempli, donc ’mes options’ marche bien.
je voulais savoir s’il faut faire quelque chose de spécial pour avoir le résultat des recherches avec les documents ?
merci d’avance
Répondre à ce message
Bonjour à tous !
Je suis en spip 2.1.6 et j’ai installé le plugin. J’ai bien lu que le moteur ne prenait en compte que les mots de + de 4 lettres. Et pourtant on dirait qu’il marche même « trop » bien :
il prend en compte les mots de deux lettres comme « de »
Du coup on se retrouve avec des listes interminables de réponses dès qu’on tape une expression « alexa de paris »
Par contre ça fonctionne très bien quand on ne tape qu’un nom propre.
Répondre à ce message
Si j’ai bien compris xpdf c’est pour extraire le contenu d’un docs (pdf) pour faire une recherche dedans.
Je ne peux pas l’installé sur mon serveur. bref
Mais j’ai vu qu’on pouvais indexer : titres et descriptifs des documents....
Donc est il possible de pouvoir faire une recherche sur les documents grâce à leurs titres et à leurs descriptifs indexer ? Donc sans utiliser xpdf
Répondre à ce message
Bonjour,
Mon essai de fulltext sur un pdf (catalogue de pièces, 36 ko) est laborieuse et j’ai besoin d’aide.
J’ai installé Fulltext, juste là ... çà va...
Je n’ai pas vraiment saisi à quel endroit je dois installer Xpdf ? La doc mentionne ce chemin : /usr/bin/xpdf, mais n’ayant pas accès à ces dossiers sur mon serveur (sfr perso), j’ai créé un dossier à la racine de mon site (donc, au même niveau que /config ou /squelettes) que j’ai nommé xpdf. Du coup, me trompe-je si j’écris ceci dans mes_options.php ? :
Je suis allée voir dans la page du plugin et j’ai créé « tous les index suggérés » et comme j’avais ’err’ dans les champs ’Extrait’, j’ai cliqué sur « Réinitialiser l’indexation des documents en erreur ».
Malgré tout cela, une foulure à l’index et beaucoup de patience, les champs « contenu » de ma table spip_documents sont désespérément vides et « extrait » reste à « non ».
Il me semble donc que l’extraction ne se fait pas, mais pourquoi donc ?? Merci d’avance ;-)
Petite précision, il y a peut-être un pb de version. Dans Phpmyadmin, je lis ceci :
« Serveur : 10.111.145.45 via TCP/IP
Version du serveur : 5.0.32-Debian_7etch5-log
Jeu de caractères pour MySQL : UTF-8 Unicode (utf8) »
Debian, c’est Linux ? Quel fichier dois-je télécharger ? Je n’y comprends rien
Çà ne marche toujours pas. J’ai bien Xpdf installé (version pour Debian) mais malgré cela le contenu du pdf n’apparaît pas dans PhpMyAdmin et la colonne extrait indique « non », voire « err » parfois.
S’agit-il d’un pb d’hébergeur (SFR pages perso) ?
S’agit-il d’un pb de poids de fichier ? Toutes les pistes que je suis pour mon histoire de stock butent sur ce fichu pb de poids, de mémoire de calcul.
Est-ce que quelqu’un a une idée pour faire fonctionner Fulltext sur mon pdf ? Mille mercisssss.
Est-ce que par hasard tes PDF seraient protégés contre la copie ?
Je ne sais pas trop : il a été généré par OpenOffice. On voit çà comment ? Parce que dans les propriétés du fichier, rien n’indique une telle info.
Dans OpenOffice, le paramètre « Autoriser la copie de contenu » est bien coché.
Est-ce que dans
tmp/extract.logtu as le message « Erreur extraction PDF : Le fichier texte n’existe pas ou n’est pas lisible. » ?Est-ce que tu peux essayé d’exécuter directement
pdftotextsur ton fichier ?J’ai bien ceci dans mon extract.log
Echec de l’extraction de IMG/pdf/stock.pdf
Par contre, comment fait-on pour exécuter directement pdftotext ? question sans doute stupide... désolée !
Voici le contenu exact de extract.log :
J’ai copié le dossier Xpdf dans Program files, et j’ai essayé d’exécuter pdftotext depuis la commande exécuter ainsi :
« C :\Program Files\Xpdf\pdftotext.exe » « C :\Utilisateurs\MonNom\Dossier\STOCKBPMSITE.pdf »
Mais rien ne se passe ensuite : un fichier devrait apparaître, non ?
Ah, je ne savais pas que ça existe aussi pour Windows, je n’ai jamais testé.
Rien n’est indiqué dans le résultat de ta commande ? Aucun message ?
Non. Le pavé noir apparait 1/2 seconde et je ne vois rien arriver ensuite... Pff... pourtant, je fais des efforts !! Merci en tout cas, Nicolas...
Tu ne saurais pas répondre à mes pb d’itérateurs, par hasard ?!... Il s’agit sans doute d’une ligne de code toute bête, mais je n’ai aucune compétence (ou si peu) en php-sql. Cà me permettrait de laisser tomber fulltext et d’offrir un résultat de recherche plus complet.
Répondre à ce message
Bonjour,
Je suis avec intérêt le développement de ce plugin. Êtes-vous sur une piste pour permettre la recherche dans un document csv ? Parce que j’ai un stock de plus de 12000 pièces à afficher (sans gestion de boutique, juste l’affichage). Et comme j’utilise la fonction désormais intégrée d’affichage des csv dans les articles, ce serait l’idéal de pouvoir proposer une fonction de recherche dans ces docs, isn’t it ?
Merci et bon courage ;-)
Oui il suffirait d’ajouter un « extracteur » (une fonction PHP lisant le CSV et en extrayant le contenu textuel). C’est a priori assez facile car le texte est « en clair » dans les CSV.
Répondre à ce message
Bonjour,
et merci pour ce plugin.
Personnellement j’ai aussi du gérer ft_stopword_file pour adapter la recherche à mon contenu français. Dans sa version de base le moteur ne trouve pas, par exemple, le mot ’seven’ qui est un mot trop courant en anglais. En adaptant la liste des mots, on corrige ce problème.
ft_min_word_len=3
ft_stopword_file=/etc/mysql/stopwords.fr.txt
encore merci
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires :
|
