Revisions : SPIP

Articles published on the website

• Anomalie #4355: critère {0,n} et variable

  21 June, by RastaPopoulos ♥

  Et donc pour compléter : ça semble être un problème général de mauvaise prise en compte des variables dans la compilation de ces critères, et du coup, peut-être ce serait à résoudre en même temps.

• Anomalie #4355 (Nouveau): critère {0,n} et variable

  21 June, by Fabrice Véronneau

  Salut,

  Pour rejoindre en partie le ticket https://core.spip.net/issues/4209 je pose le problème rencontré :

  Une boucle ayant comme critère {0,#ENV{max,n}} ne fonctionne pas. Elle sort en équivalence SQL LIMIT 0,0 donc 0 résultat, alors que si l'on met en dur :
  {0,n} cela affiche tous les résultats. Cela force à mettre un nombre max acceptable du type : {0,#ENV{max,9999}}

• Anomalie #4353: MYSQL 5.7 - Comportement du timestamp vs la variable explicit_defaults_for_timestamp

  20 June, by Eric Lupinacci

  On peut le faire manuellement sur tous les timestamp mais comme la déclaration est toujours la même on pourrait peut-être le faire automatiquement dans SPIP en remplaçant timestamp par timestamp DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP pour éviter de créer des tables sans ce comportement. Un fois que c'est fait, quelque soit la valeur de la variable ça fonctionnera.
  A voir si c'est la bonne solution ou pas ?

• Anomalie #4353: MYSQL 5.7 - Comportement du timestamp vs la variable explicit_defaults_for_timestamp

  20 June

  Je viens de me rendre compte que je suis confronté au même problème.

  explicit_defaults_for_timestamp est OFF par défaut d'après la doc Mysql (jusqu'à 5.7) mais j'ai le cas chez mon hébergeur et en local avec MAMP Pro, donc on n'est sûrement pas les seuls

  Dans /ecrire/req/mysql.php, il y a déjà des requetes SET MYSQL_MODE='' qui sont lancées pour éviter les erreurs sur les dates du type "0000-00-00 00:00:00", qui sont interdites quand la config sql_mode contient STRICT_TRANS_TABLES ou NO_ZERO_DATE (ce qui est le cas par défaut sur Mysql 5.7).
  Dans la suite logique, on pourrait ajouter SET explicit_defaults_for_timestamp = 0, mais c'est moche, il vaudrait mieux avoir des déclarations complètes.

  Je vais déjà me faire un script qui ALTER toutes les tables qui ont une colonne maj, peut être un plugin temporaire pourrait être utile ?

  L'idéal serait une release avec modification des déclarations des champs MAJ, non ?

• Anomalie #4351: Login par email (cookie spip_admin)

  19 June, by Pierre KUHN

  +1 aussi
  Si on pouvait avoir login = email non ?