Attention, image_recadre et/ou image_reduire ne sont pas forcément disponibles si on n'a pas encore activé la config GD2 ou autre...
Oui c'est voulu depuis des années qu'il n'y a pas image_recadre ou ce genre de gros filtres dans l'admin, il n'y a que la réduction qui peut se faire (car fallback quand pas de lib serveur).
Il faut donc revert ça à priori.
L'autre jour je demandais : ya pas moyen de savoir si on a une lib configurée ou pas, et faire l'un ou l'autre ? Même avec un filtre dédié eventuellement (surchargeable du coup).
Genre #LOGO|image_transformation_prive
et un filtre_image_transformation_prive() avec dedans un test si ya pas de lib, une réduction simple, et si ya une lib, un image_recadre avec focus, par défaut
et en plus de ça, ça serait surchargeable si pour tel site on veut un truc perso
Ah zut…
Pas de souci s’il faut revert.
Mais je fais encore une tentative… Qu’est-ce que vous pensez de ceci:
[(#CONFIG{image_process}|=={gd2}|?{
[(#LOGO_ARTICLE_NORMAL|image_recadre{1:1,-,focus}|image_reduire{70,70})],
[(#LOGO_ARTICLE_NORMAL|image_passe_partout{70,70})]
})]
J’apprécie beaucoup la nouvelle présentation avec les vignettes bien zoomées, c’est vraiment agréable. Mais si je peux activer le recadrage intelligent dessus, c’est un vrai gros plus pour moi, puisque ça permet de visualiser une première fois qu’on a bien réglé le centre d’intérêt des images (quand on l’a fait). Alors que sinon, à l’inverse, le recadrage centré automatique (donc «défaillant» dans beaucoup de cas), alors qu’on a pris soin de régler le centre d’intérêt des images justement pour éviter les mauvais recadrage, ça introduit une impression de «bug».
ARNO*
Ce n’est pas une question d’activation de la config GD2 ou autre uniquement :
image_reduire est implémentée pour supporter 5 méthodes différentes (celles que l’on configure dans le privé) avec un fallback css.
On peut donc l’utiliser en toute confiance sans soucis.
Toutes les autres transformations d’image autres qu’une mise à l’échelle par contre, sont implémentées uniquement au moyen de GD2. Il faut donc que celle-ci soit disponible, ce qui n’est pas forcément le cas.
J’ai fait le revert du commit précédent (retour à un simple image_passe_partout).
=> J’avais proposé à la place:
[(#CONFIG{image_process}|=={gd2}|?{
[(#LOGO_ARTICLE_NORMAL|image_recadre{1:1,-,focus}|image_reduire{70,70})],
[(#LOGO_ARTICLE_NORMAL|image_passe_partout{70,70})]
})]
Sauf erreur, ça ne pose pas de problème de compatibilité, puisqu’image image_recadre ne fonctionne qu’avec gd2.
Mais c’est évidemment problématique (éventuellement) de faire des squelettes en fonction du choix de GD2.
=> Après, faudrait peut-être voir si conserver les choix alternatifs dans l’interface a encore du sens. Un serveur qui aurait les alternatives, mais pas GD2, ça me semble désormais difficile… Surtout qu’il n’y a vraiment que image_reduire qui fonctionne.
Du coup est-ce qu’on ne se simplifierait pas la vie à décider qu’il n’y a que deux cas: GD2 activé ou pas. C’est la logique du patch à base de #CONFIG{image_process}|=={gd2}, qui deviendrait: on a activé le traitement d’image ou pas.
ARNO*
En regardant de plus près, je pense que la solution serait de mettre dans le core un filtre |image_recadre_avec_fallback (ou meilleur nom à trouver) qui
• vérifierait qu’on a bien gd2 actif
• qu’on a bien le plugin filtres_images activé (car |image_recadre n’est pas dans le core et on essaye de gérer proprement les dépendances pour que le core ne casse pas si on retire des plugins-dist)
Si les 2 conditions sont remplies, le filtre ferait appel au vrai filtre |image_recadre,
et sinon produirait un fallback à base de image_passe_partout + un peu de html/css pour produire un contenu visuel dans les dimensions attendues (peut-être avec un conteneur en overflow:hidden ou avec un clip-path en style inline ou un peu des deux, bonne méthode à trouver)
On pourrait ainsi se reposer sur ce pseudo filtre dans l’espace privé (à condition de ne pas enchainer un autre filtre derrière, car si le filtre produit le fallback le résultat risque d’être imprévisible)
En regardant de plus près, je pense que la solution serait de mettre dans le core un filtre |image_recadre_avec_fallback (ou meilleur nom à trouver)
C'est… la toute première chose que j'ai immédiatement répondu hier déjà… 