Recherche avancée

Sur d’autres sites (8904)

• Anomalie #3941 (Fermé) : CSS carnet contrib

  5 mai 2017, par jluc -

  Dans le carnet wiki de contrib, les balises code et cadre génèrent un listing dont les lignes sont numérotées.

  Il y a une colonne grisée plus claire spécialement pour les n° de ligne, à gauche du code.

  Malheureusement les n° sont déportés à droite à cause d’un `margin-left : 43px ;` spécifié par le plugin coloration_code, et du coup cette colonne est vide.

  Voir la copie d’écran de la page https://contrib.spip.net/test-du-carnet pour se rendre compte.

  Les n° de ligne sont tous décalés au lieu d’utiliser la colonne dégagée pour eux !

  Ça va nettement mieux quand on active la css suivante :

  Je ne sais pas la motivation de ce margin de 43px dans coloration_code, et si c’est à corriger dans gribouille (mais je ne sais pas quel gribouille le carnet de contrib utilise car yen a plusieurs) ou dans coloration_code ou spécifiquement dans contrib.

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

  6 mai 2017, par guytarr °

  Gilles VINCENT a écrit :

  Je suis d’accord que la recherche fulltext ne fonctionne qu’avec mysql.
  Mais est-ce une raison suffisante pour tirer les performances vers le bas ?
  Pour ma part je ne pense pas.

  Ensuite, si le plugin Fulltext répond à la demande (à savoir pourvoir faire une recherche sur "chercher un mot" qui soit pertinente) alors peut-être qu’il faut le mettre par défaut dans plugins-dist, et ne l’activer que si les conditions sur la base de données sont réunies. Comme cela, on ne change rien à l’api générale, et les recherches deviennent meilleurs. Tout le monde est satisfait !

  Qu’en dites-vous ?

  Une simple remarque : je pense qu’il faut proposer lorsque c’est possible une recherche basée sur un outil qui est conçu pour (sphinx, elasticsearch).
  Autant pour la partie publique c’est au cas par cas, autant pour l’espace privé on sait à quoi s’attendre et on pourrait proposer une solution intelligente (et performante) basée là-dessus et où plugins (objets) pourraient se brancher simplement.
  Le fulltext est pas mal mais il y a des contraintes de version, de moteur sgbd, etc... Je pense que l’on va s’embêter pour obtenir un moins bon résultat au lieu de déléguer ça à un outil qui sait bien le faire.

• Révision 23678 : Bugfix dans recup_date() quand on lui passe une chaîne du type 2017-07

  20 juillet 2017, par brunobergot@gmail.com

  Sous PHP 5.5.38-1 le test `substr($jour, 0, 1) == ’0’` renvoie true quand `$jour = ’’` ce qui fait renvoyer un valeur false pour le jour au lieu d’une chaîne vide.
  r23409 ayant modifié affdate_base(), ce cas ne passait plus par `strtotime($numdate)` mais par `mktime($heures, $minutes, $secondes, $mois, $jour, $annee)` qui génère un timestamp décalé d’un jour en arrière.
  On obtenait donc 06 au lieu de 07 pour `[(#VAL2017-07|affdatem)]`

  pfiou :p