SPIP 3 en ISO-8859-1
Bonjour, 2 points que j'ai remarqué en ISO-8859-1 sur SPIP 3.0.3
-
Le moteur de recherche (en fait, c'était déjà le cas en V2) en recherchant un mot accentué, seuls les articles sans cet accent ressortent. J'ai noté que pour une recherche de "élément", la requête à MySQL est WHERE title LIKE "%element%" OR ... et MySQL retourne bien tous les articles qui contiennent le mot recherché. C'est donc SPIP qui limite le résultat (la table spip_resultats ne contient en effet que certains de ces articles). En traçant le traitement, seul le calcul des points est susceptible de poser problème. De fait dans ecrire/inc/recherche_to_array.php ligne 103 et 104, la fonction translitteration_rapide est utilisée, et les preg_match comparent "element" (demande translittérée) à "élément" (translitteration_rapide) et se plantent. En remplaçant, transliterration_rapide par translitteration, les résultats sont impeccables. Je ne sais pas si c'est ok avec les autres charset, mais celui-ci étant connu, il peut être utile de spécifier une comparaison différente en fonction du charset.
-
ajaxCallback.js Toujours avec ma petite recherche accentuées, les résultats sont affichés, dans mon squelette, dans des blocs Ajax classés par secteur. Or j'ai remarqué que lorsque je clique sur la pagination, ce n'est pas de l'ajax, mais un lien réel. En regardant dans la console d'erreur, je vois le message "Malformed URI sequence" Ligne 812 ajaxCallback.js, ce qui correspond à
val = decodeURIComponent(val);
. De fait, ma recherche contenait un ô qui passé dans l'URL comme un%F4
, et decodeURIComponent, il n'aime pas vraiment. J'ai donc remplacé cette ligne parval = decodeURIComponent(unescape(val).replace(/%/g,'%25'));
et je n'ai plus de problème.
Pour en revenir à la recherche, pourquoi j'ai encore les tables SPIP_INDEX_ARTICLES à SPIP_INDEX_SYNDIC de la v1 ? C'est plus utilisé ça ! Si ? ... J'ai loupé une étape un jour ?