Je ne sais pas si c’est un comportement voulu ou un bug, mais les boutons % pour redimensionner les images et le redimensionnement lui-même ne fonctionnent plus si l’image n’a pas de texte alternatif, alors que cela fonctionnait avant une mise à jour récente (il y a environ une semaine ?).
S’il y a plusieurs images dans le message et que l’une d’elles manque de texte alternatif, cliquer sur ses boutons % modifie le redimensionnement d’une autre image qui, elle, possède un texte alternatif (MODIF : je viens de changer la catégorie en bug car, même si le texte alternatif était nécessaire, cela ne devrait pas arriver).
Cela ne fonctionne plus, alors qu’il fonctionnait avant : 
Ajouter la partie alt| avant la taille de l’image le répare, comme prévu.
Je dois mettre à jour certains sujets pour m’adapter à cela – sinon ces images seraient à 100 % si elles étaient régénérées plus tard – et j’ai réalisé que cela pourrait être le cas pour d’autres aussi, d’où ce message.
Cela a fonctionné, j’ai plusieurs sujets dans mon instance avec la bonne mise à l’échelle mais sans texte alternatif. Si je régénère l’un d’eux, la mise à l’échelle disparaît.
Je n’ai rien trouvé qui expliquerait la différence lors de la cuisson des messages, cependant.
Je n’ai rien contre l’édition de ces sujets, mais d’autres pourraient aussi rencontrer cette situation et les contrôles de redimensionnement sur l’image sans alt ne devraient pas modifier l’échelle d’une autre image.
Ouais, on dirait que c’est bien mon changement. J’avais supposé que l’ancienne implémentation était un bug. Tous nos tests supposent que les dimensions apparaissent après le caractère | :
Je pourrais revenir à l’ancien comportement et ajouter un test pour m’assurer que cela continue de fonctionner. Mais cela signifierait qu’on ne pourrait jamais avoir d’image avec un texte alternatif du type 123x123.
@renato, sais-tu comment tu as pu te retrouver sans caractère pipe dans le markdown ? À ma connaissance, toutes les options de l’interface devraient en générer un avec un pipe
Oui, les publications où j’ai remarqué ce comportement ont toutes été créées via l’API avec un contenu brut prédéfini qui avait été testé auparavant dans l’interface. J’ai volontairement supprimé les textes alternatifs de deux images qui n’auraient pas beaucoup de sens pour un lecteur d’écran.
Je n’ai pas de problème à m’adapter au nouveau comportement si c’est ce que vous décidez finalement.
Hors sujet : puis-je demander une recommandation de plugin qui transforme [quelque chose] en contenu brut, comme inspiration pour un plugin de mon cru ? Ainsi, je pourrais simplement effectuer une autre édition sur tous ces sujets, et si je dois éventuellement les modifier à nouveau, une nouvelle cuisson (rebake) suffira.
Oui, je pense qu’il vaut mieux s’adapter à la nouvelle approche ici. Nous n’avons jamais vraiment prévu de le prendre en charge. Un support plus large pour davantage de formats signifie plus de code dans le backend et plus de tests.
D’accord, je vais donc simplement suggérer d’afficher les boutons de zoom uniquement sur les images qui peuvent être zoomées.
Ah oui, pour ce changement précis, je peux le faire, merci. Quoi qu’il en soit, ce n’est pas le seul endroit où j’ai un contenu brut prédéfini géré par un service externe ; peut-être pourrais-je trouver des idées dans poll — ou si vous vous souvenez d’une solution plus simple, faites-le-moi savoir.
Merci et désolé pour tout ce bruit à propos d’un si petit problème.
