> Avant de l'intégrer dans le core, il serait bien qu'il soit testé pas mal > et sur autant de configurations différentes que possible. > +1. D'autant plus qu'il faut gérer les cas aux limites (genre pour les configs qui ne supportent pas les redirect rules)
> > D'autre part il faut savoir que c'est potentiellement gourmand en place > disque et en ressource (au moment de la génération des images de > remplacement). > Pour ce qui est "place disque", si ça vient en remplacement des miniatures actuelles, ce ne sera pas forcément plus gourmand, si on limite le nombre de tailles. Et éventuellement gérer une expiration dans les miniatures générées pour faire du ménage. Coté ressources, ça en prendra une fois à la génération, après c'est le cache qui jouera (et on peut éventuellement prégénérer à la sauvegarde d'un billet par exemple). Niveau impacts, il faudra peut-être revoir la manière de nommer les miniatures, vu que les _t, _m, _sq n'auront plus vraiment de sens... Et il faut regarder les images insérées dans les billets vs les images de la page. Actuellement, de ce que je comprends, le plugin met indifféremment les 2 dans le même "panier" > > Cela dit, je veux bien discuter de ça quand vous voudrez sur IRC, pourquoi > pas la semaine prochaine (je suis en vacances cette semaine et pas trop sur > le net) ? > Pas de soucis, mais je pense que c'est un bon axe de réflexion à pousser. Et ça va dans les discussions sur les palettes de couleurs du wysiwyg, chaque thème pourrait avoir ses formats de miniatures selon la largeur de colonne qu'il définit (exemple de formats d'image : la moitié de largeur d'un article, un quart, hauteur/largeur en em, ...) -- Bruno -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
