Je renouvelle ma demande de passer les logos à la racine du plugin svp.
OK je m’en charge sur les prochains plugins.
c’est possible de le noter quelque part dans la doc svp ?
Oui, je serais favorable… mais.
Ça marche la compat png-svg (3.2 - 4.0) si c'est pas dans prive/theme/ ?
MM.
Pour info même en 3.2 dans SVP, les logos *de plugin* en SVG marchent parfaitement, ils sont insérés dans un <img> ça marche pour n'importe quel type.
Cf https://git.spip.net/spip-contrib-extensions/dons/src/branch/master/paquet.xml#L7
que je vois bien en 3.2 comme il faut.
Moi je suis partisan de même pas mettre de XX dans ce cas : une image à la racine exactement du même nom que le préfixe du plugin.
Là où je me pose plus la question c'est : si l'image est *aussi* déjà utilisé dans l'interface pour des liens/boutons, dans ce cas elle va aussi être dans prive/theme : est-ce qu'il faut pas prévoir de quand même pouvoir déclarer cette image dans le XML dans le futur, histoire de réutiliser une existante, sans doublonner ? Sinon on va devoir mettre une même image à la fois à la racine et dans prive/theme si on l'utilise aussi ailleurs.
Mais pour les cas simple ou les cas où l'image du plugin n'est pas l'image d'un des objets ajoutés par le plugin, alors : une image à la racine *pile* du nom du préfixe.
Yop,
Ok moi ça me va, et c'est pas gênant vu qu'on parle de logo qui font 3ko quoi…
Et vu que ça marche déjà aussi en 3.2, il faudrait donc noter que désormais la recommandation c'est tout simplement : "une image du nom du préfixe à la racine", ni plus ni moins.
Plugin Patates => patates.svg à la racine
Simple et de bon goût.
Oui ca marche aussi en SPIP 3.2
J'ai donc adopté la nouvelle convention
https://git.spip.net/spip-contrib-extensions/spip-bonux/commit/f7cae6a8d955989eb99d4aa8ebff56101e93bcea
Salut Erational,
est-ce qu’on pourrait convenir de ne pas changer les compatibilités d’une branche sans en parler au mainteneur principal, ni de faire des tags à gogo ?
Là rien ne va :
1/ le plugin change de compat majeure en perdant sa compat 3.0 et 3.1 dans une simple release mineure
2/ le slogan et le logo du plugin changent
3/ et tout ça et joyeusement taggé et envoyé dans les zips chez tout le monde, va rattraper le bouzin
D’autre part, un bonux compat SPIP 4, dont le logo et le slogan change mérite une branche v4, car il y a des choses qui vont dégager car intégrée dans le core par exemple
Bref, c’est super cool pour l’icone, mais merci de pas y aller au bazooka sur les releases, ça fait 2 fois dans la semaine que je dois rattraper des releases foireuses
La règle c’est pas « pouf je fais un commit, je versionne le paquet je fais un tag » parce que c’est bien pénible et tout commit ne mérite pas un nouveau tag (en tout cas pour les plugins que je maintiens)
Hello Cédric
Oui désolé, je me suis laisser emporté par l’enthousiasme.
Je vais y aller mollo maintenant.
Merci pour ce rappel et désolé pour le travail de rattrapage que cela apporte.