Recherche avancée

Sur d’autres sites (5330)

• Anomalie #4177 (Nouveau) : Les traitements d’images de mauvaise extension créent des erreurs fatales

  26 septembre 2018

  Comme il a été discuté sur la liste spip-dev, il y a des cas maintenant (depuis une mise à jour des librairies GD sur les serveurs), où des images créent des erreurs fatales, ce qui plante complètement les pages.

  Cela se passe souvent sur des sites anciens, car normalement sur les SPIP récents, des images dont l’extension est incorrecte par rapport au contenu réel du fichier sont renommés dès l’import.
  Mais dans le cas de vieux sites, il peut encore y avoir des logos ou des documents, par exemple IMG/arton1.jpg dont le contenu est au format PNG.
  Avant libgd 2.?, et après libgd 2.2.5, une erreur "normale" est levée… mais notamment en libgd 2.2.4 (dans Debian 9 par exemple), une erreur fatale est levée.
  https://github.com/libgd/libgd/issues/338

  Il faudrait j’imagine :

  1. dans SPIP éviter ce problème.
  2. permettre de corriger les fichiers impactés

  Éviter le problème fatal dans SPIP¶

  La solution la plus évidente est d’analyser le contenu "mime type" du fichier prioritairement à l’extension.
  Cette solution fonctionne avec une analyse via la fonction finfo_file
  Je joins un patch qui permet cela, et log dans tmp/log/images tout fichier d’extension incorrect

  Recherche et correction des fichiers erronés¶

  D’autre part il peut être pratique de permettre une recherche / correction de ces fichiers.
  J’ai proposé une commande Spip-cli images:verifier:extensions qui permet également de réparer les fichiers avec l’option --reparer
  - https://zone.spip.net/trac/spip-zone/changeset/111668

• Evolution #3897 (Nouveau) : Traduction des configurations (yaml, xml, json) et certains formulaire...

  6 février 2017, par marcimat ☺☮☯♫

  Je remets le texte d’un mail envoyé sur spip-devel (comme il n’y a plus de liens gmane pour les voir), sur le sujet parlant de la fonction _T_ou_typo() qui permet de pouvoir traiter des chaînes contenant

  • soit "du texte"
  • soit une "<:chaine_de_langue:>"
  • soit des "<multi>...</multi>"

  La fonction _T_ou_typo() a comme usage principal d’appliquer la fonction typo() sur le texte qui lui est envoyé, ou récursivement sur chaque valeur si un tableau lui est donné.
  Et, si un des textes est de la forme <:cle_de_langue:> ou <:module:cle_de_langue:> (une forme simple de l’écriture de chaîne de langue dans les squelettes donc), alors c’est la valeur de traduction de cette chaîne de langue qui est retourné.

  Autrement dit :
  

  _T_ou_typo("Coucou") == "Coucou" 
  _T_ou_typo("<:module:bonjour :>") == "Coucou" (avec le fichier de langue qui va bien quand même)
  _T_ou_typo("Coucou") == "Coucou" 
  _T_ou_typo(["Coucou", "<:module:bonjour :>", "Coucou"]) == ["Coucou", "Coucou", "Coucou"]
  

  Cette intégration pose plusieurs questions sur l’usage / le besoin d’origine et sur la réponse apportée.

  L’usage et solution actuelle¶

  Le besoin est de permettre dans des fichiers de configuration (yaml, xml, json) de certains plugins, ou dans des options de configuration de certains plugins directement dans l’interface privée de SPIP (Menus, Formidable, Champs Extras, ...), de pouvoir indiquer soit un texte quelconque, soit de se référer à une chaîne de langue quelque part.

  Par exemple, dans une déclaration .yaml d’une saisie, on peut trouver : label: '<:saisies:option_groupe_description:>'. On pourrait utiliser pour des saisies spécifiques à un site label: 'Description' si on sait que le site n’est pas multilingue par exemple.

  La difficulté d’utiliser directement le code de langue (ie : label: 'saisies:option_groupe_description'" qui paraît pourtant plus simple) est qu’il est impossible de discriminer les cas où on écrirait un code de langue, des cas où c’est réellement le texte voulu, par exemple avec "label: 'todo'", qui si on utilise le code de langue retournerait ’à venir’ (dans spip_fr.php), alors que ce n’était pas forcément ce qui serait souhaité.

  D’où donc l’apparition de cette écriture <:truc:muche:> pour les textes de configuration, écriture connue déjà dans les squelettes SPIP, avec les nuances qu’on parle bien ici d’une syntaxe simplifiée.
  On ne peut pas écrire label: '<:module:nb_elephants{nb=5}:>' par exemple.

  Proposition¶

  Il me semble qu’on pourrait voir la chose autrement, en considérant que toute présence d’un idiome doit être transformé par la fonction typo().
  La fonction typo() traite déjà en fait le cas des polyglottes <multi>...</multi> que l’on peut écrire à la fois dans les squelettes SPIP et à la fois dans le texte d’un article.
  Il suffirait d’ajouter la gestion de l’idiome <:module:cle:> également. Ainsi typo("<:module:bonjour:>") retournerait "Coucou" en allant piocher la chaîne de langue correspondante.

  La conséquence est que ça permettrait plus de possibilités que le besoin d’origine (on pourrait mettre des chaines de langue dans les textes d’articles par exemple)
  (je ne dis pas que ça serait recommandé non plus, mais dans certains cas ça serait pratique !), tout en répondant au problème avec les configurations de type .yaml ou d’autres déclarations multilingues : il leur suffirait d’appliquer typo() sans autre question, du moins en théorie.

• Anomalie #3894 : Jointures (erronées ?) avec les boucles documents et leurs critères

  27 janvier 2017, par marcimat ☺☮☯♫

  Jointure avec Documents / id_mot¶

  Par ailleurs pour les mots la jointure que montre tcharles est correcte justement. Cependant, là il cherche les mots clés présents sur les documents, ce qui contredit ce que je disais en 2012 là http://marcimat.magraine.net/SPIP-3-Documents-Mots :

  Ce que SPIP va décider lorsqu’il y a ambiguïté, c’est à dire comme ici (DOCUMENTS){id_mot} alors qu’il existe les 2 tables spip_documents_liens et spip_mots_liens, c’est qu’il va préférer interpréter cela comme une liaison sur la table de lien de la boucle en cours, c’est à dire sur spip_documents_liens, ce qui signifie donc que ça va retourner « les documents attachés à un mot clé »

  Donc, pour ce point, quelque part à un moment donné il y a eu un changement.

  Autres test.¶

  Je viens de remarquer que le problème survient dès lors qu’il y a plusieurs critères optionnels sur la boucle. De telle sorte les boucles suivantes ont une seule jointure sur spip_documents_liens :
  -
  -
  - (+ 1 jointure sur spip_mots_liens)

  C’est dès lors qu’on utilise plusieurs critères optionnels que les problèmes surviennent :
  -

  Si on appelle page=test&id_breve=1 (1er critère) on aura 1 seule jointure :
  

  SELECT documents.fichier
  FROM spip_documents AS `documents`  
  INNER JOIN spip_documents_liens AS L1 ON ( L1.id_document = documents.id_document )
  WHERE (documents.statut = ’publie’)
      AND (documents.mode IN (’image’,’document’))
      AND (documents.taille > 0 OR documents.distant=’oui’)
      AND (L1.id_objet = 1)
      AND (L1.objet = ’breve’)
      AND (L1.vu = ’non’)
  GROUP BY documents.id_document
  

  Si on appelle page=test&id_article=1 (2è critère) on aura 2 jointures :
  

  SELECT documents.fichier
  FROM spip_documents AS `documents`  
  INNER JOIN spip_documents_liens AS L2 ON ( L2.id_document = documents.id_document ) 
  INNER JOIN spip_documents_liens AS L1 ON ( L1.id_document = documents.id_document )
  WHERE (documents.statut = ’publie’)
      AND (documents.mode IN (’image’,’document’))
      AND (documents.taille > 0 OR documents.distant=’oui’)
      AND (L2.id_objet = 1)
      AND (L2.objet = ’article’)
      AND (L1.vu = ’non’)
  GROUP BY documents.id_document
  

  Si on appelle page=test&id_rubrique=1 (3è critère) on aura 2 jointures (le L s’incrémente à L3) :
  

  SELECT documents.fichier
  FROM spip_documents AS `documents`  
  INNER JOIN spip_documents_liens AS L3 ON ( L3.id_document = documents.id_document ) 
  INNER JOIN spip_documents_liens AS L1 ON ( L1.id_document = documents.id_document )
  WHERE (documents.statut = ’publie’)
      AND (documents.mode IN (’image’,’document’))
      AND (documents.taille > 0 OR documents.distant=’oui’)
      AND (L3.id_objet = 1)
      AND (L3.objet = ’rubrique’)
      AND (L1.vu = ’non’)
  GROUP BY documents.id_document
  

  Autrement dit, je pense que SPIP crée une jointure pour la possibilité d’avoir id_breve dans l’URL (L1), pareil pour id_article (L2), etc pour les suivantes.
  Le champ "vu" utilise la première jointure possible (toujours L1 du coup ici). Ensuite SPIP nettoie les jointures inutiles en fonction des paramètres d’environnement reçus, mais il ne peut enlever L1 car le champ "vu" l’utilise (alors qu’il faudrait qu’il utilise une autre jointure, L3 par exemple si id_rubrique dans l’env, et enlever L1).