[spip-dev] SPIP 3.2.5 : balise_svg

Salut à tous et toutes

j'ai fait l'autre jour la mise à jour de SPIP 3.2.5. Celle ci à introduit une fonction balise_svg.

Ma remarque : idéalement cela n'aurait pas du être introduit dans une version mineur. J'avais un filtre maison du même nom qui a été skippé.

Cela étant, ca m'a donné l'occasion de tester le filtre en question.

Et il se trouve qu'il est problématique dans certains cas : si le fichier svg possède un entete xml, alors l'entete xml est mis dans le corps du html.

ex d'image de ce type

https://www.planete-sciences.org/astro/IMG/svg/objectif.svg

Maïeul

ps : mon filtre maison prenait en compte l'entete xml.
De plus il supprimait un certains nombres d'attributs spécifiques à Inskipe, pas necessaire à l'affichage, et donc cela allegait la page. Je me demande si et dans quel mesure on pourrait intégrer cela dans le filtre "made in spip".

De gérer l’entete xml dans le filtre qui insere la balise dans le html vu que ça casse oui.
De nettoyer le svg, non, c’est intrusif, sujet à problème et ça n’a rien à faire dans cette fonction.
Ça pourrait être l’objet d’un filtre spécifique, mais c’est un autre sujet.

Tu vois qu’on a bien fait de mettre la fonction dans la 3.2.5 comme ça il y a des gens qui la testent, sinon personne n’aurait rien dit avant la release de la 3.3 :stuck_out_tongue: (mauvaise foi inclue)

De gérer l’entete xml dans le filtre qui insere la balise dans le html
vu que ça casse oui.

oui j'ai fait un pR (mais je suis pas sur que ce soit depuis/vers la
bonne branche)

De nettoyer le svg, non, c’est intrusif, sujet à problème et ça n’a
rien à faire dans cette fonction.
Ça pourrait être l’objet d’un filtre spécifique, mais c’est un autre
sujet.

je suis d'accord. Je me demandais simplement si par exemple on pouvait
pas mettre un pipeline a la fin du filtre, et chaque personne pourrait
se brancher dessus

Bonjour

> De gérer l’entete xml dans le filtre qui insere la balise dans le html
> vu que ça casse oui.
oui j'ai fait un pR (mais je suis pas sur que ce soit depuis/vers la
bonne branche)

A priori tu as fait comme il faut. De ce que je vois tu as créé une
branche depuis master (soit spip/ coté svn) et tu as bien un PR avec
le diff

Pour le report sur les branches maintenues, il y a 2 possibilités :
* les mainteneurs jouent avec git cherry-pick pour reporter le code
entre branches
* ouvrir autant de PR que de branches maitenues

Pour la lisibilité/facilité il me semble plus facile de considérer par
défaut le cas 1/. Il est toujours possible par la suite de demander à
ce que soit proposé les autres PR si besoin.

Note : si un demande est ouverte sur core.spip.net il est tout à fait
possible de continuer à utiliser "#demande" pour lier le commit à
celle ci.

Km