- jan. 16, 2023
-
-
b_b a rédigé
-
- jan. 13, 2023
- jan. 12, 2023
-
-
b_b a rédigé
-
-
- jan. 09, 2023
- jan. 08, 2023
-
-
-
cerdic a rédigé
-
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
-
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 -
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 -
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, (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 -
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 -
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
-
- jan. 07, 2023
-
-
marcimat a rédigé
On déplace des classes SQLite dans un répertoire dédié On étend la classe `\PDOStatement` pour permettre dedans de récupérer le connecteur `\PDO` utilisé (notre `$link`). Pour se faire, il faut explicitement indiquer à `PDO` cette classe lors de la construction du lien. Ceci fait, à partir d’une jeux de résultats de PDO (PDOStatement), on peut retrouver le connecteur PDO, et donc relancer une requête sur ce connecteur là. On utilise cela pour calculer le compte des requêtes Select si on en a besoin. Refs: 5291
-
cerdic a rédigé
fix: sql_multi() echouait sur une chaine ne contenant qu'une multi car il faut tester strictement le retour de strpos()
-
cerdic a rédigé
-
cerdic a rédigé
-
- jan. 06, 2023
-
-
marcimat a rédigé
Renvoyer un message comme quoi cette fonction est dépréciée (depuis SPIP 3.1) pour inciter les gens à corriger… Refs: #5343
-
marcimat a rédigé
-
marcimat a rédigé
-
marcimat a rédigé
On fait donc dans l’espace privé de la même façon que dans l’espace public. Refs: #5366 #5384 spip/dist#4857
-
- jan. 05, 2023
-
-
marcimat a rédigé
-
-
marcimat a rédigé
-
marcimat a rédigé
-
-
marcimat a rédigé
-
-
refactor: ramener le traitement de compatibilite de l'argument id/options dans balise_FORMULAIRE_INSCRIPTION_stat() ce qui permet de n'envoyer tant tous les cas que des entiers en 2ème paramètre de `tester_statut_inscription()` depuis `#FORMULAIRE_INSCRIPTION` Fix: #5402
-
-
marcimat a rédigé
-
- jan. 04, 2023
-
-
cerdic a rédigé
refs: #5398
-
Eric Lupinacci a rédigéFix: #5411
-
-
marcimat a rédigé
-
-
- jan. 03, 2023
-
-
marcimat a rédigé
-
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
-
