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
Merci pour avoir développé cet outil et l’avoir partagé. Ma question est honteusement basique mais merci d’avance à quiconque voudra bien m’éclairer. L’installation des logiciels complémentaires de lecture/extraction de pdf tel que XpdfReader doit se faire sur le serveur, via le sous-répertoire proposé usr/bin/pdftotext. Dans quel répertoire racine doit-on créer ce répertoire pour y placer le logiciel ? Dans /htdocs qui contient tous les répertoires du site spip, ou en amont (/vhosts) ou carrément dans /lamp0 ? Désolée de cette question basique...
Bonjour,
Avez vous trouvé une solution depuis la publication de votre message ?
Merci d’avance
Gabin
Bonjour,
Même sujet. Mon site est hébergé chez un hébergeur classique mutualisé (en l’occurrence O2Switch). Dans ce cas, est-il possible d’installer Xpdf, dans un répertoire /lib/ à la racine du site par exemple ? Et si oui, quel serait le chemin à stipuler dans les paramètres de FullText ? public_html/lib/ ?
Merci !
Répondre à ce message
Bonjour
Je viens d’installer le plugin FullText 1.2.0 sur un SPIP 3.0.16.
J’ai installé les index comme le suggère le plugin (pour le moment uniquement spip_article). La bdd est bien à jour avec les 2 index créés (« titre » et « tout »).
Dans mon squelette « recherche.html », j’ai la boucle suivante :
Le plugin Fulltext n’a aucun effet sur cette boucle. Quand je regarde en debug, la requête SQL est toujours celle qui va chercher dans le hashcode dans la table « spip_resultats ».
Que faut-il faire pour que le plugin Fulltext soit déclenché ?
Merci pour votre aide.
Répondre à ce message
Je lis ici « 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 : »
Mais alors pourquoi y-a-t-il un bouton « convertir en InnoDB » pour chaque table listée sur la page ?exec=fulltext&ok=index de la table régénérée ?
Merci
les dernières versions de mysql/mariadb permettent fulltext sur innodb. Du coup je me demande si le plugin devrait pas évoluer pour cela.
Bonjour,
Comment exploiter FullText avec des tables au format InnoDB svp ?
Bonjour,
Le plugin fonctionne déjà sans problème avec des tables InnoDB.
Répondre à ce message
Bonjour
Avec Spip 3.2.9 et Fulltext 2.0.1
Lorsque je veux créer l’index « tout » pour les articles, j’obtiens un message d’erreur :
La recherche sur les articles est donc limitée aux seuls titres, alors que j’aimerais bien ajouter au moins le texte.
J’avais échangé sur la liste users mais pas ici.
Le pb est résolu : dans ma table « articles », j’avais un mélange d’interclassements différents selon les colonnes. C’est réglé en passant toutes les colonnes en utf8_general_ci.
Répondre à ce message
Quelquechose m’échappe.
Comment fonctionne l’indexation des documents.
Il semble qu’il faille installer un logiciel sur son ordinateur ?
cela signifie t’il que chaque rédacteur doit installer ce logiciel sur son propre ordi ?
Il faut installer les exécutables qui permettent les conversions de PDF, ODT, DOC... sur le serveur (l’ordi qui fait tourner SPIP) puisque c’est sur ce dernier que seront les fichiers à indexer.
Bonjour,
Pouvez vous m’indiquer comment installer pdftotext sur un site SPIP installé sur windows ?
J’ai le message quoique j’essaye : « Ce logiciel n’est pas disponible sur le serveur »
Merci d’avance
Gabin
Répondre à ce message
Très bon plugin.
quelques remarques :
- le plugin ne traite pas les images, donc il faudrait retirer les images des erreurs d’indexation,
- j’ai des documents html, il ne les traite non plus, là il pourrait le faire
- si on pouvait visualiser les documents Indexés, Non-indexés, Protégés, En erreur d’indexation, ça éviterait d’aller sur regarder la base de donnée.
A par ça c’est super
Répondre à ce message
Magnifique plugin permettant notamment d’indexer les pdfs et donc de rechercher dans les documents publiés.
Un soucis cependant avec la balise #AIDE_RECHERCHE que j’avais bêtement disposée dans le squelette en dessous du formulaire recherche.
La balise insert effectivement le ficher prévu : aide_recherche.html. Mais ce fichier est une page html complète avec doctype, head et body. L’insertion de cette balise provoque alors des défauts d’affichage de la page où l’on a disposé cette balise ; deux doctypes dans la même page html c’est toujours un de trop.
Je suggère donc soit de modifier le fichier aide_recherche.html pour qu’il puisse s’insérer normalement comme un bout de code dans un squelette, soit d’avertir les utilisateurs du plugin de l’usage inédit de cette balise.
Cordialement, Yanic Gornet
Répondre à ce message
Bonjour,
Il semblerait que fulltext ne prennent pas en compte les rubriques sans objets (article, document, ...) même en forçant les recherches via le paramètre « tout » dans les boucles de recherche. Est ce normal, y a t-il un contournement possible ou une possibilité de forcer la recherche ?
Merci à l’auteur et tous ses contributeurs.
++
Répondre à ce message
Idée d’amélioration pour aider à mieux trouver ce qu’on cherche :
D’où la suggestion suivante : ordonner les 322 résultats en priorisant ceux correspondants à la requête exacte, suivis des autres.
Répondre à ce message
Bonjour,
Les dernières version d’innoDB permettent d’utiliser le FullText.
Comment l’utiliser dans ce plugin svp ?
Merci
Répondre à ce message
Yop,
si je comprend bien la modif de https://zone.spip.org/trac/spip-zone/changeset/104831/_plugins_/fulltext
…il suffit de mettre dans mon fichier mes_options.php la ligne
et hop, j’ai ma recherche sur le terme « nano » qui devient automatiquement équivalente à « nano* » (nanometre, nanotechnologie, etc.) ?
oh yeah :)
Répondre à ce message
Bonsoir,
Suite à différents tests nous avons remarqué que l’exclusion de ’étranger’ dans une recherche full text du type ’+enfant -étranger’ n’était plus prise en compte dans les résultats en dessous d’un certain indice de pertinence. Nous avons donc quand même des résultats avec ’étranger’ quand l’indice de pertinence est < ou = à 10.
Dans l’aide de Full Text il est pourtant indiqué : " Retourne les textes qui contiennent « enfant » mais PAS « étranger »."
Est-ce normal ?
Une idée sur la façon de modifier/corriger ce comportement ?
Merci d’avance
Répondre à ce message
J’ai essayé d’ajouter la recherche fulltext sur les zoteros de zotspip.
J’ai fait un mini plus gin pour cela avec l’appel d’un pipeline :
J’ai pu générer les indexes...
J’ai fait cette boucle :
Mais les résultats ne collent pas...
J’ai trouvé un fichier log fulltext.log dans tmp/log :
Je ne comprend pas trop ce qui se passe....
Est ce que quelqu’un aurait une idée, une piste ?
Merci d’avance !
Bonjour à tous !
Finalement, nous travaillons sur le plugin zotero pour le faire évoluer.
Nous avons résolu le problème des jointures.
J’ai trouvé la piste ici : http://code.spip.net/fr/archives/plugins-7/article/declarer-et-ajouter-des-tables
La partie intéressante est celle-là :
$join_nouvelletable = array(
« id_article » => « id_article »
) ;
$tables_principales[’spip_nouvelletable’] = array(
’field’=>&$nouvelletable,
’key’ => &$cles_nouvelletable,
’join’ => &$join_nouvelletable,
) ;
Pour la table zitems, j’ai écris
$join_zitems = array(
« id_zitem » => « id_zitem »
) ;
$tables_principales[’spip_zitems’] = array(
’field’ => &$zitems,
’key’ => &$zitems_cles,
’join’ => &$join_zitems,
) ;
J’ai suivi ce principe sur les autre tables.
Donc maintenant, les références zotero s’affichent bien dans l’espace privée et nous pouvons faire des jointures dans les boucles de la partie publique.
Par contre, les résultats de la recherche fulltext ne sont toujours pas pertinents...
Est ce que quelqu’un aurait une idée ? Une piste à creuser ?
Merci d’avance de votre aide.
Répondre à ce message
Bonjour,
Les documents images sont en erreur d’indexation, ce qui me parait normal.
Donc, ils ressortent dans le total des documents en erreur.
N’y a t-il pas possibilité de les sortir de ce décompte ?
Merci d’avance et bravo pour ce plugin !
Répondre à ce message
Je tente de faire une recherche fulltext sur les objets du plugin zotspip.
J’ai déclarer table et jointure via pipelines :
J’ai fait la conversion des tables avec l’outil fourni avec Fulltext dans l’espace privé de spip.
Mais ma boucle spip spip ci-dessous ne sort rien...
Vous pouvez prendre votre temps pour répondre, je suis en vacances à partir de maintenant !
Ceci dit, merci d’avance de vos réponses !
Répondre à ce message
Bonjour
Je viens d’installer Fulltext. Tout fonctionne bien sauf... qu’il ne trouve jamais Olympic marina (ou olym* ou toute autre combinaison) sur mon site
guidemediterranee.com
Olympic marina est en chapo et « dépend » de Lavrion.
Il existe un Lavrion (titre) et un Lavrion - Olympic marina (titre + chapo)
Une recherche sur Lavrion ne donne que Lavrion et pas les deux entrées.
Je ne comprend vraiment pas pourquoi (alors que Athenes donne bienb tous les Athènes)
Merci d’un essai d’explication
ADB
Je me réponds à moi-même...
Désolé pour le bruit : il s’agissait simplement d’un problème de mot clé dans le fichier Recherche.html.
Tout est parfait
Merci pour ce plugin
Répondre à ce message
Bonjour
Gros problème de restauration de la base, ça semble venir du plugin Fulltext.
Ma base est en mysql.
Lorsque je veux restaurer la base sauvegardée via le menu maintenance de Spip, toutes les tables sont en échec.
Lorsque j’exporte, puis réimporte via phpmyadmin, j’ai l’erreur suivante :
#1064 - You have an error in your SQL syntax ; check the manual that corresponds to your MySQL server version for the right syntax to use near ’TYPE=MyISAM AUTO_INCREMENT=558’ at line 44
Ma config :
SPIP 3.0.16
Fulltext 1.1.8 à jour.
Merci pour votre aide.
Répondre à ce message
Avec SPIP 3.0.17 et Fulltext 1.0.2 la recherche sur le mot « this » ne donne rien.
Ce mot fait référence à un auteur qui s’appelle « Hervé This ».
J’arrive bien à trouver des auteurs dont le nom est en 4 lettres par ailleurs.
Avez-vous une idée sur l’origine du problème ?
Sur SPIP 3.0.21 avec Fulltext 1.1.8, testé sur deux sites
la recherche ne prend pas en compte certains mots comme
- this
- the
- new
Cela ressemble à des mots clés qui ne seraient pas pris en compte ?
Des idées ?
je précise que j’ai bien activé l’astuce pour étendre la recherche sur 3 lettres.
Solution trouvée par Nicod_
Il existe un dictionnaire de mots ignorés par défaut (stop words).
La requête…
… doit afficher ’built-in’
La liste par défaut (built-in) est celle-ci :
http://dev.mysql.com/doc/refman/5.5/en/fulltext-stopwords.html
Il faut alors modifier la config du serveur Mysql ( my.cnf) et lui indiquer dans la section [mysqld] :
À utiliser si c’est vraiment nécessaire, car cela peut augmenter le « bruit » dans les résultats.
Répondre à ce message
Bonjour,
Je voulais juste signaler que le plug-in ne fonctionne pas quand la base de données du site a été conçu en Sqlite !
Merci !
Bonjour,
Je pense que j’ai le même problème mais je ne sais pas ou trouver le format de ma base.
Le plugin me dit de convertir en UTF8 mais lorsque je clique sur ce lien j’ai l’erreur : « Fichier convert_sql_utf8 introuvable »
dd
Ce fichier est dans le plugin « grenier ».
Trouvé, merci.
Pour un site cela a fonctionné, pour un autre non je me retrouvais avec du contenu invisible dans l’espace public ET privé dès lors qu’il y avait un caractère accentué. J’avais déjà essayé avec Fusion de convertir sqlite en mysql sans succès. Je réessaierai un jour.
dd
Re,
Pour ceux que ca intéresse, j’ai publié sur un autre forum une solution assez simple pour convertir une base de donnée sqlite vers mysql :
http://forum.spip.net/fr_213057.html
J’espère que ca aidera.
Répondre à ce message
Bonjour,
Merci pour ce plugin. J’ai juste 1 remarque et 1 bidouille.
Il me semble qu’il y a une différence entre le fonctionnement avec et sans index sur le pluriel des mots. Sans index la recherche sur « enfant » apportera aussi les articles avec le pluriel « enfants ». Ce n’est pas le cas avec fulltext. Y-a-t-il moyen de systématiquement faire ajouter à la requête une astérisque à la fin des termes sauf si l’on a mis des guillemets, pour une recherche sur un mot ou une expression précise ?
Je n’ai pas réussi à faire fonctionner l’extraction de texte des pdf. Je suis sur un Windows, SPIP et plugin à la dernière mode. Comme je ne publie pas chaque jour des brassées de pdf, j’ai contourné en le faisant à la main. J’ai ajouté avec le plugin champ_extra un champ à la table document et j’y fais un copier coller du texte en allant le chercher sur le pdf sans autre manoeuvre que CRTL+A puis CRTL+C. C’est pas cher et ça fonctionne... :-)
Bon, c’est le même comportement sur contrib.spip et spip.net.
Sur contrib, si on cherche « fulltex » cela ne retourne rien, il faut ajouter l’astérisque pour avoir des résultats.
Le tableau d’exemples devrait illustrer ce point (ou plutôt cette étoile :) ).
Répondre à ce message
Bonjour.
Impossible pour moi de faire une extraction de PDF, le plugin m’indiquant que pdftotext n’est pas disponible sur le serveur (CentOS 6.5), alors que le binaire est présent (testé également en indiquant en dur le chemin du binaire dans mes_options.php).
pdftotext provient du paquet poppler.x86_64. Je précise que l’extraction fonctionne en console (loggué sur le serveur, user non root).
Les droits d’éxécution (sudoers) ont été vérifiés et ne semblent pas poser problème
Les logs extract.log et prive_extract.log ne sont pas très explicites et indiquent juste une erreur d’extraction, ex :
Oct 02 15:16:45 une_adresse_ip (pid 21566) Indexation de pdf/16_mai_2013.pdf
Oct 02 15:16:45 une_adresse_ip (pid 21566) Extraction PDF avec /usr/local/bin/pdftotext -enc Latin1 IMG/pdf/16_mai_2013.pdf
Oct 02 15:16:45 une_adresse_ip (pid 21566) Erreur extraction IMG/pdf/16_mai_2013.pdf (code 127) :
SPIP - v2.1.26
Plugin FullText - v0.8.2
Merci d’avance de votre aide.
Moi je pense que l’auteur aurait du utiliser le fonction File_exists de php. Ca sert à rien de lancer un exec sur un fichier par exemple dans windows Ca ne fonctionne pas la majorité du temps.
Répondre à ce message
Fixer une date de départ (cf §Permettre à l’utilisateur de déterminer le corpus de recherche)
Sur un SPIP 3.0.17, il semble qu’il y ait un problème avec la fonctionnalité décrite (limiter la recherche aux « objets » dont la date est postérieure à l’année saisie)
J’ai modifié le formulaire recherche de la dits tel que décrit.
(ici : spip.php ?page=recherche&recherche=semis+direct&recherche_date=2015
voir copie d’écran (j’ai mis des
[<pre>#SQUELETTE : (#ENV**|unserialize|print_r{1})</pre>]dans le squelette appelant et en tête du fichier du formulaire de recherche pour voir ce qu’il se passait)Bien sûr, la limitation de date souhaitée ne fonctionne pas.
Quelque chose que j’ai mal fait ? Un oubli dans la doc ?… Un bug ?
Répondre à ce message
Le plugin marche très bien avec SPIP v3.0.15. J’ai juste eu la petite surprise de constater que les recherches sur un seul mot ne donnaient parfois pas les mêmes résultats suivant la syntaxe de la recherche :
- un seul mot de de 3 lettres (j’ai étendu la recherche aux mots de 3 lettres tel qu’indiqué dans la documentation) : abc se comporte comme abc*. « abc » et +abc ont le comportement attendu. Pour corriger ce problème, j’ai rajouté des guillemets avant l’appel du plugin dans ce cas. Ça marche, mais s’est franchement sale :)
- un seul mot de 1 ou 2 lettres : même soucis que précédemment sauf que ce n’est pas vraiment gênant. « ab » et +ab ne sortent aucun résultat, ce qui est attendu.
- le ranking pour les mots de 4 à 7 lettres est différent que la recherche soit mon_mot ou +mon_mot (ou « mon_mot »). Je n’ai pas analysé en détails mais il me semble à première vue que le résultat attendu est obtenu avec le + ou les guillemets.
De plus n’y aurait-il pas un soucis avec le caractère ’è’ ? La recherche est indépendante des accents (et marche même avec ’œ’) mais le ’è’ semble devoir être présent dans le champ de recherche pour qu’elle aboutisse correctement. Ce n’est pas dramatique en pratique car de toutes façons les utilisateurs tapent les accents dans le champ de recherche. C’est juste bizarre...
Enfin, une petite requête : ne serait-il pas judicieux que la recherche ait un « mega-boost » lorsque le champ entier indexé est égal à la requête ? Par exemple, je rêve que si la base contient un article dont le titre est Fulltext et que la requête est fulltext, la recherche le sorte premier haut la main devant d’autres articles dont le titre est Fulltext marche très bien ou La recherche fulltext est active. Ce n’est peut-être pas possible, mais ce serait pratique.
Répondre à ce message
Bonjour,
Sur un site en SPIP 3.0.17 [21515] avec Fulltext Version :
0.8.2 SVN [82959] activé
j’ai une erreur lors de la recherche sur le site public :
1 Erreur SQL 1146
Table ’site.spip_giss_articles’ doesn’t exist
SELECT t.id_article, t.surtitre, t.titre, t.soustitre, t.chapo, t.texte, t.ps, t.nom_site, t.url_site, t.descriptif, MATCH(t.
titre) AGAINST (’ssr*’ IN BOOLEAN MODE) * 8 +...
/ /
2 Erreur SQL 1146
Table ’isite.spip_giss_rubriques’ doesn’t exist
je vois qu’il y a un « s » en trop à gis mais je ne sais pas où le corriger
merci
dd
Bonjour
Même problème depuis la maj du plugin. Quelqu’un a-t-il trouvé l’origine du bug ?
Répondre à ce message
Bonjour,
tout d’abord merci pour votre plugin.
J’ai bien intégré les éléments mais une chose curieuse se produit.
Quand je recherche des termes ainsi qu’a partir d’une date (comme le cite votre explication), cela fonctionne mais si je change la date à nouveau, ça ne le prend plus en compte. Par précaution, j’ai désactivé le cache. C’est très aléatoire. je n’ai plus d’idées.
Avez vous déjà constaté ce comportement ?
merci d’avance.
Répondre à ce message
Merci à Leam ! Effectivement lorsque l’on fait comme dit : « En créant tous les index (à la fin de la page configuration) le problème » Le bug table spip_paquets_plugins doesn’t exist (et autres tables... suivant le splugins installés) disparait de l’admin ! ouf !
Répondre à ce message
Bonjour ,
Je voudrais pouvoir faire une recherche sur les albums, plugin albumV2.
j’ai ajouté dans inc/rechercher.php : pipeline(’rechercher_liste_des_champs’ ... ’album’ => array( ’titre’ => 8, ’descriptif’ => 5
?exec=fulltext ,
PhpMyAdmin : j’ai donc une table blop_albums (pas spip_albums) en MyIsam ,
a été créé un index fulltext sur le champ titre :
NomIndex|Type|Unique|Compressé|Colonne|...
titre|FULLTEXT|Non|Non|titre|1| |Non|
mais le type du champ texte est varchar(255) ! et non pas « text » est-ce cela qui peut bloquer ?
La doc disant « Seuls les champs de type TEXT (ou LONGTEXT etc) peuvent faire partie d’un index FULLTEXT » j’imagine que de de là peut venir le problème !
si oui, est-ce que je peux convertir sans risque pour le fonctionnement du plugin album ?
j’ai passé le champ titre de la table _albums en type TEXT , mais ça n’a aucun effet, pas de recherche sur les albums ... vous auriez une idée ?
point étonnant (si lier...) : c’est que la recherche sur les albums dans l’espace privé est maintenant parfaitement opérante et efficace. Mais du côté public, niet.
pour préciser le pb :
- sur ecrire/ ?exec=fulltext j’ai bien album (22262) , l’index ’titre’ créé
- rien dans tmp/recherche.log pour album
j’ai essayé de supprimer recréer les index fulltext via phpmyadmin et ecrire/ ?exec=fulltext sans résultat. Si qcq’un avait une idée à me suggérer ...
il suffisait d’ajouter dans le squelette recherche.html :
;o)
8 mois que je (re)cherche la solution du pb dans recherche.php, les pipelines, les fct° php, phpmyadmin ...
Pour les nuls comme moi ... ça vaut sans doute le coup de le mettre dans la doc
La Recherche en SPIP est expliquée dans la doc. officielle,
mais d’après ce que je comprends de ta recherche,
c’est http://spippourlesnuls.fr/ ?rechercher-dans-un-site-spip que tu aurais voulu ?
N’hésite pas a me renvoyer des demandes plus précises..
Cdlt
YannX
Répondre à ce message
Bonjour,
J’ai un petit souci avec Fulltext, j’ai créé un objet éditorial (via le plugin Fabrique), cet objet me permet d’étendre les auteurs SPIP (en ajoutant un tas de champs), je souhaite donc effectuer des recherches sur cet objet éditorial, malheureusement le formulaire de recherche ne remonte que ce qu’il trouve dans la table auteurs en ignorant la jointure sur profils
- Dans mon theme (un plugin), j’ai bien ajouté dans paquet.xml un « utilise » sur Fulltext
- J’ai bien créé l’indexation de mon plugin via ?exec=fulltext
- j’ai surchargé inc/rechercher.php en ajoutant ma table et les pondérations sur les champs
- J’ai bien ajouté ces mêmes champs dans mon plugin dans base/profil.php > fonction profil_declarer_tables_objets_sql dans « rechercher_champs »
Visiblement ma recherche tape toujours dans la table auteurs mais pas dans profils...
Any idea ?
Merci d’avance !
Bonjour,
je rencontre la même difficulté pour le plugin album V2
- j’ai pour album l’index ’titre’ créé via ?exec=fulltext
- j’ai surchargé inc/rechercher.php en ajoutant album et les pondérations sur les champs
par contre
- j’ai pas ajouté dans le paquet.xml de album un « utilise » sur Fulltext (je peux essayer si vous me précisez ce qu’il faut ajouter)
- j’ai pas ajouté dans base/profil.php > fonction profil_declarer_... (?..) (idem ...)
dans l’espace privé la recherche est parfaitement opérationnelle
sur le site public pas de recherche sur les albums !
recherche.log :
dans espace privé :
sur site public :
etc. (30 ligne aucune album)
Bonjour,
venant de résoudre mon pb je me demande s’il pourrait éclairer le votre.
Ajouter comme je l’ai fait une boucle pour auteurs ou pour profils dans recherche.html n’est sans doute pas la solution. Un problème de jointure ...
je vois dans le plugin albums dans base/albums.php ces lignes en plus dans fonction albums_declarer_tables_objets_sql :
si ça vous « parle » et peut vous aider
Répondre à ce message
Bonjour,
Ma configuration :
- spip 3.0.17 en utf-8
- plugin fulltext 0.8.2
- mysql 5.5.38 utf-8
Après avoir indexé tous les index suggérés, j’obtiens le message en bas de la page :
Quand je clique sur le lien « convertir en UTF-8 pour restaurer la cohérence », il m’envoie à la page
ecrire/?exec=convert_sql_utf8qui n’existe pas.J’obtiens le message d’erreur :
Alors j’ai installé le plugin grenier qui propose le script
ecrire/?exec=base_convert_sql_utf8(et nonecrire/?exec=convert_sql_utf8).Il faudrait peut-être adapter le plugin fulltext pour spip3.0 :
ecrire/?exec=base_convert_sql_utf8en cas d’incohérencebien à vous,
Répondre à ce message
bonjour
idem,
la recherche ne se fait plus que sur le champ titre malgré la reconstruction des index. Je ne sais pas depuis quelle version c’est comme celà
La version 0.8.1 corrige un gros bug, ça devrait aller mieux !
impeccable
merci
Répondre à ce message
Bonjour,
depuis la mise à jour vers la version 0.8.2, j’ai un message d’erreur lorsque j’utilise le moteur de recherche dans le back-office :
Invalid argument supplied for foreach() in /plugins/auto/fulltext/v0.8.2/inc/recherche_to_array.php on line 68Voir également la copie écran ci-jointe.
Je précise que cette erreur ce produit avec la config suivante :
- SPIP 3.0.16 ;
- uniquement le plugin Fulltext V.082 activé ;
- le répertoire /squelettes mis en berne.
Cheers
Répondre à ce message
Bonjour,
Quand je fais une recherche depuis l’interface privée de SPIP 3.0.5 avec le plugin Fulltext installé (v0.8.2) j’obtiens une erreur SQL :
Erreur SQL 1146
Table ’namesite.spip_paquets_plugins’ doesn’t exist
SELECT id_plugin,id_paquet FROM spip_paquets_plugins WHERE 0=1
Ainsi que des warning php :
Warning : Invalid argument supplied for foreach() in www/plugins/auto/fulltext/v0.8.2/inc/recherche_to_array.php on line 68
Warning : Invalid argument supplied for foreach() in www/plugins/auto/fulltext/v0.8.2/inc/recherche_to_array.php on line 260
Mais tout en bas de la page, les résultats s’affichent, après une dizaine de pages écrans de warning php.
Si je désactive Fulltext cela fonctionne correctement.
Par contre, le plugin donne de superbes résultats sur le site public.
Une idée ?
Merci d’avance.
J’ai rencontré le même problème et donc bricolé de plugin :
J’ai ajouté une condition ligne 29 de inc/rechercher.php
Bonjour
En créant tous les index (à la fin de la page configuration) le problème disparaît
Répondre à ce message
Bonjour,
Après une mise à jour de ma base en UTF-8, l’installation du plugin Fulltext et la création des index (depuis le plugin), plus aucun résultat ne s’affiche en lançant des recherches dans le moteur interne ou public.
C’est un peu la panique...
Avez-vous une idée d’où cela pourrait venir ?
Merci beaucoup.
Bonjour,
Je rencontre toujours ce problème : quand le plugin fulltext est activé, le moteur ne renvoie aucun résultat lors d’une recherche. J’ai passé toutes les tables en mode fulltext et quand le plugin est désactivé la recherche renvoie bien des résultats...
Sauriez-vous d’où peut venir le problème ?
Merci d’avance.
Même chose pour moi : quand le plugin Fulltext est activé, la recherche ne fonctionne pas.
La version 0.8.1 corrige un gros bug, ça devrait aller mieux !
Merci Cédric. J’ai installé la toute dernière version : avec Fulltext activé, cela semble bien fonctionner pour les articles, mais la recherche ne se fait pas dans les sites référencés malgré leur indexation dans la configuration du plugin.
Merci.
Répondre à ce message
La recherche marche parfaitement... quand on désactive Fulltext !
La version 0.8.1 corrige un gros bug, ça devrait aller mieux !
Répondre à ce message
Bonjour,
Il pourrait être également intéressant de documenter comment supprimer la fonction stopword, qui peut empêcher des éléments d’être retrouvé via la recherche : http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_ft_stopword_file
En gros, tout comme le changement à 3 caractères min pour la recherche, il faut modifier le fichier de configuration de MySQL pour y mettre
ft_stopword_file = ''puis redémarrer le serveur MySQL et relancer l’indexation FullText (via l’admin de votre site).
Il peut être également utile de vider le cache de SPIP.
Répondre à ce message
Bonjour,
J’ai un petit souci avec le magnifique plugin FullText (un grand merci aux créateurs).
Sur la page de configuration, je ne peux plus utiliser la fonction « Créer l’index
tout(surtitre,titre,soustitre,chapo,texte,ps,nom_site,url_site,descriptif) »... sur la table article.Si je clique sur « crééer l’index ’tout’ », j’ai l’erreur suivante qui s’affiche :
Erreur 1283 Column ’url_site’ cannot be part of FULLTEXT index
Ma base est en UTF-8. En tout cas c’est ce que me dit configuration/langue principale du site.
Mais quand je me connecte via PhpMyAdmin, je vois que sur la table article, par exemple, certains champs (pas tous) sont encore en encodage « latin1_swedish_ci », comme les champs Titre, SurTitre, Chapo et Texte. En revanche, URL_SITE est en UTF-8. A n’y rien comprendre, j’avoue.
Est-ce que je dois les forcer à passer en UTF-8 via PhpMyAdmin ?
Merci pour vos lumières, vos réponses
Cordialement
Christophe
Répondre à ce message
Bonjour,
Juste pour vous informer que j’obtiens cette erreur dans les logs php_errors.log
[09-Apr-2014 14:40:07] PHP Fatal error : Class ’ZSimplePPTX’ not found in /htdocs/plugins/fulltext/lib/simplepptx.class.php on line 81
Any idea ?
Merci,
Freed
C’est corrigé commit 81745, c’est juste les zips qui ne sont pas à jour (erreur temporaire).
Répondre à ce message
bonjour,
Je teste le plugin Dictionnaires.
Pas de problème pour utiliser avec Fulltext, tous les champs sont reconnus sauf un champ « termes »
Avec PHPMyAdmin, pas de différences visibles. Est-ce parce que le mot « termes » comporte un "s à la fin ?
Le problème a été résolu par une modification du plugin Dictionnaires.
Répondre à ce message
bonjour,
J’utilise spip3 un squelette sarka et le module fulltext pour gerer des nomenclatures (listes de référence).
Or, quand je lance une recherche sur un morceau de référence, il ne trouve rien.
par exemple, j’ai la ref 48523697524 dans une nomenclature et si je cherche 4852 il devrait me trouver toutes les ref contenant 4852 mais il ne trouve rien.
y a t-il un moyen pas trop complexe de contourner ce problème très gênant ? ou un réglage que j’aurai loupé ?
Merci d’avance,
Répondre à ce message
Bonjour,
Après pleins de tests infructueux, je cherche à installer XPDF sur un mutualisé OVH (et spip 3.0). J’ai bien testé les versions 32 bits ou 64 bits sous LINUX, en mettant bien le chemin complet, mais à chaque fois le plugin me répond qu’il ne trouve pas l’exécutable.
Quelqu’un pourrait-il me fournir un lien clair pour avoir le bon fichier pdftotext à installer ?
Merci de votre aide !
Julien
Suite de mon message : le serveur OVH mutualisé est sous Debian Linux version noyau : 3.2.42
Où puis-je trouver un exe déjà fait qui tourne sur ovh ? Cela doit bien exister !
Merci, merci,
Julien
Répondre à ce message
Après avoir converti les tables en myisam, impossible de restaurer la base de donnée après sauvegarde...
J’ai un échec sur tous les champs gérés par le plugin.
Des idées pour régler ça ?
merci
idem. et up.
au moins, faudrait pouvoir revenir en InnoDB :P
Répondre à ce message
Bonjour,
J’ai installé SPIP - pour le moment - uniquement avoir une interface à la recherche fulltext de MySQL (mais je suis tellement emballé par la qualité de ce que je vois, que je risque fort de m’en servir pour notre intranet).
J’ai donc installé le plugin FULLTEXT ainsi que tous les binaires nécessaires (pdftotext, catdoc...). Le plugin est configuré et j’ai ajouté les champs
titre,descriptif,fichier,credits,contenuà l’index fulltext.J’ai ensuite importé tous mes documents (xls, doc, docx, pdf) au moyen de l’import global du répertoire /tmp/upload : tout a bien été importé.
Dans l’interface du plugion FULLTEXT, je vois bien 170 documents (nous en avons quelques centaines, mais c’est juste un essai). Curieusement, chaque fois que je rafraichis la page, 5 documents de plus passent en indexés (5 est le « Nombre de documents à traiter par itération du CRON »).
Pour autant, je n’ai aucun contenu dans les champs « contenu » de la table spip_documents et la table spip_mots est vide.
Les fichiers extract.log et recherche.log n’existent pas et le fichier spip.log ne mentionne pas d’erreur.
Du coup avec aucun résultat et aucune erreur, je ne sais vraiment pas quoi faire.
24h après, le champ « contenu » est rempli. Pas pensé à faire un ps pour voir s’il bossait.
Par contre, toujours aucun résultat de recherche, toujours rien dans la table mots, toujours pas de fichiers extract.log et recherche.log. L’index est bien là (le .MYI) et sa taille, bien plus important que les autres, laisse suggérer qu’il est bon.
Ce plugin cherche, et c’est bien normal, parmi les documents qui sont en statut « publié ».
Or, avec l’import global, les documents sont en statut « prop » et ne ressortent donc pas.
Il faut donc changer ce statut (et ajouter la boucle pour listes les documents, car le plugin ne le fait pas) et ça fonctionne.
Répondre à ce message
Bonjour,
J’ai un sacré problème, (je suis sous spip 3 0 4).
En effet, lorsque je veux installer le plugin fulltext celui-ci m’indique que « Une incohérence entre le charset de votre site et celui des tables de votre base de données risque de fausser les recherches avec caractères accentués:convertir en UTF-8 pour restaurer la cohérence ».
Je clique donc sur le lien et ça m’affiche ça : Fichier convert_sql_utf8 introuvable
Que puis-je faire ? merci de votre aide,
Aurélien
http://www.fortboyard.net
Oui pour avoir cette page il faut installer le plugin « grenier ». Une fois la conversion faite, tu pourras supprimer le plugin.
Bonjour et merci de ta réponse,
Je viens d’installer le plugin grenier mais lorsque je fais http://www.fortboyard.net/ecrire/?exec=convert_sql_utf8 j’ai toujours le même message Fichier convert_sql_utf8 introuvable.
Quelle commande dois-je exécuter avec le plugin Grenier, je n’ai pas trouvé de tuto ?
Merci d’avance,
Aurélien
Salut, essaye avec ecrire/ ?exec=base_convert_sql_utf8 peut être.
++
Bonjour,
Merci de ta réponse.
Cela a résolu mon problème et maintenant ma base est en UTF8, tout comme SPIP.
Bonne journée,
Aurélien
Bonjour
J’ai aussi tenté cette manœuvre sur un spip 3.04 et une base de données de plus de 300 mégas. Tout se déroule bien avec Grenier mais au final, les articles en français disparaissent au premier accent. ceux en anglais ne sont pas touchés. un nouvel article apparaît très bien avec ses accents.
voir le site : www.seasailsurf.fr
Une idée pour retrouver l’intégralité des précédents articles et brèves (plus de 7000 pour plus de 10 ans d’archive) ?
Par avance merci
As-tu une sauvegarde de ton site ? Si tu la mets dans un coin et que tu m’envoies l’adresse, je peux essayer de la récupérer ce we. => mail fil@rezo.net
Je cherche aussi une solution pour ce transcodage qui coupe les articles au premier accent.
J’ai aussi essayé en intervenant sur le dump de la base, celon la méthose indiquée ici, celà donne exactement le même résultat.
J’atteins mes limites là ; une piste ?
J’ai le même problème.
J’ai fait la conversion avec grenier. mais je me retrouve avec des « É » a la place de mes accents dans mes articles.
Y a t’il moyen de corriger la base sans pour autant que les articles soient affecté de cette façon ?
Problème résolu en redéfinissant UTF-8 dans language du site
Répondre à ce message
Bonjour,
Une remarque sur la page de configuration qui permet de générer les index.
Pour les documents, le champ « Contenu » n’est pas dans l’index, ce qui empêche l’indexation du contenu textuel des documents.
Il faut ajouter ce champ et tout rentre dans l’ordre.
Répondre à ce message
Bonjour,
J’ai de gros problèmes de performances avec ce plugin dès que la recherche se fait sur plusieurs tables (spip 3.0.5, MySQL 5.1.49) :
- index fulltext uniquement sur la table articles :
mon serveur MySQL prend 0,07 secondes a me renvoyer les resultats
- index fulltext sur articles + mots :
prend 26,59 secondes.
J’ai vérifié les ressources allouées a MySQL - il semble qu’il n’y a pas de problème a ce niveau-la.
Quelqu’un a-t’il une expérience similaire ?
Pour info,
Merci !
J’ai pu constater le même souci sur deux serveurs récemment — il y a matière à enquête !
Si tu peux tester une mise à jour en 0.7.1 (commit http://zone.spip.org/trac/spip-zone/changeset/69055 ) ; elle devrait, j’espère, résoudre ce bug.
Parfait, tout marche parfaitement a présent.
Merci bcp !
Répondre à ce message
Bonjour,
Impossible de faire une recherche, celle-ci prend au moins 30 sec, contrairement à la recherche intégrée à Spip. ça marchait beaucoup mieux avant la 3. J’ai fini par désactiver, en attendant de trouver une solution.
Bonjour,
Problème réglé. J’ai supprimé tous les index, puis récréé. ça remarche, à priori :)
Répondre à ce message
Bonjour,
La version locale de mon site fonctionne parfaitement et Fulltext remplit parfaitement son rôle.
Cependant, à la mise en ligne de celui-ci, chaque recherche me renvoie :
Fatal error : Unsupported operand types in [racine]/plugins/auto/fulltext/inc/recherche_to_array.php on line 257
Je suis hébergé en mutualisé chez OVH, la version de PHP en cours est la 5.
Quelqu’un a t-il déjà rencontré ce genre d’erreur ?
Répondre à ce message
Bonjour,
j’ai installé ce plug-in sur mon SPIP 3.0, mis les tables en fulltext et dès que je fais une recherche dans le champ et bien ça cherche, ça cherche, ça cherche jusqu’à en faire tomber Apache !
Avez-vous une idée d’où cela vient ?
Merci
Répondre à ce message
ça marche pô en spip3 ?
ha bin si... (finalement)
Répondre à ce message
Bonjour,
Sur un Spip 3.0.2 tout neuf, utilisation du squelette dist fournit,
PHP Version 5.3.8
MySQL Version 5.5.16
Je rencontre 2 problèmes avec Fulltext
- Une recherche sur des mots contenu dans les documents indexés ne renvoi rien.
pourtant la table spip_documents est bien renseignés avec le contenu de mes documents
- La recherche sans le + ou le - ne renvoit rien. Il faut toujours utiliser l’addition ou la soustraction
Cordialement
pour la table document j’avais le meme probleme , en fait elle n’avait pas d’index fulltext
j’ai du le faire avec phpmyadmin.
sinon pour le + devant les recherches même problème pour moi ....
Bonjour,
La construction de l’index avait était faite par le plugin ...
mais ta réponse m’a intriguée .
J’ai donc vérifié.Le champ contenu n’était pas dans l’index Tout.
J’ai donc ajouté ce champ et c’est mieux.
Il faut également penser à adapter la page recherche fournie par défaut.
Il faut au minimum lui ajouter
Maintenant, ca fonctionne !
Répondre à ce message
Bonjour,
Depuis une mise à jour récente, la recherche d’un site était devenue très longue. Environ 8 à 14 secondes selon les résultats.
Une fois le plugin Full Text désactivé, la recherche est largement plus rapide. Une idée ?
Répondre à ce message
Salut,
J’ai trouvé un truc qui ne fonctionne pas bien :
J’ai un article qui s’appelle « Mémento des méthodes d’authentification par défaut des logiciels intranet communs ».
Si je recherche le mot clé « authentification », l’article ne sort pas, si je recherche « d’authentification », l’article ressort...
Y-a-t-il un moyen d’améliorer cela ?
J’ai le même comportement.
Si je recherche « activité sociale » j’ai 55 résultats alors que si je recherche « l’activité sociale » j’en ai 236 et sans les guillemets
activité socialej’en ai 169.Comment modifier ce comportement ?
Merci
C’est un bug de MySQL concernant les apostrophes dans les recherches fulltext.
Il est résolu dans la version 5.1.6 de MySQL c.f. http://dev.mysql.com/doc/refman/5.1/en/news-5-1-6.html - 1er paragraphe
Répondre à ce message
Bonjour, Après la mise à jour d’un site vers SPIP 3, je n’arrive pas à faire fonctionner Fulltext. Est-ce que ce plugin est censé être compatible ? (Il est dans la liste de plugins installables automatiquement.)
J’ai trouvé la source de mon problème. C’’etait une incompatibilité de squelette qui n’’etait pas lié au plugin.
Répondre à ce message
Bonjour
Après installation, petit souci d’accents sur les pages de configuration du plugin (uniquement sur ces pages)
exemple :
Répondre à ce message
A l’aide !
Bonjour !
Merci pour le plugin ! J’ai cependant une question sur l’indexation des documents. Mon site est chez OVH. J’ai les accès ssh. Après ,où coller les fichiers pour les doc et les pdf ? Quels fichiers prendre ? Tout le répertoire téléchargé ?J’imagine les versions linux. Et enfin quel sera le chemin ?
Merci d’avance de votre aide.
Répondre à ce message
Bonjour,
La recherche fulltext peut-elle fonctionner avec les champs IPTC, exif et tout champ de métadonnées des documents ?
pas directement, non ; si tu veux indexer ces champs il faut les « extraire » du fichier pour les recopier dans le champ « extrait » de la table spip_documents ; un mécanisme est prévu pour les fichiers pdf, doc et rtf, à étendre pour le cas qui t’intéresse : regarde dans le sous-répertoire extract/ du plugin
Bonjour,
Je reviens sur cette idée qui me paraît très opportune.
Exemple d’un site hébergeant de nombreux fichiers PDF. Ceux-ci comportent des métadonnées enrichies (titre, auteur, sujet, description)
L’indexation fulltext par défaut (extract->contenu) pourrait être complétée d’une extraction des métadionnées dans le champ descriptiif (meta->descriptif si descriptif vide)
xpdf->pdfinfo permet d’extraire facilement les métadonnées [pdfinfo ] ou [pdfinfo -meta ].
Insérer les métadonnées dans le descriptif doit être relativement simple.
Il suffirait ensuite d’ajouter à l’index fulltext document->titre une seconde colonne « descriptif » (ou créer un autre index)
Par contre, n’étant pas développeur, je ne peux guère vous aider....
Répondre à ce message
Salut,
C’est vraiment pas cool d’avoir ajouté des fonctionnalités comme l’« Indexation du contenu textuel des documents », nécessitant PHP 5.2, en faisant des sauts de version du plugin sur le derniers digits (0.6.1 -> 0.6.8), même si c’est optionnel.
En admettant que ce plugin ne soit toujours pas stable (il serait encore en développement, selon les fichiers xml... :p), un passage en 0.7 serait assez « signifiant » je trouve.
hum t’as perdu tes codes de commit ? :)
Oui :) ... (et je signale au passage un bug d’affichage quand on saisit moins de 10 caractères dans ce forum : on a la chaine « forum_attention_dix_caracteres » au lieu d’un libellé correct ...:P)
Répondre à ce message
Bonjour,
J’ai créé une table supplémentaire appelée spip_produits, qui est reconnue par TableData mais pas par Fulltext.
Dans la structure de ma table, je vois ceci :
manufacturer
famille
Il me semble donc que les index soient bien en place, non ?
J’ajoute que le Moteur de stockage est bien réglé sur MyISAM.
Comment dois-je procéder pour retrouver cette table dans la liste de la page de configuration du plugin ?
Merci bôcoup !
Je me permets un petit up... Y a quelqu’un ?
Répondre à ce message
Bonjour,
Je rencontre une difficulté sur l’indexation des documents : le cron de l’indexation des documents ne semble pas se lancer, et il faut que je supprime le fichier temp/fulltext_index_document_lock à la main pour que l’indexation des documents se déclenche.
Petites précisions :
- l’intervalle de temps pour l’indexation est réglé à 60 s pour les tests
- le problème est rencontré sur un site encore peu consulté car en développement, (mais la suppression de temp/fulltext_index_document_lock permet de déclencher)
- dans la fonction tmp/cache/charger_pipelines.fr, l’appel à la fonction Fulltext_taches_generales_cron, est avec un F en majuscule (issue du préfix du plugin , j’imagine), mais sa correction en minuscule à la main ne semble rien changer (dès fois que).
Merci pour vos lumières.
Pascal
Répondre à ce message
Bonjour,
Sur un SPIP 2.1.11 [18566] + FULLTEXTE Version : 0.6.4 [52790], une fois l’indéxation réalisée,, j’ai le message d’erreur suivant si la recherche porte sur un nombre :
Sur la table article (le même sur la table rubrique)
Répondre à ce message
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
aloa, y a t-il d’autres possibilités d’extraction que pdf ?
« La recherche s’effectuera aussi dans le contenu des documents (formats pris en charge : PDF, RTF, DOC, DOCX, ODT,XLS, XLSX, CSV, ODS, PPT, PPTX, ODP). »
merci
Répondre à ce message
Bonjour,
J’ai installé la version 0.3 [40755] sur un SPIP 2.1.2 [16017] .
Mon problème concerne la recherche sur le contenu de documents pdf, sachant que :
- le contenu du pdf a bien été importé dans le champ « contenu » de spip_documents
- le champ « extrait » est bien à « oui »
- tous les champs sont indexés
- j’ai bien rajouté une boucle documents au fichier du résultat de recherche (recherche.html)
La recherche sur un mot contenu dans le pdf ne donne aucun résultat.
Ai-je oublié quelque chose ?
Merci pour votre réponse.
Pour info, ci-joint le log, ma recherche porte sur le mot « fichier » contenu dans un pdf (le mot « fichier » est bien dans le champ contenu du doc) :
Salut vero,
S’il y a une erreur SQL, elle devrait normalement se retrouver dans
tmp/recherche.log; donc ici il semble que la requête est bonne... je ne vois pas ce qui peut clocher (d’autant que, chez moi, ça marche).Répondre à ce message
Je suis enthousiasmé par ce plugin, la recherche dans les contenus syndiqués fonctionne, c’est un plus. J’essaye de faire fonctionner la recherche dans les fichiers pdf joints aux articles, cela enrichirait pas mal les réponses aussi. Mais je n’y arrive pas (encore).
Voici ce que j’ai fait :
- SPIP 2.1.2 [16017] est installé en mutualisé
- Fulltext : 407552010-09-14 08:10:59 +0200
- mes_options.php :
Je suis sur un ubuntu et le fichier ’/usr/bin/pdftotext’ existe bien sur mon serveur
- page revisitée http://monsite.net/ecrire/?exec=fulltext®enerer=tous
Mais la recherche ne sort rien des fichiers pdf et la Table : spip_documents a une colonne : « extraits » à « non » pour tous les documents.
- Faut il que je patiente le temps que cron fasse tourner l’indexation ?
- Est ce une difficulté liée à l’installation en mutualisé (j’ai déja eu à remercier d’autres développeurs de plugins d’avoir retravaillé leur code à cause de cette mutualisation)
- Ais je oublié quelque chose ?
Répondre à ce message
Merci pour la réponse à ma précédente question.
J’en profite pour en poser une nouvelle. Un précédent plugin, Indexation, proposait une balise #EXTRAIT pour afficher la portion de texte où apparaissait le terme de recherche. Est-il possible d’intégrer une telle balise pour le plugin FullText ?
Merci encore.
A ma connaissance la commande FULLTEXT de MySQL n’offre pas d’extrait. Il est donc « logique » que ce plugin ne le propose pas. Mais tu peux bien entendu recopier le code de l’autre plugin et l’importer dans celui-ci, pour en enrichir les possibilités.
Répondre à ce message
Bonjour,
j’aimerais que la recherche soit effectuée également sur le nom physique des fichiers présents dans la table documents. Pour cela, j’ai modifié l’index ’tout’ de la table documents en intégrant le champ ’fichier’.
Je souhaiterais que la recherche soit effectuée sur ce champ avec un critère LIKE %%. C’est à dire que si je fais une recherche avec « test », le document « monfichier-test-version2.pdf » soit retourné dans les résultats. Je n’arrive pas à obtenir un tel résultat. Est-il possible de faire cela ?
Merci.
Non, ça ne peut pas fonctionner comme ça, car on utilise la commande FULLTEXT de MySQL. Cependant tu peux peut-être ajouter un champ à la table (et à l’index FULLTEXT), et le remplir régulièrement avec les « mots » du nom du fichier.
Répondre à ce message
Bonjour,
Est-ce que ce plugin permet de retrouver un article qui aurait deux mots clés par ex ?
Une recherche : +motclé1 +motclé2
retournera-t-elle les articles ayant ces deux mots clés ?
Je pose la question car je n’ai pas réussi à mettre cela en évidence.
Beru
Non, ça ne fait pas encore partie de ses possibilités ; j’aimerais pouvoir y retravailler
Répondre à ce message
Bonjour,
Y a -t-il qq chose à faire pour que cette recherche fulltexte se fasse aussi sur les champs extra ?
Beru
Il suffit d’intégrer ces champs dans un des index fulltext définis sur cette table dans MySQL. (Ou de créer un index fulltext sur ce champ.)
Merci de cette réponse rapide.
Veux-tu dire qu’il faut utiliser PHPMy admin pour intervenir ?
Je ne vois pas ce qu’est un index fulltexte.
Y’a une petite procédure écrite quelque part que je n’aurais pas vu ?
Beru
En effet : cherche « créer un index FULLTEXT » dans l’article ci-dessus :-)
Oui, j’ai lu cela.
Mais dans PhpMyadmin, je ne vois rien qui fait référence à ces index.
Et dans l’admin de Spip, « /ecrire/ ?exec=fulltext » , il n’est pas proposé de créer des index pour les champs extra ; mais juste pour les champs spip.
Quelque chose doit m’échapper.
Il faut entrer dans phpmyadmin la commande indiquée :
en remplaçant
titraillespar ce que tu veux, et en ajoutant tes champs extras dans la listes des champs.Ok !
Ca peut donner cela :
ex :
ALTER TABLE spip_articles ADD FULLTEXT
titre-choisi(`chp-extra1’, ’chp-extra2’, etc... )
Si j’ai tout compris.
Merci
Répondre à ce message
Bonjour,
J’ai installé le plugin (v0.3) et dans l’espace privé les tables sont listées mais elles ont toutes la mention « table non reconnue. » (spip 2.1.2)
Une idée...? Merci !
Je m’auto répond car j’ai trouvé : le plugin ne fonctionne pas avec MySql 4. Je suis passé à MySql 5 et c’est bon.
Répondre à ce message
2 choses qui me laissent quelques peu perplexes sur la doc :
je me demande s’il n’y a pas une erreur ici :
Ne fallait-il pas là lire formulaires/recherche.php tout court ? J’ai un doute là, ou alors c’est qu’il manque une étape d’explication à ma compréhension ???
Ensuite, serait-il possible d’avoir un petit décryptage PHP sur ce que fait exactement cette fonction :
Ce juste histoire de voir comment l’adapter à autre chose que la date
(là je bosse sur une recherche multi-critère se basant sur des champs extras en grand nombre + une recherche spécifique sur des références alpha-numériques incluses dans les articles et qu’il faudrait pouvoir remonter aussi, bien que pour la plupart elles ne contiennent qu’1 ou 2 caractères (ex : 6F ou 15CT ....) )
Bonjour,
Où doit-on mettre le fichier recherche_fonctions.php ou comme le mentionne Loiseau2nuit, ne serait-ce pas plutôt formulaires/recherche.php. Dans un cas, comme dans l’autre, ça ne semble pas fonctionner.
Je passe en paramètre dans mon formulaire
<input type="hidden" name="recherche_date" value="2004" />, mais lorsque je lance la recherche, j’ai des résultats ayant l’année 2008 comme date.Des idées ?
Merci
Répondre à ce message
Bonjour,
Je viens d’installer le plugin Fulltext. Ensuite je vais dans « Configuration > Fulltext », et là j’ai le message « Page réservée aux webmestres ».
Je suis pourtant administrateur du site. Une idée ?
Spip 2.0.1
Bonjour,
Le webmestre du site est par défaut l’auteur 1.
Vous pouvez installer le plugin Couteau Suisse et ajouter votre numéro d’auteur à la liste des webmestres (dans la section Administration du plugin).
Bonne journée
Répondre à ce message
Bonjour !
Est-ce que ce plugin offre la possibilité de restreindre la recherche à une seule rubrique ou à une seul article ? Et dans ce cas, comment faire ? (j’ai en effet un import de stock contenant 10000 références et je souhaite proposer un moteur de recherche uniquement dans cette liste. A priori, je pensais simplement intégrer mon csv comme document pour en faire un article).
Merci d’avance.
Répondre à ce message
Merci aux auteurs pour leur excellent plugin.
Une question toutefois : lorsque la recherche utilise le métacaractère * (par ex. Géogra*), les mots trouvés ne sont pas surlignés dans les pages de résultats.
Par contre avec un mot entier (Géographie par ex) les mots trouvés sont bien surlignés.
Est-ce normal ?
Répondre à ce message
je n’avais pas de boucle dans mon fichier recherche.html.
j’ai rajouté la boucle mais je n’ai toujours rien.
mon fichier pdf est bien importé dans le champs contenu de la table documents.
j’ai SPIP2.1.2
merci
Répondre à ce message
Dans quelle fichier dois être placé cette boucle ?
Merci pour votre réponse
Dans le squelette recherche.html, normalement
Répondre à ce message
Bonjour,
j’ai installé se plugin, l’utilitaire xpdf importe les fichiers pdf dans ma table documents.
tout semble bien fonctionner, mais quand je fait une recherche dans le moteur de recherche SPIP à l’interieur des fichier pdf, je n’ai aucun resultat
As-tu bien une
<BOUCLE_d(DOCUMENTS){recherche}>? Sinon il faudrait donner un peu plus de détails...Répondre à ce message
Bonjour !
J’ai un problème pour communiquer le contexte de la langue pour
#AIDE_RECHERCHE(en SPIP 2.1 SVN).Pour reproduire : faire un squelette
inc-searchhelp.htmlqui contient :<BOUCLE_help(RUBRIQUES){lang}{0,1}>#AIDE_RECHERCHE</BOUCLE_help>et l’appeler avec la ligne
... /spip.php?page=inc-searchhelp&lang=fren variant le code de langue. Et ça ne marche pas. Pour que cela marche avec fiabilité il faut ajouter&var_mode=recalcul(et non pas seulement « calcul ») dans l’URL. Ce qui n’est pas normal je trouve (?)Répondre à ce message
bonjour,
je voulais juste dire que ce plugin est de la balle.
Merci !
Répondre à ce message
Bonjour, ce plugin est certainement très utile, mais il refuse de fonctionner dans le cadre d’un site mutualisé : il apparaît bien dans la liste des plugins du site, mais l’appel à la page ?exec=fulltext aboutit à Erreur : fichier fulltext introuvable ...
Un moyen d’arranger cela ?
Marc
Répondre à ce message
Bonjour à tous.
Sympa comme plugin. Cependant y a t’il moyen de rajouter des tables supplémentaires et des champs supplémentaires dans la recherche ?
Merci.
Répondre à ce message
Je suis très intéressé par ce plugin et principalement la recherche dans les pdf cependant comme beaucoup je ne comprends pas du tout la partie « installation » et principalement l’installation de Xpdf. Installé ou ? comment ? etc...
Ça serait vraiment super qu’une personne complète cette partie car je pense que la contribution n’en serait que plus intéressante.
Merci, d’avance Mathieu.
Répondre à ce message
Bonjour !
N’étant pas familier avec PHP et la syntaxe pour mes_options.php n’étant pas précisée ici, je viens vous demander si je ne fais pas une bêtise en définissant ainsi les constantes :
ou (avec indexation des pdf)
Merci d’avance !
Répondre à ce message
Bonjour,
J’ai un sacré problème, le plugin m’ayant demandé de convertir ma base en utf-8 (pourtant elle y est déjà), j’ai cliqué, me disant qu’il y avait bien une raison pour qu’on me demande cela. le résultat est catastrophique, naturellement. Y a-t-il un moyen de revenir en arrière, sachant que je n’ai pas fais de sauvegarde (erreur que je ne fais pourtant jamais !) ?
Merci d’avance.
Philippe
Normalement la procédure de conversion utf8 écrit un backup de la base dans le répertoire tmp/
Cela dit ce n’est peut-être pas si « catastrophique » que cela ; fais un dump SQL de ta base, de manière à pouvoir le cas échéant la récupérer
Philippe G.
J’avais un souci de recherche infructueuse sur les mots comprenant des caractères accentués depuis quelque temps, que je pensais résoudre en suivant les indications données ici :
http://benjamin.sonntag.fr/Resolu-Probleme-de-recherche-avec-accents-dans-Spip#forum339
J’ai subi un échec à l’importation de ma base corrigée, puis, après sauvegarde, ai décidé de faire confiance à la correction proposée par FULLTEXT, malgré ta mauvaise expérience.
Résultat : impeccable, la base a été convertie, aucun souci.
Merci FULLTEXT, qui a incidemment réglé un souci que je ne comprenais pas.
Christophe
Répondre à ce message
Bonjour,
il y avait une balise #EXTRAIT avec le plugin Indexation qui permettait d’afficher dans les résultats de recherche l’extrait où se trouvait le mot recherché.
Il me semble que cette balise n’est plus disponible avec le plugin Fulltext ? Y’a-t-il un autre moyen d’arriver au même résultat ?
Merci beaucoup !
Répondre à ce message
Bonjour et merci pour cette fonctionnalité avancée.
J’ai installé XPDF sur mon serveur, ensuite j’ai ajouté dans le fichier mes_options.php la ligne suivante :
define('_FULLTEXT_PDF_EXE', '/usr/bin/pdftotext');Maintenant comment faire pour que les contenus des documents PDF déjà présents dans mon site soient indexés ?
Comment savoir aussi ceux qui le sont déjà ou pas ?
Merci par avance.
L’info est dans la base, les docs ont un statut d’indexation qui vaut « oui » s’ils sont indexés, « non » s’ils sont en attente de passage du génie, et « err » s’ils n’ont pas pu être indexés, soit à cause d’une erreur soit à cause de l’absence d’un extracteur.
On va ajouter une page permettant de relancer l’indexation de ceux qui sont en erreur.
bonjour
moi je n’arrive pas à trouver le fichier mes_options.php, merci de m’indiquer ce chemin et aussi les différentes étapes à suivre après l’installation de xpdf et fulltext pour commencer l’indexation
mes_options.php se trouve dans le répertoire /config à la racine de ton spip.
Ce fichier n’existe pas par défaut, il faut donc le créer au besoin.
ca par contre, je laisse à d’autres le soin de t’expliquer ça, moi je n’en suis pas encore là dans mon analyse de Fulltext
Merci pour votre réponse effectivement ce fichier ne figure pas dans le répertoire config donc pour le crée j’aurai besoin de son contenu, merci de me transmettre le contenu de ce fichier
Euh oui mais non. Son contenu dépend essentielement de la configuration dont TU as besoin. Je peux bien te filer le contenu d’un des miens de fichier mais ca ne t’avanceras absoluement à rien.
Et pour ce qui concerne le cadre propre à FullText, ce que doit contenir le mes_options.php est déjà indiqué dans l’article ;-)
merci pour votre réponse, mais j’aurai besoin du contenu de l’un de vos fichier pour avoir une idée sur le contenu de ce fichier, et merci
Répondre à ce message
Bonjour,
est-ce que l’activation du plug-in permet d’en avoir également l’usage dans la partie privée ?
merci
oui il fonctionne aussi dans la partie privée
Répondre à ce message
Merci pour cette précision.
Dans le fichier « extract.log » voici ce que j’ai (j’ai remplacé les IP pour ne pas les afficher)
Qu’est-ce qui pourrait empêcher l’indexation des documents, puisqu’il à l’air de tourner en boucle ?
Encore merci.
C’est bizarre, il devrait te dire qu’il n’a pas d’extracteur pour les .jpg et .gif normalement !
Répondre à ce message
Bonjour
Est-ce que Spip 2 cherche sur le contenu des documents PDF et DOC comme il le faisait dans les versions précédentes ?
Est-ce que ce plugin modifie ce comportement ?
Bonjour,
Je recherche aussi une solution.
je suis en 2.0.9, et au niveau des résultats de recherche j’obtiens des documents qui ont le mot recherché dans le titre ou le descriptif mais pas dans le contenu des PDF.
Une idée ?
L’indexation du contenu des pièces jointes arrive dans quelques heures dans ce plugin, en commençant justement par les PDF !
Excellent !
Merci beaucoup !!!
Cela confirme donc le fait que Spip n’indexe plus les contenus de certaines pièces jointes ou pas ?
Quoi qu’il en soit merci de la contrib !
SPIP seul n’a jamais indexé la moindre pièce jointe. Avant, il fallait utiliser le plugin Indexation, maintenant Fulltext hérite de cette fonctionnalité.
Bravo pour ce plugin et vivement la suit, genre une balise #extrait(extrait du texte ou la recherche a trouvé la recherche :)), si je me sors assez vite d’autre soucis de webmaster je me lance pour voir comment fiare une telle balise.
En attendant, dès que j’active le plugin je ne peux plus rechercher dans les brèves... J’efface les index fulltext, je les recrés... toujours rien. Le problème disparait quand je déactive le plugin... Le fichier rechercher.php et a priori correcte. Je recherche également dans les évenements et la pas de soucis... Je suis sur spip 2.09.
Une suggération ?
Vraiment aucune idée sur le fait que la recherche sur les brèves ne fonctionne pas ?
Répondre à ce message
Comment faire pour inclure dans la recherche des tables supplémentaires qui ne sont pas gérées par spip ?
Je crois qu’il va falloir que tu regardes un peu le code en détails, car à priori ce n’est pas prévu en standard. Bon courage et n’hésite pas à partager tes solutions
Répondre à ce message
Juste un mot : « Bravo ! » Et même un autre : « Merci ».
Répondre à ce message
Bonjour,
Voilà une bonne semaine que je cherche une solution à mon problème de résultats de recherche... cf ma dernière tentative sur les forums de spip : http://forum.spip.org/fr_215799.html#forum215878 (je vous laisse visiter, je ne vais pas me répéter ici)
Et puis je déniche, je ne sais pas comment, ce plugin. Je me dis chouette ! Je vais régler mon problème.
Et bien c’est pire !! Et ce plugin ne semble pas fonctionner pour moi.
Je ne sais pas par où commencer pour régler ce souci... si quelqu’un avait une idée, cela m’aiderait grandement.
Répondre à ce message
Bonjour,
J’utilise Fulltext sur plusieurs sites spip et tout marche parfaitement sur chacun d’eux. J’ai interconnecté ces sites entre eux en créant des fichiers Connect pour chacun d’eux et les sites communiquent bien entre eux. Par contre, en utilisant Ajax, je voudrai passer une requete de recherche fulltext d’un site à l’autre... et je n’y arrive pas.
Par exemple, comment, depuis un site A, transmettre une recherche sur le site B avec « enfant étranger » ?
J’obtiens des résultats avec « enfant » et avec « étranger » comme si fulltext n’existait pas. Par contre, la même requête faite directement sur le site B renvoie des résultats corrects !
Ma requete ajax sur le site A :
$.ajax(
type : « POST »,
url : http://monsiteA/?page=recherche,
data : ’recherche=« enfant etranger »&connect=siteB’,
success : function(bloc)//integration dans la maquette
$(« #cont_recherche-B »).append(bloc) ;
) ;
Comment faire pour que la chaîne « enfant étranger » soir bien prise en compte et non chaque mot ?
Amicalement,
Pierrick
Répondre à ce message
Bonjour,
sur ce site j’ai essayé la recherche :
+afficher +sql (ça remonte beaucoup de lignes ; mais toutes ne contiennent pas les 2 mots !)
sql (ne remonte aucune ligne)
donc à quoi sert de spécifier le + comme mis dans la doc de ce plugin :
+enfant +étranger -> Retourne les textes qui contiennent « enfant » ET « étranger ».
qqun peut il m’expliquer pourquoi
merci
voir un peu plus haut dans cet article :
ce qui, donc, par défaut ne permet pas de rechercher sur « sql », « cvt », « onu », « ena »...
Répondre à ce message
Bonjour,
Suis-je le seul à avoir une « énorme » erreur sql à l’activation du plug-in, lors d’une recherche ?
voici le message :
You have an error in your SQL syntax ; check the manual that corresponds to your MySQL server version for the right syntax to use near ’LEFT JOIN
archive.spip_auteurs_articles as lien1 ON lien1.id_article=t.id_arti’ at line 3je suis sous spip 2.0.5, sql 5.1.30...
J’ai désactivé tous les autres plugins, et bien transformé les champs de ma base (avec exec=fulltexte
Non tu n’es pas le seul. Nous sommes au moins 2 !
J’ai essayé ce plugin en local, suivi la procédure sans souci.
Puis essayé et j’ai eu ce même message d’erreur.
@Sam et @tof : pouvez-vous regarder dans tmp/mysql.log le messag d’erreur complet ? Merci
ça te suffit ça ?
Mar 20 09:22:58 127.0.0.1 (pid 524) You have an error in your SQL syntax ; check the manual that corresponds to your MySQL server version for the right syntax to use near ’LEFT JOIN
escal_V2.spip_auteurs_articles as lien1 ON lien1.id_article=t.id_art’ at line 3 -SELECT t.id_article, (MATCH(t.
titre) AGAINST (’firefox’)) * 8 + (MATCH(t.surtitre,t.titre,t.soustitre,t.texte,t.nom_site,t.descriptif) AGAINST (’firefox’)) * 1.2 + SUM(MATCH(obj1.nom) AGAINST (’firefox’)) + SUM(MATCH(obj2.titre) AGAINST (’firefox’)) + SUM(MATCH(obj3.titre) AGAINST (’firefox’)) AS score, t.populariteFROM spip_articles AS t,
LEFT JOIN spip_auteurs_articles as lien1 ON lien1.id_article=t.id_article
LEFT JOIN spip_auteurs AS obj1 ON lien1.id_auteur=obj1.id_auteur
,
LEFT JOIN spip_mots_articles as lien2 ON lien2.id_article=t.id_article
LEFT JOIN spip_mots AS obj2 ON lien2.id_mot=obj2.id_mot
,
LEFT JOIN spip_documents_liens AS lien3 ON (lien3.id_objet=t.id_article AND lien3.objet=’article’)
LEFT JOIN spip_documents AS obj3 ON lien3.id_document=obj3.id_document
WHERE t.statut=’publie’
GROUP BY t.id_article
ORDER BY score DESC
LIMIT 0,500
Merci, c’est corrigé.
Je viens de
- télécharger le zip
- décompresser et mis le dossier fulltext à la place de l’ancien
- réactiver le plugin
- régénérer les index
- vider les caches
et le problème persiste
C’est bien la version corrigée qui est dispo ici ?
Non, car le zip n’est mis à jour qu’une fois par jour. Il faut que tu récupères le fichier par svn (ou que tu attendes le zip)
Ok merci, j’attendrais demain.
Ah voui ça marche mieux ainsi !
Merci beaucoup pour ce plugin qui nous donne enfin une solution simple à mettre en œuvre pour permettre une recherche sur plusieurs mots, ce qui manquait à notre petit écureuil préféré.
Bonjour,
y a-t-il une raison logique pour que la première recherche de n’importe quel terme (mot unique, deux mots, ...) mette toujours exactement 60 secondes avant de délivrer le résultat, et que, par la suite (même après une demi heure), la même recherche s’exécute immediatement.
J’ai lancé plus d’une vingtaines de recherches et j’ai bouclé sur un SHOW PROCESSLIST : le process de requête SELECT T.id_article, MATCH... existe pendant strictement 60 secondes (avec le libellé : Copying to tmp table)
Oui c’est logique : la recherche est mise en cache à deux niveaux :
- par MySQL, qui cache sa requête et la restitue instantanément si elle est refaite exactement pareil
- par SPIP qui la stocke temporairement dans la table spip_resultats, pour pouvoir faire de la pagination et des boucles en tous sens sans relancer à chaque fois la même recherche
Ensuite, 60 s c’est un peu long : mais là ça dépend surtout de la taille de ta base et de la capacité et configuration de ton serveur.
Répondre à ce message
Il serait intéressant de fusionner avec le plugin Indexation qui permet en outre d’indexer les documents joints.
Plus tot ce sera fait mieux ça sera.
Ce qu’il manque dans ces 2 plugins à mon avis c’est une proposition de formulaire de recherche avancée.
Il y a certes des choses à reprendre dans le plugin « Indexation » (notamment les extracteurs, pour remplir un champ spip_documents.texte avec le contenu des PDF etc) ; mais certainement pas tout, et pas en vrac.
N’hésite pas à contribuer !
Par curiosité, Fil, j’aimerais savoir lequel sera soutenu par la communauté ?
Je suis également de ceux qui pensent que cela devrait être natif dans SPIP.
Quant à contribuer, ce n’est l’envie mais le manque de temps qui m’en empêche.
Quoiqu’il en soit, avec le plugin Fulltext, ça serait bien quand même un formulaire de recherche avancée avec :
- termes recherchés
- liste des rubriques
- date début et date de fin
Ca fait 2 post que tu fais pour donner des listes de choses à faire pour améliorer ce plugin, tu ferais mieux de passer ce temps à coder ! (comment peux tu avoir imaginé un seul instant qu’on est pas déja plein à avoir pensé aux choses que tu suggère ???)
Désolé d’avoir froissé certains.
Vu la tournure, je pense que je vais m’arrêter là.
En tout cas, bon courage et bravo pour le travail accompli.
Répondre à ce message
Puisque (je suppose ?) MySQL met des mots courts aussi dans l’index, est-ce qu’on pourrait réussir à chercher/trouver des mots comme « Jan », « Ewa », etc. maintenant ?
Il me semble que la limite qui demande >3 caractères pour une recherche est toujours en place. Est-ce qu’elle est nécessaire ?
@Paolo : je viens d’ajouter un paragraphe expliquant comment étendre la recherche aux mots de 3 lettres.
Fil écrit :
Impeccable ! Cela marche. Merci.
Répondre à ce message
Bonjour,
On pourrait pas prévoir une intégration pure et simple dans Spip en lieu et place de la recherche actuelle ?
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 :
|
