Pb : on est sur du find_in_path, et donc on ne peut pas béneficier de la mécanique du core sur image_pack qui cherche d'abord le svg, puis le png si jamais...
a voir
Pb : on est sur du find_in_path, et donc on ne peut pas béneficier de la mécanique du core sur image_pack qui cherche d'abord le svg, puis le png si jamais...
a voir
Il faudrait probablement basculer sur find_in_theme : même signature, mais ça fait aussi la correspondance svg/png
Il faudrait probablement basculer sur [find_in_theme](https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/utils.php#L1467) : même signature, mais ça fait aussi la correspondance svg/png
Mais c'est de la merde ce icone_barre non ? Je vois pas pourquoi ça cherche dans un autre dossier à la racine comme ça… À la limite si c'était images/barre/truc.xxx pour pas conflicter avec images/truc là ok. Mais un tout autre dossier différent à la racine, c'est naze (encore plus quand un plugin quelconque veut ajouter un modele avec son icone et est obligé d'ajouter ce dossier en plus, ça fout du bordel inutilement pour une pauvre icone.
Mais c'est de la merde ce icone_barre non ? Je vois pas pourquoi ça cherche dans un autre dossier à la racine comme ça… À la limite si c'était images/barre/truc.xxx pour pas conflicter avec images/truc là ok. Mais un tout autre dossier différent à la racine, c'est naze (encore plus quand un plugin quelconque veut ajouter un modele avec son icone et est obligé d'ajouter ce dossier en plus, ça fout du bordel inutilement pour une pauvre icone.
C'est nul en effet, mais c'est parce que j'ai pas été cherché plus loin.
En fait il y a possibilité pour la barre typo d'avoir d'autres lieux que `icones_barre` (un find_in_path classique).
Du coup
316d578
(annulle et remplace le précédent commit)
Bon, j'ai finalement mis cette résolution dans le master, et pas seulement dans la branche v2.
Cela permet aux plugins compatible 3.2 d'en profiter, et c'est le but, notamment pour avoir l'alternance png/svg.
Bon, j'ai finalement mis cette résolution dans le master, et pas seulement dans la branche v2.
Cela permet aux plugins compatible 3.2 d'en profiter, et c'est le but, notamment pour avoir l'alternance png/svg.
Pb : on est sur du find_in_path, et donc on ne peut pas béneficier de la mécanique du core sur image_pack qui cherche d'abord le svg, puis le png si jamais...
a voir
Il faudrait probablement basculer sur find_in_theme : même signature, mais ça fait aussi la correspondance svg/png
oui, comme je l'ai fait pour saisies :
find_in_theme, puis, en fallback,find_in_pathEN fait ce n'est pas possible sans tout casser, car on prend dans le dossier
icones_barre. Cf mes remarques en5a4bf98Mais c'est de la merde ce icone_barre non ? Je vois pas pourquoi ça cherche dans un autre dossier à la racine comme ça… À la limite si c'était images/barre/truc.xxx pour pas conflicter avec images/truc là ok. Mais un tout autre dossier différent à la racine, c'est naze (encore plus quand un plugin quelconque veut ajouter un modele avec son icone et est obligé d'ajouter ce dossier en plus, ça fout du bordel inutilement pour une pauvre icone.
C'est nul en effet, mais c'est parce que j'ai pas été cherché plus loin.
En fait il y a possibilité pour la barre typo d'avoir d'autres lieux que
icones_barre(un find_in_path classique).Du coup
316d578(annulle et remplace le précédent commit)
attention, faut parfois du var_mode=recalcul pour ajuster les chemins.
Bon, j'ai finalement mis cette résolution dans le master, et pas seulement dans la branche v2.
Cela permet aux plugins compatible 3.2 d'en profiter, et c'est le but, notamment pour avoir l'alternance png/svg.