Recherche avancée

Sur d’autres sites (8177)

• Evolution #3268 (Nouveau) : Traitement de en 3.1

  10 septembre 2014

  L’intégration de dans _PROTEGE_BLOCS en http://core.spip.org/projects/spip/repository/revisions/21273 entraîne une rupture de compatibilité en 3.1 pour celleux qui auront utilisé la feature de la doc ( en tête et en fin de texte d’article... http://www.spip.net/fr_article3016.html).

  Si des gens utilisent du tex ils n’auront pas manqué de repérer cette grosse facilité d’encodage. Ils vont être piégés là en 3.1
  C’est clairement une feature... de niche mais une feature.

  Du coup, ça me semble valoir la réflexion quant à la rupture de compat...

  Quelques idées :
  - ne sert qu’à activer l’interprétation des et

  

  par spip. Faut-il le traiter comme les autres cas de _PROTEGE_BLOCS ?
  - A la limite, traiter ce cas comme d’autres du marquage SPIP ? Bon il y a le cas où quelqu’un voudrait dans un article aussi bien des formules que des prix en $...
  - faire un plugin qui reprend le traitement historique ?
  - une page qui permettrait de traiter ça de manière automatique, un peu comme on a fait pour les sauts de ligne ?

  En tous cas, quand je vois certaines pages avec des dizaines de formules, j’ai mal aux doigts pour les rédacteurs qui vont devoir remplacer les $bla$ par partout... Et je crains que ça ne devienne une motivation à ne pas mettre à jour.

• 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.