1) Est-ce que quelqu'un sait expliquer pourquoi lorsque sur spip.net on recherche « critères » on ne retrouve *pas* la page « Les critères communs à toutes les boucles », tandis que si on cherche « critère », on le trouve bien.
Est-ce un bug ?
2) Est-il possible de changer (parametrer) l'action du javascript qui opère le surlignement des résultats de recherche pour que ce surlignement survienne sur la première page appelée et non seulement à partir de la deuxième ? Ceci est particulièrement utile lorsqu'il s'agit d'un formulaire de recherche qui appelle la même page (avec résultats en format tabulaire, par exemple).
RealET m'a expliqué (http://thread.gmane.org/gmane.comp.web.spip.user/138965) que le referer est utilisé pour le surlignement -- ce qui limite peut-être les possibilités ?
1) Est-ce que quelqu'un sait expliquer pourquoi lorsque sur spip.net on recherche « critères » on ne retrouve *pas* la page « Les critères communs à toutes les boucles », tandis que si on cherche « critère », on le trouve bien.
Est-ce un bug ?
Je viens pas avec une réponse, mais j'ai aussi constaté des disfonctionnements dans le moteur de recherche de mon site (en version 2.0.3). J'ai pas encore su comprendre la logique des bugs, mais mes tests se portaient uniquement sur des mots avec une ou des lettres accentuées. Si ça peut aider.
C'est peut-être du à un mauvais charset dans la base de donnée.
Il n'y a pas de problème avec un site neuf installé sous SPIP 2.0, mais il semble que les sites migrés puissent se retrouver avec un charset inadapté.
Cela ne se voit pas dans SPIP dans ce cas, mais quand on essaye de voir la base avec un autre outil comme phpMyAdmin.
C'est peut-être du à un mauvais charset dans la base de donnée.
Il n'y a pas de problème avec un site neuf installé sous SPIP 2.0, mais il semble que les sites migrés puissent se retrouver avec un charset inadapté.
Cela ne se voit pas dans SPIP dans ce cas, mais quand on essaye de voir la base avec un autre outil comme phpMyAdmin.
Cédric
ça m'a effectivement l'air d'être le cas chez moi.
Je me souviens à une époque, avoir migré volontairement mon site de iso-8859-1 (c'est comme ça qu'on dit) en utf-8 ... je n'ai plus le détail des opérations faites côté base.
Bref, comme j'ai l'habitude d'aller parfois bricolé dans phpMyAdmin, tout allait bien. C'est vrai que depuis quelques temps, j'avais bien remarqué des caractères bizarres mais je ne m'en étais pas inquiété.
Bingo, mes tables ont un interclassement latin1_swedish_ci ???
Pourquoi, j'en sais rien, comment résoudre, je ne sais pas non plus, tout ce que j'ai vu par ailleurs dans phpMyAdmin, c'est :
Jeu de caractères pour MySQL: UTF-8 Unicode (utf8)
Faut-il aller simplement sur chaque table pour remettre cet interclassement comme il devrait-être ? Affaire à suivre.
C'est peut-être du à un mauvais charset dans la base de donnée.
Il n'y a pas de problème avec un site neuf installé sous SPIP 2.0, mais il semble que les sites migrés puissent se retrouver avec un charset inadapté.
Cela ne se voit pas dans SPIP dans ce cas, mais quand on essaye de voir la base avec un autre outil comme phpMyAdmin.
Cédric
ça m'a effectivement l'air d'être le cas chez moi.
Je me souviens à une époque, avoir migré volontairement mon site de iso-8859-1 (c'est comme ça qu'on dit) en utf-8 ... je n'ai plus le détail des opérations faites côté base.
Bref, comme j'ai l'habitude d'aller parfois bricolé dans phpMyAdmin, tout allait bien. C'est vrai que depuis quelques temps, j'avais bien remarqué des caractères bizarres mais je ne m'en étais pas inquiété.
Bingo, mes tables ont un interclassement latin1_swedish_ci ???
Pourquoi, j'en sais rien, comment résoudre, je ne sais pas non plus, tout ce que j'ai vu par ailleurs dans phpMyAdmin, c'est :
Jeu de caractères pour MySQL: UTF-8 Unicode (utf8)
Faut-il aller simplement sur chaque table pour remettre cet interclassement comme il devrait-être ? Affaire à suivre.
Il faut aller sur chaque champ en iso et le mettre en UTF8 general_ci
Tu peux faire un essai sur une table, mais je crois que ça ne résoud pas le probleme, en fait.
La seule résolution définitive consiste à sauvegarder sa base en xml (avec la fonction de SPIP), à réinstaller SPIP dans une nouvelle base vierge, et réimporter la base.
Mais on perd les stats, revisions et autres babiolles au passage:(
Il faut aller sur chaque champ en iso et le mettre en UTF8 general_ci
Tu peux faire un essai sur une table, mais je crois que ça ne résoud pas le probleme, en fait.
La seule résolution définitive consiste à sauvegarder sa base en xml (avec la fonction de SPIP), à réinstaller SPIP dans une nouvelle base vierge, et réimporter la base.
Mais on perd les stats, revisions et autres babiolles au passage:(
Eh Cédric, tu retardes d'une version et tu es pris à ton propre piège: la sauvegarde propose maintenant une liste à cocher des tables à sauvegarder, celles que tu cites étant seulement non cochées par défaut. Ce qui me fait rire c'est que tu as trouvé cette liste angoisssante pour le spipeur moyen et m'a demandé qu'elle n'apparaissent qu'au survol du triangle. Résultat: tu as oublié la fonctionnalité ! CQFD.
Non. Mais si tu essaye de sauvegarder les stats sur un site un peu conséquent et un hébergement pas haut de gemme, tu verras vite que le temps nécessaire à la sauvegarde devient rédhibitoire.
Quand à la sauvegarde des révisions, elle est illusoire, car les fragments de versions sont zippés dans la base, et deviennent corrompus (illisibles) après une opération sauvegarde - restauration.
La sauvegarde optionnelle des tables non prises en compte par défaut dans SPIP peut donc être utile pour certaines tables, en cas de plugin désactivé par exemple, mais pas pour ces tables là.
Et sur l'ergonomie de la fonction sauvegarde, je maintiens que l'on a beaucoup perdu par rapport à la version 1.9.x, mais j'espère avoir le temps de revenir sur ces points pour la prochaine version.