Recherche avancée

Sur d’autres sites (6269)

• Révision 22576 : Suppression d’un code mort, mort depuis longtemps.

  23 novembre 2015, par marcimat@rezo.net

  Déjà signalé par rénato en 2006 (http://spip-dev.rezo.narkive.com/mHG6Qlt6/small-bug-in-phraser-champs),
  ce if () vaut toujours true. On l’enlève du coup.

  Précisément, cela vient tout à l’origine d’une erreur lors d’un passage de ereg à strpos en r3964, strpos ne comprennant
  pas l’expression [0-9]. Redmine n’affichant plus les révisions / diff avant la révision 9600, je mais des liens git :
  https://git.spip.net/rCSPIP57683758d1ebe3a6ffa5095035e88768b14d86f2 ou https://github.com/spip/SPIP/commit/57683758d1ebe3a6ffa5095035e88768b14d86f2

  C’était à une époque ou la constante NOM_DE_CHAMP coupait les balises nommées en héxadécimal en 2 : `#FF3300` par exemple avait `#FF` en balise, et
  le reste était dans la suite, et il fallait potentiellement recorriger ce problème.
  Cette constante a été améliorée ensuite, pas longtemps après en r4407, pour attraper tout le contenu de ces balises :
  https://github.com/spip/SPIP/commit/fef3ff59fad8896d1c8946346eac1b47befc588f

  Donc, en théorie, depuis cette date, le test if() n’a plus lieu d’être.

• Anomalie #3593 : pb generer_url_entite si appel dans squelette

  14 novembre 2015, par jluc -

  Le commentaire en ligne 1418 indique l’intention :
  // mais d’abord il faut tester le cas des urls sur une base distante
  Pour cela le code "if (is_string($public)..)" semble nettement insuffisant.

  Le bug est révélé dans le squelette suivant :
  

  [(#ID_ANNONCE|generer_url_entitemonobjet,’’,’’,0)]

  
  lorsqu’on remplace le 0 par un 1 afin de récupérer les urls publiques au lieu des urls privées.

  La question est donc "comment distinguer un connecteur d’un booléen" ?

  Une réponse peut être que si $public vaut "1" ou 1, alors c’est un booléen...

  À la place de
  if (is_string($public) ...)
  je proposerais donc
  if ((is_string($public) or (intval($public)=="1") AND ...

• Anomalie #3736 : image_recadre est affecté par la constante _IMG_GD_MAX_PIXELS même quand on n’uti...

  2 mars 2016, par Michel Bystranowski

  Pour information, les traitements d’image ne passe que par GD. La
  plupart des fonctions image_* ne sont pas génériques et ne savent
  exploiter que GD.

  J’ai été voir dans le code pour en avoir le cœur net, et c’est bien ça : le mode de production des vignettes n’est utilisé que pour image_reduire et image_passe_partout, les autres filtres d’image utilisent gd.
  Le bug n’a donc pas lieu d’être… Pardon pour le bruit !