Recherche avancée

Sur d’autres sites (4939)

• Evolution #3638 (Nouveau) : Utiliser la rechercher Fulltext par défaut pour le critère {recherche}

  7 janvier 2016, par Gilles VINCENT

  Suite à la discussion entammée sur spip-dev, je suggère d’utiliser la recherche Fulltext par défaut, au lieu des REGEXP actuelles
  http://thread.gmane.org/gmane.comp.web.spip.devel/66780

  Par défaut, recherche génère des requêtes des type REGEXP, ce qui n’est utile que si des utilisateurs font des recherches avec des expressions régulières, ce qui n’est pas le cas. Depuis le commit r21697 les tables ont installées par défaut au format MyISAM (demande #2727). SPIP gagnerait donc à utiliser les recherches en Fulltext.

  Analyse détaillée du problème faite par Remi (root@lautre.net) :

  Le problème c’est que ce type de requête est généré dès lors qu’il y a un
  espace dans la recherche et les requêtes REGEXP n’utilisent pas les index.

  Donc ça ne concerne pas que les utilisateurs qui recherchent des
  expressions régulières.

  Pour une recherche aussi bête que "chercher un mot" ça recherche
  REGEXP sur chaque colonne de la table
  spip_articles. Evidemment ça renvoie tous les articles contenant "un".

  Un exemple particulièrement inefficace : 51s pour faire une recherche sur 2
  mots sans avoir la certitude que les 2 mots ne s’y trouvent.

  1. Query_time : 51.073814 Lock_time : 0.018906 Rows_sent : 16363 Rows_examined : 36816

  SELECT t.id_article, t.surtitre, t.titre, t.soustitre, t.chapo, t.texte,
  t.ps, t.nom_site, t.url_site, t.descriptif FROM `xxxxxx`.spip_articles AS t
  WHERE t.surtitre REGEXP ’Etats unis|Etats|unis’ OR t.titre REGEXP ’Etats
  unis|Etats|unis’ OR t.soustitre REGEXP ’Etats unis|Etats|unis’ OR t.chapo
  REGEXP ’Etats unis|Etats|unis’ OR t.texte REGEXP ’Etats unis|Etats|unis’
  OR t.ps REGEXP ’Etats unis|Etats|unis’ OR t.nom_site REGEXP ’Etats
  unis|Etats|unis’ OR t.url_site REGEXP ’Etats unis|Etats|unis’ OR
  t.descriptif REGEXP ’Etats unis|Etats|unis’ ;

  Ici, ça me renvoie les articles qui contiennent "punissons",
  "réunis".

  A ce niveau, un bête like me met "que" 5s :

  SELECT * from (select *, concat( t.surtitre, t.titre, t.soustitre,
  t.chapo, t.texte, t.ps, t.nom_site, t.url_site, t.descriptif) search from
  spip_articles t) s WHERE s.search like ’%unis%’ or s.search like
  ’%Etats%’ ;

  Mais honnêtement 5s, ce n’est pas non plus acceptable.

  Mais s’il vous faut mettre un truc par défaut autre que du fulltext,
  utilisez LIKE sur la chaine à rechercher. Ca ira plus vite et ça vous
  renverra des résultats plus cohérents.

  Remi

• Anomalie #3633 (Nouveau) : probleme appel de la mediabox

  2 janvier 2016, par tofulm -

  Bonjour,
  dans un squelette toto.html, j’ai un inclure en ajax avec un squelette qui comporte plusieurs liens de la forme
  

  &lt;script&gt;<br />
  
  jQuery(document).ready(function(){<br />
  
       jQuery(&quot;a.appel_mediabox&quot;).mediabox();<br />
  
  ...<br />
  
  &lt;/script&gt;
  
  

  au chargement de la page, j’ai les mediabox qui se lancent "vides" au lieu d’attendre le click sur le lien.

  le problème vient de :
  http://zone.spip.org/trac/spip-zone/browser/_core_/plugins/mediabox/javascript/spip.mediabox.js#L89

  Ce test n’était pas présent en spip 3.0 et le même code fonctionnait.

  Si je supprime ce test et le remplace par :
  

  return this.colorbox($.extend(cbox_options,options)) ;
  

  tout est ok

  Merci

• Révision 22875 : Déplantage de la balise #RANG quand on a déclaré autre chose qu’un simple champ p...

  4 mars 2016, par rastapopoulos@spip.org

  On garde exactement le même fonctionnement qu’avant avec un "AS titre_rang" rajouté. Mais on fait deux tests au lieu d’un seul :
  - d’abord on cherche le titre en se disant que "lang" est défini AVANT
  - et si on ne trouve pas, là on prend depuis le début
  Mais dans les deux cas, vu que c’est séparé en deux, et qu’on cherche "lang" explicitement et pas une virgule toute seule : on peut donc prendre tout caractère pour le titre, y compris les virgules qu’il y aurait dans des fonctions.

  Cela gère donc bien tous les cas, enfin de toute façon plus de cas qu’avant.