Recherche avancée

Sur d’autres sites (16462)

• Anomalie #3261 (Nouveau) : Non prise en compte des champs

  2 septembre 2014

  Quelque soit le type d’urls sémantiques utilisés, si l’objet est en multi, une seule url est encodée (celle de la langue du contexte d’enregistrement). L’activation de l’édition avancée permet d’ajouter des urls mais elles redirigeront en 301 vers la première ce qui n’est pas top...

  Il me semble que l’on peut difficilement échapper à la création d’un champ lang dans spip_urls vu que les objets n’ont pas forcément une langue (selon la configuration du SPIP ou selon le codage de l’objet...).

  Après, le système le plus simple serait peut-être de créer un schéma "url linguistiques" calqué sur celui des propres et adapté comme évoqué par http://core.spip.org/issues/3148

  A vous lire (je vais devoir trouver une solution à ce souci d’ici fin 2014, peut-être une occasion pour passer geek à 44%, je plafonne à 41% depuis trop longtemps ^^)

• Anomalie #3260 (Nouveau) : Problème de dump sur les tables comportants des index de longueur spéci...

  28 août 2014, par b b

  Le contexte est le suivant : http://contrib.spip.net/GIS-4?debut_comments-list=@476655#forum476655

  En résumé, depuis que la table spip_gis contient des index dont la longueur est spécifiée, le système de dump génère une erreur sur ces tables. Après pas mal de recherche, je suis remonté jusqu’à spip_mysql_show_table() (raison pour laquelle ce ticket est déclaré sur le core et non le plugin dump).

  J’ai d’abord étudié ce qui se passe dans base_copier_table() de ecrire/base/dump.php :

  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/base/dump.php#L536

  À ce niveau, dans $desc_source['key'] la longueur des index n’est pas renseignée. Si on compare le contenu des fichiers de cache des descriptions des tables, on observe que tmp/cache/sql_desc*.txt ne renseigne pas la longueur des index. Alors que tmp/cachesql_desc_dump*.txt est ok, la longueur des index y est présente.

  Du coup, j’en suis remonté à sql_showtable(), et plus précisemment à spip_mysql_show_table() :

  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L754

  Depuis phpmyadmin, un SHOW CREATE TABLE renvoie bien ce qu’il faut, ex :

  CREATE TABLE `spip_gis` (
   `id_gis` bigint(21) NOT NULL AUTO_INCREMENT,
   `titre` text NOT NULL,
   `descriptif` text NOT NULL,
   `lat` double DEFAULT NULL,
   `lon` double DEFAULT NULL,
   `zoom` tinyint(4) DEFAULT NULL,
   `adresse` text NOT NULL,
   `pays` text NOT NULL,
   `code_pays` varchar(255) NOT NULL DEFAULT ’’,
   `region` text NOT NULL,
   `departement` text NOT NULL,
   `ville` text NOT NULL,
   `code_postal` varchar(255) NOT NULL DEFAULT ’’,
   PRIMARY KEY (`id_gis`),
   KEY `lat` (`lat`),
   KEY `lon` (`lon`),
   KEY `pays` (`pays`(500)),
   KEY `code_pays` (`code_pays`),
   KEY `region` (`region`(500)),
   KEY `ville` (`ville`(500)),
   KEY `code_postal` (`code_postal`),
   KEY `departement` (`departement`(500))
  ) ENGINE=MyISAM AUTO_INCREMENT=24 DEFAULT CHARSET=latin1
  

  Il semble que la regex de la ligne 736 ne match pas la table spip_gis certainement à cause des (500) :

  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L736

  Et du coup, on bascule sur le plan B, qui ne fait qu’un simple SHOW COLUMNS FROM ne contenant pas l’information de longueur des index :

  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L765

  Wala où j’en suis ^^ Je ne sais pas si ce comportement est voulu, mais il pose un sacré problème pour les dumps.

• Evolution #3257 (Nouveau) : Permettre de surcharger facilement le nombre d’items affiché dans les ...

  13 août 2014, par b b

  Le système de pagination permet déjà de personnaliser le contenu des liens précédent/suivant à l’aide de paramètres passés aux modèles. Par contre, il n’est pas possible de personnaliser le nombre d’items affichés dans la pagination de cette manière. On peut le faire à l’aide d’une surcharge de filtre_bornes_pagination_dist() comme le signale Cedric :

  < cerdic‎ >  function filtre_bornes_pagination($courante, $nombre, $max)
  < b_b‎ >  ouep je suis remonté jusqu’à lui hier soir
  < cerdic‎ >  en y forçant $max = 5 ;
  < b_b‎ >  merci pour la confirmation :)
  < b_b‎ >  super
  < b_b‎ >  10 c’est trop par défaut je trouve
  < cerdic‎ >  eventuellement tu definis le filtre que si tu es pas dans le prive
  < cerdic‎ >  pour impacter que le site public
  

  Il serait intéressant de permettre cette personnalisation à l’aide d’un paramètre passé aux modèles.