Skip to content
Extraits de code Groupes Projets
  1. jan. 16, 2023
  2. jan. 13, 2023
  3. jan. 12, 2023
  4. jan. 09, 2023
  5. jan. 08, 2023
    • marcimat's avatar
    • cerdic's avatar
      docs(changelog): correction du filtre `|couper` · 05d8c120
      cerdic a rédigé
      05d8c120
    • cerdic's avatar
      fix: filtre `|couper`, gestion des espaces insécables · 2cc15a73
      cerdic a rédigé
      Couper sur un espace insécable comme un espace normal, et le trimmer si c'est le dernier caractère via la preg car le trim final ne nettoie pas les espaces insécables
      
      Refs: #5422
      2cc15a73
    • Glop's avatar
      fix: filtre `|couper`, toujours compter deux caractères pour les sauts de paragraphes · 48e79e5b
      Glop a rédigé et cerdic's avatar cerdic a validé
      Pendant le calcul de la coupe du texte, les sauts de paragraphes
      sont représentés par des `\r` (un caractère) mais, à l'issue du
      filtre, ils sont remplacés par `\n\n` (deux caractères).
      
      Par conséquent, cela fausse le calcul de la coupe et peut renvoyer
      un texte plus long que demandé.
      
      Ainsi, par exemple :
      ```
      [(#VAL{<p>Un test du filtre |couper</p><p>avec deux paragraphes</p>}|couper{41})]
      ```
      renvoie
      * jusqu'à eebacfbe inclus :
        `Un test du filtre |couper\n\navec deux (...)`
        (42 caractères → KO) ;
      * après ce correctif :
        `Un test du filtre |couper\n\navec (...)`
        (37 caractères → OK).
      
      Il est important de compter les `\n` correctement, en particulier
      pour les plugins qui fabriquent des messages de taille limitée
      (comme des pouets ou des tweets).
      
      Refs: #5422
      48e79e5b
    • Glop's avatar
      fix: Filtre `|couper`, ne pas couper si le texte est déjà à la bonne taille · c3e184df
      Glop a rédigé et cerdic's avatar cerdic a validé
      Plutôt que de reposer sur un marqueur de fin de texte (`\n`), autant
      détecter dès le début si le texte est déjà à la longueur demandée.
      Cela évite en particulier des cas où le texte est inutilement coupé
      juste parce que la coupe retire le marqueur de fin pour laisser de
      la place pour les points de suite.
      
      Ainsi, par exemple :
      ```
      [(#VAL{Encore un test du filtre |couper bla bli blu}|couper{44})]
      ```
      renvoie
      * jusqu'à eebacfbe inclus :
        `Encore un test du filtre |couper bla (...)` (42 caractères
        → OK, mais coupe inutile) ;
      * après ce correctif :
        `Encore un test du filtre |couper bla bli blu` (44 caractères
        → OK, sans coupe inutile).
      
      Refs: #5422
      c3e184df
    • Glop's avatar
      fix: Filtre `|couper`, longueur du texte de suite et détection du dernier mot · a7f7a786
      Glop a rédigé et cerdic's avatar cerdic a validé
      Jusqu'à présent, le filtre supposait que le texte de suite faisait
      exactement 5 caractères, indépendamment de sa véritable taille.
      Qui plus est, le texte de suite par défaut ` (...)` fait 6 caractères
      et non pas 5 (car il faut aussi compter l'espace insécable), ce qui
      fait que la longueur de la chaîne retournée était parfois incorrecte.
      
      Ainsi, par exemple :
      ```
      [(#VAL{Un nouveau test du filtre |couper bla bli blu}|couper{42})]
      ```
      renvoie
      * jusqu'à eebacfbe inclus :
        `Un nouveau test du filtre |couper bla (...)` (43 caractères → KO) ;
      * après ce correctif :
        `Un nouveau test du filtre |couper (...)` (39 caractères → OK).
      
      De même, en spécifiant un autre texte de coupe :
      ```
      [(#VAL{Un nouveau test du filtre |couper bla bli blu}|couper{42,&nbsp;(etc.)})]
      ```
      renvoie
      * jusqu'à eebacfbe inclus :
        `Un nouveau test du filtre |couper bla (etc.)` (44 caractères → KO) ;
      * après ce correctif :
        `Un nouveau test du filtre |couper (etc.)` (40 caractères → OK).
      
      Aussi, lorsque la coupe tombait juste après un mot, l'expression
      régulière employée dans le `preg_replace()` suivant considérait ce mot
      comme tronqué car non suivi d'une espace. Afin de pouvoir détecter les
      coupes en fin de mot, il faut en fait couper avec un caractère de plus
      et modifier l'expression régulière en conséquence :
      * soit ce dernier caractère est une espace, auquel cas on n'a pas coupé
        au milieu d'un mot, et il faut supprimer uniquement cette espace
        (c'est le `[\s]` dans la seconde alternative de l'expression
        régulière) ;
      * soit ce dernier caractère n'est pas une espace, auquel cas on a coupé
        au milieu de (ou juste avant) un mot, et il faut supprimer ce mot
        (c'est le `[^\s]+` dans la seconde alternative de l'expression
        régulière).
      
      Enfin, il faut aussi ajouter le modifieur `D` (`PCRE_DOLLAR_ENDONLY`)
      à l'expression régulière pour qu'elle ne traite pas différemment le `\n`
      ajouté comme marqueur de fin de texte :
      https://www.php.net/manual/en/reference.pcre.pattern.modifiers.php
      
      Refs: #5422
      a7f7a786
    • Glop's avatar
      fix: Filtre `|couper`, cas où l'on coupe dès le premier mot · c934c0d1
      Glop a rédigé et cerdic's avatar cerdic a validé
      Le filtre tente de ne pas tronquer le dernier mot si la coupe
      tombe au milieu de celui-ci. Pour cela, il essaie de couper
      au mot précédent.
      
      Mais lorsque le premier mot est long (ou que la longueur de
      coupe est courte), il se peut que l'on coupe au milieu du
      premier mot, auquel cas il ne faut pas couper au mot précédent
      mais carrément en début de chaîne. Les mécanismes suivants
      pour s'assurer que la chaîne coupée n'est pas trop courte
      feront ensuite en sorte que la coupe se fasse au caractère,
      si nécessaire.
      
      Ainsi, par exemple, lorsque le mot long n'est pas le premier :
      ```
      [(#VAL{A supercalifragilisticexpialidocious}|couper{22})]
      ```
      renvoie correctement `A supercalifragilistic` (22 caractères).
      La coupure est faite au caractère, sans ajouter les points de
      suite.
      
      Par contre, si le mot long est en premier :
      ```
      [(#VAL{Supercalifragilisticexpialidocious}|couper{20})]
      ```
      renvoie
      * jusqu'à eebacfbe inclus :
        `Supercalifragili (...)` (22 caractères → KO) ;
      * après ce correctif :
        `Supercalifragilistic` (20 caractères → OK).
      
      Ce correctif rétablit un comportement cohérent de la coupe,
      que le mot long soit en premier ou non.
      
      Refs: #5422
      c934c0d1
    • Glop's avatar
      fix: Filtre `|couper`, ne pas décompter les caractères UTF-8 · 9980f342
      Glop a rédigé et cerdic's avatar cerdic a validé
      Les fonctions `spip_substr()` et `spip_strlen()` gèrent déjà
      correctement les chaînes UTF-8. Il n'y a donc pas besoin de
      corriger la longueur de coupe en lui rajoutant des caractères
      supplémentaires pour les caractères UTF-8.
      
      Ainsi, par exemple :
      ```
      [(#VAL{Tést àvéc plêïn d’àççènts bla bli blu}|couper{31})]
      ```
      renvoie
      * jusqu'à eebacfbe inclus :
        `Tést àvéc plêïn d’àççènts bla (...)` (35 caractères → KO) ;
      * après ce correctif :
        `Tést àvéc plêïn d’àççènts (...)` (31 caractères → OK).
      
      Cela rejoint le bug rapporté par @Fil dans les commentaires de #255 :
      spip/spip#255
      
      Refs: #5422
      9980f342
  6. jan. 07, 2023
  7. jan. 06, 2023
  8. jan. 05, 2023
  9. jan. 04, 2023
  10. jan. 03, 2023
    • marcimat's avatar
      docs(changelog): Pour #3719 édition des logos · 5b53e630
      marcimat a rédigé
      5b53e630
    • cerdic's avatar
      feat: Balise `#ID_LOGO_` qui prend les mêmes variantes que `#LOGO` mais... · 9ed7778c
      cerdic a rédigé
      feat: Balise `#ID_LOGO_` qui prend les mêmes variantes que `#LOGO` mais renvoie simplement le `id_document` du logo
      
      - la fonction `logo_survol` disparait au profit d'une fonction `generer_code_logo` que l'on définit dans `ecrire/balise/id_logo_.php` pour être robuste aux vieilles surcharges du fichier `logo_.php`
      - le flag `fichier` de la fonction `quete_logo()` devient déprécié, car l'information que l'on veut est en fait le champ fichier du document logo, donc on traite ce cas via `table_valeur()` (au passage on répare donc la syntaxe `#LOGO_TRUC**` ou `[(#LOGO_TRUC|fichier)]` qui depuis
      SPIP 4.1 renvoyait toujours le nom du fichier `truconXX.png` au lieu de `logo/truconXX.png`)
      - le traitement des champs titre, descriptif, credits et alt est fait dans la fonction `quete_html_logo()` c'est à dire uniquement quand on va effectivement produire du html
      
      Refs: #3719
      9ed7778c
Chargement en cours