Plugin SPIP : « Image responsive »

1

Plugin SPIP : « Image responsive »

20 mars 2015

par ARNO*

Le plugin « Image responsive », que j’ai créé en même temps que Cédric développait le plugin « Adaptive images », repose sur une logique sensiblement différente.

Les problématiques sont, à la base, les mêmes, dans le cadre d’un site responsive (c’est-à-dire qui s’adapte à la taille de l’écran du visiteur) :

afficher de grandes images sur un grand écran, et afficher de petites images sur un petit écran,
afficher des images « deux fois plus grandes » sur un écran à haute définition (notamment les smartphones et tablettes récents, mais aussi désormais certains ordinateurs portables), et afficher une image « normale » sur les autres écrans.

Mon problème est, avant tout, que j’ai des maquettes très personnalisées, et qu’une façon unique d’adapter les images sur l’ensemble du site ne me convient pas. Outre des images de grande taille, j’ai par exemple besoin de traiter les vignettes de navigation, qui s’affichent à différentes tailles sur différents supports, sans pour autant être de « grandes images ».

Le principe de ce plugin consiste à afficher (ou non) une vignette de l’image, puis à charger (dès que Javascript se déclenche) l’image définitive aux bonnes dimensions et à la bonne résolution. Depuis les dernières versions, il est de plus possible de créer avec le plugin des balisages HTML modernes qui permettent le fonctionnement responsive sans Javascript et facilitant le préchargement des contenus.

Au passage, le plugin permet d’automatiser un fonctionnement en « lazy load », c’est-à-dire le chargement des images uniquement lorsqu’elles sont visibles dans la page.

Je l’utilise en production depuis une bonne année, et je continue à le faire évoluer. On peut par exemple le voir fonctionner sur le site Flip-Zone (il est également en fonction sur les sites de la Fémis et les Arts décoratifs, mais dans des versions un peu moins optimisées).

Installation

Le plugin est disponible sur le site Plugins SPIP (et donc en installation et mise à jour automatiques via l’interface privée de SPIP), à partir de SPIP 3.0.

Si vous utilisez les URL « propres » dans SPIP, il faut modifier votre fichier .htaccess pour y ajouter le contenu du fichier ajouter_a_htaccess.txt livré avec le plugin.

Attention : votre travail ne fait alors que commencer. Contrairement à Adaptative images, ce plugin n’aura d’intérêt que si vous modifiez vos squelettes pour l’utiliser selon vos besoins. Si vous ne modifiez pas vos squelettes, il ne se passera rien…

La fonction `image_responsive`

Le principe est d’introduire une nouvelle fonction : image_responsive.

De base, elle fonctionne ainsi :

[(#LOGO_ARTICLE_NORMAL|image_responsive)]

Sans autre réglage, le fonctionnement sera le suivant :

une image de 120 pixels de large se chargera avec la page (mais l’image s’affichera « en grand », c’est-à-dire la largeur du bloc qui contient l’image – par exemple, si l’endroit où s’affiche l’image fait 300 pixels, on affichera ce fichier basse définition de 120 pixels de large, mais « agrandi » à la largeur de 300 pixels) ;
après le premier affichage de la page, un script calculera la largeur réelle du bloc d’affichage (dans notre exemple, 300 pixels), et remplacera l’image basse définition par une image de 300 pixels de large ;
si on redimensionne l’écran et que la largeur disponible pour afficher l’image est de 150 pixels, alors on chargera une image d’exactement 150 pixels ;
si on est sur un écran à haute densité (Retina dans le jargon Apple) et qu’on dispose de 300 pixels de large pour afficher l’image, alors on chargera un fichier de 600 pixels de large qu’on affichera sur cette largeur de 300 pixels (en haute densité donc).

Maquetter via les CSS

La balise <img> est ici remplacée par un code différent, et l’image elle-même est dans un conteneur plus complexe (qui peut, d’ailleurs, changer en fonction des versions du plugin, de façon à intégrer les dernières possibilités du HTML5). De fait, il ne faut plus contrôler le style de l’image, en particulier sa largeur d’affichage, via la balise <img> elle-même, mais par l’élément qui la contient – le résultat du filtre image_responsive occupera de toute façon toute la largeur disponible de son conteneur).

Par exemple, il faudra bien prendre soin à intégrer l’image responsive dans un conteneur, div ou span selon les besoins, que l’on pourra ainsi maquetter via les CSS (c’est bien tout l’intérêt, puisqu’on fait du responsive) :

[<div class="logo">(#LOGO_ARTICLE_NORMAL|image_responsive)</div>]

Le travail de maquette se fera donc dans le style de div.logo, et non plus directement sur l’image elle-même. L’image, dans tous les cas, occupera toute la largeur disponible fixée par div.logo.

Emplacement de l’image pré-réservé

Puisque l’image va occuper toute la largeur, la balise <img> ne peut plus contenir d’indications de height et de width. C’est classique en responsive (puisque la taille d’affichage des images va varier selon l’écran), mais cela pose le problème classique de pré-réserver l’espace occupé par l’image.

Classiquement, on indiquait dans le code HTML les dimensions de l’image pour que l’affichage de la page commence en réservant l’espace correct de l’image, avant même de l’avoir chargée. Sinon, cela donnait l’effet désagréable d’afficher la page sans l’image puis d’avoir tout le texte qui se déplace violemment une fois que le navigateur a chargé l’image.

Le plugin fabrique automatique le code HTML/CSS qui permet de pré-réserver l’emplacement correct de l’image, sans utiliser height et width (le plugin va utiliser un padding-bottom en pourcentage de la largeur, permettant de définir les proportions du bloc image sans connaître ses dimensions en pixels). C’est donc transparent pour le webmestre, mais ne vous étonnez donc pas de l’absence de height et de width dans le code généré (surtout si PageSpeed vous le réclame) : c’est fait exprès, et le code généré est conçu justement pour contourner leur absence.

Première subtilité : des images réduites plus nettes

Une première difficulté que le plugin a dû contourner, c’est le fait que plus on réduit la taille d’une image, plus elle semble légèrement « floue », ou un peu « molle ». C’est un problème classique lorsqu’on prend une image de grande taille et qu’on la réduit à la taille d’une vignette

Ce qu’on pouvait résoudre dans SPIP, auparavant, en faisant passer un filtre de renforcement de netteté après une réduction de taille (par exemple image_renforcement{0.1}).

Ce plugin introduit une nouvelle fonction, image_reduire_net que l’on peut utiliser à la place de image_reduire. À partir de PHP 5.1 (utilisation de imageconvolution), cette fonction va réduire et renforcer l’image réduite, et cela en fonction du redimensionnement (plus la vignette est petite par rapport à l’image d’origine, et plus on va renforcer la netteté). Sur PHP avant 5.1, le script devrait fonctionner très bien, mais sans le renforcement de la netteté.

En pratique, c’est totalement transparent pour le webmestre : le simple fait d’utiliser le filtre image_responsive va faire calculer les images plus petites avec cette nouvelle fonction, et on maintiendra donc automatiquement les images à un niveau de netteté cohérent.

Deuxième subtilité : des images haute définition de poids raisonnable

Attention : ce comportement est désactivée à partir de la version 7.6.0 du plugin (mai 2019) : les images haute définition sont désormais identiques aux images deux fois plus grandes compressées normalement, de façon à préserver la qualité d’affichage (au détriment, donc, du poids des fichiers). On peut rétablir le comportement « ultra-compressé » des images sur écran haute définition en ajoutant :

define("_IMAGE_RESPONSIVE_RETINA_HQ", true);

Un (énorme) souci avec la gestion de la haute définition, c’est qu’on se retrouve à envoyer des images avec quatre fois plus de pixels à destination des écrans haute densité, qui sont actuellement très majoritairement des écrans de smartphones. Pour afficher une image de 320x240 pixels à l’écran, on charge un fichier de dimensions 640x480 pixels : quatre fois plus de points, mais surtout un fichier JPEG sept fois plus lourd, alors qu’on a une connexion moins rapide qu’à la maison (j’ai posté sur Seenthis une explication avec un exemple d’image qui passe de 22ko à… 169ko de cette façon).

La solution ici consiste, lorsqu’on appelle les images à haute densité, à créer des fichiers JPEG beaucoup plus compressés. Après différents essais, j’ai décidé de fabriquer des JPEG compressés en qualité 50% au lieu de 85% habituels de SPIP. À l’usage, cela nous semble le bon équilibre entre le poids du fichier et le fait qu’on ne perçoive pas la dégradation de l’image. Attention : si on affiche une telle image sur un écran de densité « normale », alors on verra un fichier JPEG très dégradé ; mais sur un écran à haute densité, on ne parvient pas à détecter les artefacts de compression. Mais on perçoit bien, en revanche, cette impression de « haute densité » des images par rapport à l’utilisation d’images « normales ». (Dans l’exemple sur Seenthis, l’image haute densité revient à un poids de 34ko, bien plus raisonnable que les 169ko obtenus sans cette astuce.)

À l’usage, on expédie ainsi des images avec quatre fois plus de points, mais dans des fichiers dont le poids est seulement 30% plus lourd qu’une image de taille normale.

Troisième subtilité : une fonction pour recadrer une image sans la réduire

Puisque le plugin gère lui-même des réductions de taille des images selon les critères nécessaires (taille réelle d’affichage, mais aussi densité de l’écran), il devient très habituel de simplement lui faire passer l’image d’origine, sans se soucier de sa taille. On ne va donc plus gérer des |image_reduire, puisque le plugin va faire « mieux » automatiquement.

On a alors une difficulté si on a pris l’habitude de normaliser les proportions des images (par exemple toutes les vignettes de navigation dans un format 16x9, pour donner un aspect esthétique cohérent et élégant) : le filtre image_recadre fonctionne sur des valeurs absolues.

Le plugin introduit donc une fonction supplémentaire, destinée à remplacer image_recadre : image_proportions. Si je veux une image recadrée en 16x9, je fais simplement :

[(#LOGO_ARTICLE_NORMAL|image_proportions{16,9})]

J’obtiens alors une image aux proportions 16x9, mais conservant une de ses dimensions d’origine (si l’image d’origine fait 1200x800 pixels, j’obtiens après ce filtre une image de 1200x675 pixels ; si l’image d’origine fait 300x240 pixels, j’obtiens après ce filtre une image de 300x169 pixels).

Évidemment, l’idée est ici de l’utiliser juste avant le filtre image_responsive.

Retour à `image_responsive` : fixer des tailles autorisées

Nous en sommes donc toujours à utiliser le filtre de manière automatique :

[(#LOGO_ARTICLE_NORMAL|image_responsive)]

Si c’est bien pratique pendant la phase de fabrication du site, une fois que le site est réellement actif et visité par le public, ce fonctionnement entièrement automatique devient très problématique : si les tailles d’affichage de l’image ne sont pas strictement définies par les CSS, on risque de fabriquer des centaines de versions de cette image (selon les différentes tailles d’écran des visiteurs).

Il est donc important, une fois qu’on a bien compris les tailles d’affichage que l’on va réellement utiliser pour cette image en fonction de nos scénarios responsive, les différentes tailles autorisées :

le premier intérêt étant évidemment de limiter le nombre de fichiers fabriqués par le plugin,
le second étant de préparer l’utilisation d’un balisage HTML5 particulièrement efficace (voir plus loin dans cette documentation).

Commençons par un cas extrême : je n’autorise qu’une seule taille d’affichage. Il y a de nombreux cas où c’est pertinent (parfois : petit logo du site, ou petits boutons de partage…). On indique directement cette taille ainsi :

[(#LOGO_ARTICLE_NORMAL|image_responsive{150})]

Quelle que soit la taille d’affichage final de l’image, on charge une image de 150 pixels de large (si on n’est pas idiot, il y a des chances que la taille d’affichage réel sera bien 150 pixels…). Mais attention : ce n’est pas équivalent à image_reduire{150} (ni même image_reduire_net{150}). Si l’écran du visiteur est à haute densité (smartphone récent notamment), alors le plugin va automatiquement charger une seconde version de l’image : une image de 300 pixels de large (éventuellement plus compressée s’il s’agit d’un JPEG).

Le code précédent, indiquant une taille unique, autorise en fait l’utilisation de deux fichiers différents, ce qui permet de faire un affichage « simple » qui sait s’adapter à un écran haute densité. (Nous verrons plus loin que, dans ce cas, un balise HTML moderne est directement fabriqué par le plugin.) C’est très adapté pour ces petits boutons-outils, du style boutons de partage sur Facebook/Twitter, qui apparaissent toujours à la même taille sur les différents supports, mais qu’on veut passer en double-définition sur écran Retina.

Si la taille unique répond à la problématique des écrans haute densité, elle ne suffit pas pour gérer les différentes tailles d’affichage selon des tailles d’écran. Par exemple, une image occupant toute la largeur de l’écran (écran qui fera les 320 pixels d’un smartphone « usuel » tenu verticalement, jusqu’à un écran de 1920 pixels de large). C’est le problème central du responsive : je ne peux pas utiliser simplement l’image de 320 pixels sur un écran de 1920 pixels, ça serait très laid (image extrêmement pixelisée), comme je ne veux pas expédier une image de 1920 pixels, extrêmement lourde, pour finalement l’afficher sur un tout petit écran de 320 pixels. Comme on l’a vu, ce problème est résolu automatiquement par le plugin sans avoir besoin d’indiquer des variables, mais avec le risque alors de fabriquer autant de fichiers qu’il existe de largeurs de fenêtres (disons 1920-320 = 1600 variantes de l’image). On se retrouve à fabriquer des giga-octets d’images si on laisse le filtre sans limites.

On va donc indiquer les différentes tailles d’images que l’on autorise en les séparant par un slash :

[(#LOGO_ARTICLE_NORMAL|image_responsive{160/320/480/640/960/1440/1920})]

Cela signifie que, si la taille d’affichage est inférieure à 160 pixels (par exemple 120 pixels), on charge l’image de 160 pixels (mais on l’affiche plus petite, sur une largeur de 120 pixels), puis de 320 pixels jusqu’à 320 pixels, etc.

En pratique, je limite encore largement le nombre de variantes. Si on parvient à réduire à 3 ou 4 valeurs autorisées, c’est aussi bien, puisqu’on calculera alors beaucoup moins d’images.

Effet de bord induit : on fait travailler PHP sur chaque image

Arrivé à ce stade, il est important de comprendre que les images ne sont pas « pré-calculées » au moment du calcul de la page, comme c’est le cas habituellement avec SPIP (si je fais image_reduire, je fabrique l’image réduite au moment où je calcule la page). Avec ce plugin, je ne fabrique rien d’autre que le balisage HTML, et le fichier « image » qui est appelé est en fait une page PHP (d’un genre spécial : qui fabrique la vignette de l’image).

Bien entendu, il y a un système de cache de fichier pour chaque taille d’image déjà visitée, mais on se retrouve tout de même à déclencher un script PHP à chaque hit sur ce « fichier image » (ce script PHP se faisant évidemment passer pour une image).

Une fois la taille d’image calculée, ce script est très rapide et travaille peu, mais il y a de l’occupation de mémoire, une instance qui tourne, etc. Sur un site à fort traffic et/ou avec beaucoup d’images, ça peut demander une adaptation de la configuration.

Et finalement, sur un site très visité et/ou avec beaucoup d’images, la meilleure solution sera sans doute d’installer Varnish et de bien veiller à ce que les images responsive passent bien par son cache. (C’est ce que je fais sur Flip-Zone, qui contient plus de 100.000 images très grandes, toutes gérées désormais via image_reponsive.)

Contrôler le cache du plugin

Le plugin va donc fabriquer des images en fonction de leur taille d’affichage. Les images calculées sont logiquement installées dans un sous-dossier de /local, que l’on peut contrôler et vider dans la page « Vide le cache » de l’espace privé, dans le pavé « Images calculées automatiquement ».

Le plugin ajoute cependant un pavé supplémentaire dans la page « Vider le cache » de l’espace privé de SPIP : « Images pour responsive ». En effet, sur un site avec beaucoup d’images, vider complètement le cache /local peut s’avérer très violent. Or, il y a certainement des tailles d’images qui sont certainement beaucoup moins utilisées que d’autres.

Ce nouveau pavé de contrôle du cache va afficher le poids occupé par « toutes les images », les images « non vues depuis 3 jours », les images « non vues depuis une semaine », « un mois », « 3 mois ». On peut alors effacer sélectivement ce que l’on veut (supprimer images réduites qui n’ont pas été vues depuis un mois ne va certainement pas pénaliser le serveur). Note : cette fonction se base sur le atime(), et ne fonctionnera donc pas si on l’a désactivé sur ce disque dur pour faire tourner le serveur plus rapidement.

Sur un site où l’on a bien conçu et limité les tailles autorisées des images, on ne devrait pas avoir réellement d’images qui sont rarement consultées. Mais cela demande de l’habitude, et avant de réussir à bien cerner les tailles pertinentes, ce troisième pavé permet de gérer plus finement ses nettoyages de cache et éventuellement signaler qu’il faut modifier ses squelettes pour tenter d’optimiser la fabrication de tailles d’images peu utilisées.

Avec ou sous sans vignette au chargement de la page

Le principe de base du plugin est donc de charger la page HTML avec une balise <img>, puis de charger l’image à la bonne taille une fois que la page a été affichée.

La question est de savoir ce qu’on veut afficher dans ce <img> dès le chargement de la page et avant le déclenchement du script.

1. Par défaut. Si on n’a défini aucune taille autorisée, l’image par défaut sera une vignette de 120 pixels de large.

2. Première taille autorisée. Si on a défini une ou plusieurs tailles autorisées, alors c’est la première taille indiquée qui sera chargée avec la page. Dans notre exemple, c’est donc une image de 160 pixels de large qui est chargée avec la page avant le lancement du script :

[(#LOGO_ARTICLE_NORMAL|image_responsive{160/320/480/640/960/1440/1920})]

Visuellement, si on est sur une taille d’affichage nettement plus grande, on obtient l’effet visuel suivant :

dès l’apparition de la page, l’image de grande taille apparaît très pixellisée,
après lancement du javascript, la « bonne » image apparaît donc.

Selon l’usage qu’on en a, ce n’est pas réellement gênant (à une époque, on avait une même une balise HTML pour faire ça, et cela produit visuellement une impression similaire au chargement d’un JPEG progressif).

3. Rien. En revanche, si l’image définitive n’est pas la version 160 pixels en densité normale, alors on déclenche deux appels au serveur au lieu d’un. Dans certains cas, on peut juger que c’est une mauvaise idée.

Dans ce cas, on peut indiquer que l’on ne veut pas charger de vignette au chargement de la page. (Solution pour l’instant : on charge quand même un petit fichier, qui est rien.gif. Je pense essayer faire autrement dans le futur.) Pour cela, il suffit d’ajouter la taille « 0 » (le chiffre zéro, évidemment) au début des tailles autorisées :

[(#LOGO_ARTICLE_NORMAL|image_responsive{0/160/320/640/1280/1920})]

Charger uniquement les images visibles : mode lazyload

Sur un site avec des pages un peu longues (les pages Web deviennent d’ailleurs habituellement beaucoup plus longues quand elles sont affichées du smartphone…), on peut vouloir charger les images uniquement si elles sont visibles à l’écran. C’est le principe du lazy load.

En théorie, les navigateurs savent charger les images de manière « intelligente », en commençant en priorité par les images visibles. Mais cette méthode permet de le gérer via notre propre script, et d’être certain de ne pas charger ce qui n’est pas visible.

Pour cela on utilise une seconde variable du filtre, que l’on va fixer à 1 si l’on veut charger cette image en lazy load (par défaut : 0) :

[(#LOGO_ARTICLE_NORMAL|image_responsive{0/100/200, 1})]

Ici : je ne charge rien au chargement de la page, et le script ne chargera une image de 100 ou 200 pixels (en basse ou haute densité) que si l’image est visible à l’écran (en fait : on prévoit de la marge sur cette notion de « visible », pour que les images juste en dessous de la ligne de scroll soient déjà chargées).

Alignement vertical

Le principe de base est de calculer la taille de l’image selon la largeur disponible à l’endroit où elle s’affiche. C’est l’utilisation la plus commune des images dans une maquette Web.

Avec cette variable supplémentaire (que l’on fixe à 1 si on veut ce fonctionnement ; sinon la valeur par défaut est 0), on peut forcer le calcul non plus sur la largeur de l’espace disponible, mais sur sa hauteur :

[(#LOGO_ARTICLE_NORMAL|image_responsive{150/300, 0, 1})]

Ici : on affiche une vignette de 150 pixels au chargement du HTML, puis on calcule si on charge une image de 300 pixels de haut si la hauteur disponible pour cette image est plus grande que 150. (Et on ne fonctionne pas en lazy load, la seconde variable étant laissée à 0.)

Le balisage responsive directement en HTML5

Depuis quelques temps, il existe des balisages directement en HTML5, permettant de gérer des images responsive sans attendre le déclenchement de Javascript et en profitant des optimisations des navigateurs (preloading). Le plugin permet d’introduire ces balises.

L’intérêt est de permettre au navigateur de pré-charger les image de manière intelligente, ou au moins de lancer leur chargement en même temps que la page HTML et de les afficher directement aux bonnes dimensions sans attendre le lancement du script. On a une impression de fluidité et de vitesse de l’affichage qui est bien meilleur, à la fois sur les pages jamais visitées et sur les pages déjà visitées.

Mise à jour 2017. Ces balisages du HTML5 sont désormais largement répandus dans tous les navigateurs. Je recommande désormais absolument d’utiliser ces spécificités du plugin, le rendu à l’écran s’en trouve très largement amélioré (impression d’« immédiateté » dans l’affichage des images). Notez bien que, pour les navigateurs qui ne comprennent pas nativement ces balises, un script Javascript fournit automatiquement assurera l’affichage correct.

1. scrset. La première méthode est appliquée automatiquement si l’on utilise une taille unique pour l’image :

[(#LOGO_ARTICLE_NORMAL|image_responsive{150})]

dans ce cas, le code HTML fabriqué par le plugin, sans aucune intervention supplémentaire de votre part, va ajouter un srcset à la balise <img> permettant de gérer directement les densité 1x et 2x.

Cette méthode est très simple à utiliser, et s’applique très bien aux vignettes de navigation, dont la taille d’affichage ne varie pas beaucoup selon les dimensions de l’affichage.

Mise à jour 2017. Selon CanIUse.com, tous les navigateurs actuels comprennent cette balise ; plus de 85% des utilisateurs en profitent.

2. picture. La seconde méthode demande un investissement plus important de votre part, mais le résultat est incomparable, puisqu’il permet un contrôle très riche de ce qu’on affiche.

Mise à jour 2017. Désormais plus de 89% des utilisateurs profitent de cette balise.

Il faut pour cela utiliser une quatrième variable à notre filtre, relativement complexe cette fois, contenant les media queries pour chaque des tailles d’image autorisées. Par exemple :

[(#LOGO_ARTICLE_NORMAL
|image_responsive{
0/50/100/200,
0,
0,
(max-width:470px)/(max-width:1009px)/
})]

Télécharger

Explication :

avec la première variable (0/50/100/200), je charge la page sans vignette (en fait : rien.gif), et j’autorise le chargement d’images de largeur 50, 100 ou 200 pixels ;
la seconde variable est à zéro, donc pas de lazy load ;
la troisième variable est à zéro, donc la calcul se fait bien sur la largeur disponible ;
la quatrième variable ((max-width:470px)/(max-width:1009px)/) est celle qui va permettre de mettre en place le code HTML5 gérant nativement les images responsive.

Cette variable doit contenir autant d’entrées qu’il y a de tailles de fichiers autorisées, séparées par des slash. Dans la première variable, il y a trois tailles autorisées (50, 100, 200 – la taille « 0 » n’est pas une taille autorisée, elle ne fait qu’indiquer qu’on charge la page sans vignette). Nous avons donc ici trois valeurs de media queries séparées par des slash :

(max-width:470px)
(max-width:1009px)
et… rien. Ce sera donc la valeur « par défaut » si les deux autres ne s’appliquent pas. Notez qu’il faut bien un slash pour définir cette valeur « vide » dans la dernière variable.

La logique est donc :

si l’écran fait 470px et moins, je charge l’image de 150 pixels, en simple ou double densité selon l’écran (1x ou 2x),
si l’écran fait 1009px et moins, je charge l’image de 100 pixels, en simple ou double densité,
au-delà je charge l’image de 200 pixels (1x ou 2x)

Il y a ici deux difficultés pour vous :

la première, c’est qu’il faut absolument que vos valeurs de media queries indiquées soient cohérentes avec les valeurs utilisées dans vos CSS, sinon vous risquez de lancer des chargements d’image pour rien ; dans certains cas, ce n’est pas évident…
c’est difficile à tester, parce que de toute façon le javascript va se déclencher après le premier affichage de la page ; pour vérifier le code généré, désactiver javascript dans un navigateur compatible (aujourd’hui : Chrome).

Par rapport au fonctionnement « simple » du plugin (définir des tailles autorisées), c’est nettement plus contraignant, pour un affichage final de la page totalement identique. En revanche, pendant le chargement et l’affichage de la page, l’effet de fluidité et de rapidité est incomparable (en règle générale : tout ce que vous parvenez à afficher correctement sans attendre Javascript est un gain énorme pour l’expérience de navigation). Je pense que ça vaut vraiment le coup de s’embêter un peu…

Et par rapport à un simple usage de picturefill.js (parce qu’alors ça revient à ça…), le code HTML est vraiment plus facile à générer avec ce plugin qu’à la main. Jetez un coup d’œil, ça fait tout de même un sacré bestiau :

<picture
style="padding:0;padding-bottom:126.84989429175%"
class="conteneur_image_responsive_h"
>
<source media="(max-width:470px)" srcset="/local/cache-couv/f/f58b4d3df25bd84fe7f9fddf405e260f-resp50.jpg 1x,/local/cache-couv/f/f58b4d3df25bd84fe7f9fddf405e260f-resp50-2.jpg 2x">
<source media="(max-width:1009px)" srcset="/local/cache-couv/f/f58b4d3df25bd84fe7f9fddf405e260f-resp100.jpg 1x,/local/cache-couv/f/f58b4d3df25bd84fe7f9fddf405e260f-resp100-2.jpg 2x">
<source srcset="/local/cache-couv/f/f58b4d3df25bd84fe7f9fddf405e260f-resp200.jpg 1x,/local/cache-couv/f/f58b4d3df25bd84fe7f9fddf405e260f-resp200-2.jpg 2x">
<img src="rien.gif" data-src="/local/cache-couv/f/f58b4d3df25bd84fe7f9fddf405e260f.jpg" data-l="473" data-h="600" data-tailles="[\"50\",\"100\",\"200\"]" class="image_responsive">
</picture>

Télécharger

Vous constaterez que, par rapport aux démonstrations habituelles de <picture>, ici on prend bien soin à gérer la densité de l’écran avec des images JPEG différentes (l’image haute définition n’est pas simplement l’image deux fois plus grandes, elle est aussi beaucoup plus compressée en JPEG pour éviter de livrer des images 7 fois plus lourdes là où notre système livre des images seulement 1,3 fois plus lourdes).

Image adaptative, recadrage et direction artistique

Ajout 2017. Le filtre image_responsive autorise le recadrage de l’image en fonction de la dimension finale d’affichage, en utilisant les media queries. C’est là une fonctionnalité extrêmement puissante.

Pour cela, nous utilisons une série supplémentaire de configurations, après la liste de media queries, constituées de valeurs séparées par des slash. Ces valeurs correspondent aux variables de la fonction image_proportions : largeur, hauteur, alignement du recadrage (top, left, …, focus, focus-center), et zoom (par défaut : 1).

Voici par exemple l’affichage d’une image sur toute la largeur de l’écran, en changeant le recadrage selon la taille de l’écran :

[(#LOGO_ARTICLE_NORMAL
|image_responsive{0/480/800/1280/1920,
0, 0,
(max-width: 480px)/(min-width:481px) and (max-width: 800px)/(min-width:801px) and (max-width:1280px)/,
1x1xfocusx1.5/5x4xfocusx1.2/3x2xfocus/2x1xfocus
})]
</spip>

Télécharger

Nous avons ici 4 tailles autorisées, correspondant à 4 media queries, avec 4 recadrage différents :

— image de 480 pixels de large, si (max-width: 480px), avec un recadrage 1x1xfocusx1.5, c’est-à-dire un recadrage carré (1x1) selon le centre d’intérêt de l’image, avec un zoom de 150% ;

— image de 800 pixels de large, si (min-width:481px) and (max-width: 800px), avec un recadrage 5x4xfocusx1.2, c’est-à-dire un recadrage légèrement aplati (5x4) selon le centre d’intérêt de l’image, avec un zoom de 120% ;

— image de 1280 pixels de large, si (min-width:801px) and (max-width:1280px), avec un recadrage 3x2xfocus, c’est-à-dire un recadrage horizontal (3x2) selon le centre d’intérêt de l’image, sans zoom dans l’image ;

— image de 1920 pixels de large le reste du temps (pas d’indication explicite après le dernier slash de la série de media queries) avec un recadrage 2x1xfocus, c’est-à-dire un recadrage très horizontal (2x1) selon le centre d’intérêt de l’image, sans zoom dans l’image.

Voici un autre code, que j’utilise pour « remplir » l’écran de la page d’accueil selon l’orientation de l’écran (ce n’est pas un « remplissage » exact de l’écran, mais un recadrage qui, grosso modo, correspond à l’orientation de l’écran ; pour l’utilisateur l’effet est très similaire, en revanche ça permet de précharger la bonne image dès le chargement de la page). Noter ici le fait que j’utilise deux fois la même série de valeurs de largeur, mais avec des media queries différents et des recadrage différents (pour gérer l’orientation de l’écran) :

[(#LOGO_ARTICLE_NORMAL|image_responsive{
0/480/800/1280/1920/480/800/1280/1920,
0, 0,
(max-width: 480px) and (orientation:portrait)/(min-width:481px) and (max-width: 800px) and (orientation:portrait)/(min-width:801px) and (max-width:1280px) and (orientation:portrait)/(min-width:1281px) and (orientation:portrait)/
(max-width: 480px)/(min-width:481px) and (max-width: 800px)/(min-width:801px) and (max-width:1280px)/,
4x5/4x5/4x5/4x5/3x2/3x2/3x2/3x2
})]

Télécharger

Un aspect vraiment important ici, c’est que le code HTML5 généré utilise le balisage <picture>, et que le chargement de ces images est ultra-efficace (préchargement, et affichage immédiat quand on revient sur une page déjà visitée).

Précalculer les images

L’une des difficultés du plugin est de passer par un script PHP à chaque fois qu’une image est affichée. (La configuration du fichier .htaccess décrite dans la partie « Installation » ci-dessus rend cet appel transparent, mais c’est bien un script qui se déclenche pour afficher une image.)

Une solution pour limiter le passage par ces scripts est d’installer un proxy inverse, tel Nginx ou Varnish, en veillant à le configurer pour qu’il passe bien les images dans son cache. De cette façon, évidemment, on limite énormément les appels de scripts sur le serveur Web.

Si l’on n’a pas cette possibilité, et si le serveur a tendance à ne pas tenir la charge, la solution consiste à demander au plugin de pré-calculer les images pour toutes les tailles, et à les stocker sur le serveur et, ainsi, à fonctionner avec des appels directs aux fichiers d’images statiques. Cela se fait en configurant _IMAGE_RESPONSIVE_CALCULER ainsi :

define("_IMAGE_RESPONSIVE_CALCULER", true);

Une fois les images calculées, le serveur Web se retrouve à gérer des fichiers d’images directement, sans nécessiter aucun script PHP. En revanche, il y a deux inconvénients : (a) le temps de calcul initial de la page est nettement allongé, parce qu’il faut pré-calculer toutes les versions des images, (b) on pré-calcule toutes les tailles prévues dans le script, plutôt que d’attendre qu’elles soient réellement appelées par un visiteur. On fabrique ainsi beaucoup plus d’images dans le cache de SPIP, possiblement pour des tailles d’images qui ne sont pas réellement utilisées en pratique.

Créer des liens vers les fichiers d’images

Lorsqu’on veut aspirer le site Web (pour une installation en local, pour fabriquer une application…), les outils qui réalisent cette opération (tel wget) ont tendance à ne pas bien comprendre les codes HTML5 les plus récents, tels qu’ils sont fabriqués par ce plugin (<picture>, <source>, srcset…), et n’« aspirent » alors pas tous les fichiers d’images nécessaires.

Pour ajouter au code source de la page des liens que ces outils seront capables de « suivre » pour télécharger tous les fichiers nécessaires, on peut définir la variable suivante :

define("_SPIP_LIER_RESSOURCES", true);

Des balises <link href="…" ' rel='attachment' property='url'> seront alors insérées dans le code de la page.

Et pour des images en background ?

One more thing…

Il y a une autre fonction, qui permet de gérer des images responsive en background d’un élément. Par exemple cet exemple utilisé sur les site des Arts décoratifs :

<div class="logo">
<a
href="#URL_RUBRIQUE"
[(#LOGO_RUBRIQUE_SURVOL|background_responsive{240/480/600/960})]>
</a>
</div>

Télécharger

Il n’y a donc pas ici de <img> : l’image responsive s’installera en fond (background) de la balise <a> et couvrira tout le conteneur (quitte, donc, à « déborder » de manière invisible du bloc).

C’est d’un usage nettement plus spécifique que les images responsive « normales », mais ça peut être intéressant pour plusieurs raisons :

si le conteneur (ici <a>) est plus haut que large (par exemple il occupe toute la taille d’un écran de smartphone vertical), alors l’image est recadrée verticalement avant d’être affichée ; cela permet d’éviter d’avoir une image de logo horizontale, affichée dans une boîte verticale (par exemple : l’écran), avec la moitié de l’image n’est donc pas affichée à l’écran). De cette façon, on optimise la taille de l’image non seulement selon la taille de l’écran, mais aussi selon l’orientation du bloc qui la contient ;

travailler avec une image en fond permet de réaliser des fonds en positionnement fixed, ce qui est indispensable avec certains effets de « parallaxe ».

En revanche, ici, on a le droit de passer en lazy load, mais rien d’autre. Pas d’option d’alignement vertical (c’est inutile, puisque le plugin va charger l’image pour qu’elle couvre toute la boîte horizontalement et verticalement), ni surtout de balisage HTML avancé.

Format WebP

Puisque image_responsive fabrique un beau code HTML à base de <picture> contenant éventuellement des <source>, le plugin est capable de proposer de manière transparente aux navigateurs (Chrome et Firefox pour l’instant) qui gèrent ce format, les versions des images en WebP.

Pour cela, il faut que votre version de PHP soit capable de fabriquer des images au format WebP (c’est désormais généralement le cas), et vous devez définir dans mes_options.php une nouvelle constante :

define("_IMAGE_WEBP", true);

(Cette nouvelle fonctionnalité est introduite avec la version 7.7 du plugin. En cas de mise à jour d’une version plus ancienne, pensez à mettre à jour votre fichier .htaccess avec une nouvelle ligne supplémentaire.

Correction du bruit dans la transparence

Un bug rare sur certains serveurs ajoute un très léger bruit dans les zones de transparence des images PNG et WebP. Et ça peut se voir.

Si cela arrive, on peut activer une correction systématique des transparences des images PNG et WebP, ainsi :

define("_IMAGE_CORRIGER_BRUIT_TRANSPARENT", true);

Mai 2015

Il semble que le plugin pose problème sous spip 3.0.17 Conflit avec Jquery qui ne fonctionne plus sur l’interface privée
Hervé Le Dantec

Mars 2017

Bonjour Arno,

Je m’arrache les cheveux depuis plusieurs jours face à une énigme : Soit 2 sites spip 3.1.4 utilisant les mêmes squelettes (squelettes dérivés de squelettes-dist) et les mêmes plugins. image_responsive fonctionne sur l’un des sites mais pas sur l’autre !?

Exemple de code pour le squelettes/inclure/header.html :

<div class="clearfix header"> <div class="titre_logohome" > [(#ENV{home,'non'}|=={oui}|?{ [<div class="logo" >(#LOGO_SITE_SPIP|image_responsive{900/600})</div>]<h1 id="logo" >#NOM_SITE_SPIP</h1> , <a rel="start home" href="#URL_SITE_SPIP/" title="<:accueil_site:>">[<div class="logo" >(#LOGO_SITE_SPIP|image_responsive{900/600})</div>]<h1 id="logo" >#NOM_SITE_SPIP</h1></a> })][<h2 id="slogan" >(#SLOGAN_SITE_SPIP)</h2>] <div class="bandeauVignettes"> <BOUCLE_bandeauVignettes(DOCUMENTS){id_article=1}{extension==jpg|png|gif}{mode=document}{doublons}> [<div class="logo">(#FICHIER|image_responsive{900/600/400/200}|inserer_attribut{alt, #TITRE|attribut_html})</div>] </BOUCLE_bandeauVignettes> </div> </div>

Merci d’avance,

Cordialement,

Hervé
ARNO*

Mars 2017

Ça ne viendrait pas des versions de PHP, plutôt ? La réduction se fait avec une fonction image_reduire_net() au lieu de image_reduire().
mono

Avril 2017

Salut ! Merci pour ce plugin ! Je tente d’installer le plugin sur une configuration nginx, mais je n’arrive pas à "traduire" le config Apache en Nginx ! Est-ce que vous avez une idée ? Merci par avance,
Hervé Le Dantec

Août 2017

Bonjour Arno,

Sous SPIP 3.2.0-beta3 SVN [23687] et Filtre image_responsive 7.5.2 SVN [104718], le plugin s’installe, mais ça ne fonctionne pas : L’image ne s’affiche pas et pour cause, aucun dossier "/local/cache-responsive/" ne s’est créé.

Bien entendu, je sais bien qu’il s’agit d’une utilisation avec un spip svn encore en beta.

Une idée tout de même ?

Merci d’avance,

Hervé
formatec

Septembre 2017

Bonjour Arno, J’ai testé ce plugin, tout allait bien jusqu’à ce que je vide le cache. Et là, bizarrement les logos d’article n’apparaissent plus lorsque j’ajoute le filtre |responsive alors que les documents apparaissent correctement dans le texte.

Voici un lien : http://pol-detienne.be/arctic-tern et voici la boucle

<BOUCLE_article(ARTICLES){id_article}> <h2 class="#EDIT{titre}">#TITRE</h2> <h5 class="#EDIT{soustitre}"><i>#SOUSTITRE</i></h5> #LOGO_ARTICLE_NORMAL [(#LOGO_ARTICLE_NORMAL|image_responsive)] [<div class="#EDIT{texte} texte">(#TEXTE||image_responsive)</div>] </BOUCLE_article>

as tu déjà rencontré ce genre de problème ?
formatec

Septembre 2017

J’ai trouvé, ce n’est pas la vidange du cache qui a déclenché cette erreur. C’est la réécriture en url propre. Y a t il une manip’ à faire pour pouvoir utiliser url propre et pourquoi l’erreur se produit sur les logos et pas sur le corps du texte ?
Julien

Octobre 2017

Super plugin ! Merci. Une évolution qui serait intéressante, ce serait de pouvoir aussi indiquer des sources d’images différentes selon la résolution. Je suis de plus en plus amené a faire des compositions d’images(recadrage) pour les versions mobile.
jeanmarie

Novembre 2017

Salut,

j’ai tenté un message sur spip-zone il y a quelques temps, mais sans succès. Je tente ici...

J’utilise Filtre image_responsive et, malgré l’utilisation de la méthode convert pour générer les images (dans / ?exec=configurer_avancees), il semble que le plugin utilise la méthode GD ou du moins la limite _IMG_GD_MAX_PIXELS. Cf : https://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive/image_responsive_options.php#L88

Du coup, pour les grandes images (env 4300x2900px), les vignettes ne sont pas générées par le |image_responsive alors qu’elles le sont par |balise_img.

Ça veut dire que image_responsive utilise GD même si la config de SPIP est en convert ? Si oui, il y a une variable permettant de changer ça ?

Merci.
ARNO*

Décembre 2017

@jeanmarie,

Le plugin utilise une fonction spécifique pour les réductions : image_reduire_net (parce que je veux réduire les images en renforçant la netteté, ce qui évite l’effet de léger « flou » (ou mollesse) quand on réduit beaucoup la taille d’une image.

Et du coup, oui, c’est uniquement avec GD.
jeanmarie

Décembre 2017

Salut ARNO*,

merci pour ton retour.

Et j’imagine que l’idée n’est pas de proposer des méthodes alternatives à GD (type convert qui est plus efficace sur des hébergements mutu). Bon, je tente hein :)
Mikha

Janvier 2018

Bonjour, et merci pour ce super plug-ins. Je viens de devenir "fou" un moment pour pas grand chose, et donc j’ai une proposition de correction de bug : dans SPIP les images peuvent être des fichiers locaux ou des URL. Dans le cas des URL, le plug-in ne fonctionne pas (aucune image ne sort) au moins dans le cas "background" à cause du file_exists.

Voila. Merci encore ! Mikhaël
cilou

Juin 2018

Bonjour

Ayant des problèmes de cache en testant mon site (sur WebPagetest) qui utilise le plugin (7.5.6), j’ai du modifier la page : image_responsive_options.php —> header("Cache-Control : maxage=".$expires) ; j’ai modifié maxage en max-age et tout fonctionne normalement maintenant.
Dom

Septembre 2018

Salut Arno, Tout d’abord merci pour ce super boulot. Par contre depuis ta dernière révision du plugin dans le fichier image_responsive_options.php (111517) mes sites n’affichent plus les images si elles sont plus petites que la zone à afficher... Je reviens à la version précédente et tout refonctionne... As tu une piste ? Merci d’avance pour ta réponse

https://zone.spip.org/trac/spip-zone/changeset?old_path=%2Fspip-zone%2F_plugins_%2Fimage_responsive%2Fimage_responsive_options.php&old=111517&new_path=%2Fspip-zone%2F_plugins_%2Fimage_responsive%2Fimage_responsive_options.php&new=111516
Aurel

Octobre 2018

Salut Arno, j’ai le même problème que Dom... depuis la dernière mise à jour : https://zone.spip.org/trac/spip-zone/changeset?old_path=%2Fspip-zone%2F_plugins_%2Fimage_responsive%2Fimage_responsive_options.php&old=111517&new_path=%2Fspip-zone%2F_plugins_%2Fimage_responsive%2Fimage_responsive_options.php&new=111516

Une idéee sur comment résoudre le souci ?
jeanmarie

Décembre 2018

Même problème pour moi... En annulant les modifs, ça refonctionne. Je commite en attendant de trouver une solution ?
ARNO*

Décembre 2018

OK, j’ai vérifié, et le bug était systématique quand l’image était exactement de la taille de la réduction demandée. Merci pour le signalement !
jeanmarie

Décembre 2018

Merci pour la modif...
rjadot

Février 2019

Bonjour,

suite à un redémarrage de mon serveur, j’ai une partie des images « resp » qui ne s’affichent pas, parce qu’elles n’existent pas. Je suppose que les images recalculées ont du être effacées. Y a-t-il un moyen de forcer la recréation de toutes les images ? Ou alors il me manque un paramètre ou un dosssier ?

Raphaël
jeanmarie

Mars 2019

Salut Arno,

il semble que [(#TEXTE|image_responsive)] ne fonctionne pas chez moi, ni [(#TEXTE|image_responsive{360/500/800})] : les images insérées dans le texte ne sont pas redimensionnées à 800px (pour le 2nd cas) mais systématiquement à 1200px (je ne trouve pas d’où vient cette valeur).

Je n’avais pas vraiment fait attention, mais ce n’est pas être pas un usage prévu par le plugin ?

jeanmarie
ARNO*

Juin 2019

La fonction |image_responsive ne s’applique pas au texte, mais à des images (#FICHIER, #LOGO_ARTICLE…).
Eric

Juin 2019

Salut Arno,

Mon site web est sous SPIP 3.2.4 et Image responsive 7.6.1, le plugin s’installe et J’ai aussi modifié le fichier .htaccess de mon serveur en y ajoutant les lignes livrées avec le plugin mais les images ne s’affiche pas (img src="../../monimage-resp320.jpg..."image n’existe pas") et aucun dossier "/local/cache-responsive/" ne s’est créé.

Une idée s’il vous plaît ?

Merci ! Eric
stéphane de spipfactory

Septembre 2019

Bonjour, J’ai installé le plugin sur une mutualisation spip 3.2.5, l’installation c’est bien passé et j’ai presque 100% de résultat.

(je ne l’utilisé pas auparavant)

article de démo

toutefois je n’arrive pas a comprendre pourquoi lorsqu’on souhaite paramétrer la largeur comme préconisé : <img|largeur=xx>

l’image ne s’affiche pas

Une piste, une idée, un tuto ; je vous remercie par avance toutefois je n’arrive pas a comprendre pourquoi lorsqu’on souhaite paramétrer la largeur comme préconisé : img|largeur=xx

l’image ne s’affiche pas

Une piste, une idée, un tuto ; je vous remercie par avance
Jacques

Octobre 2019

Bonjour, je viens de mettre à jour le plugin en version 7.7.9 et j’obtiens, sur l’ensemble de mes images, le warning suivant :

"Warning : preg_match() : Delimiter must not be alphanumeric or backslash in /htdocs/plugins/auto/image_responsive/v7.7.9/image_responsive_fonctions.php on line XXX "

pourriez-vous m’orienter vers une solution à ce problème ?

Bien cordialement, Jacques
Jacques

Octobre 2019

Bonsoir,

en complément d’information, ce problème semble venir de la compatibilité avec le plugin "Insertion avancée d’images 1.11.2" , suite à la mise à jour du plugin "image responsive"

Cordialement, Jacques
Jacques

Octobre 2019

Re bonsoir,

j’ai pour ma part mis en commentaires les lignes 105 et 106 du fichier " image_responsive_fonctions.php " portant sur " $mime " et je n’ai plus d"erreur,

j’espère que cela ne porte pas préjudice à d’autres fonctions du script,

Bien cordialement, Jacques

... et merci pour ce super plugin !
ARNO*

Octobre 2019

Oups, désolé, je viens d’uploader à l’instant une correction.

La détection du MIME est nécessaire pour le réinjecter dans le code HTML, essentiellement si on active la création automatique de la version WebP des images : c’est en effet l’indication du MIME qui permet au navigateur d’afficher le format le plus adapté.

Mais avec la version précédente du plugin, je suis tombé sur un serveur qui n’acceptait pas la fonction php mime_content_type(), j’ai donc bidouillé rapidement un correctif, en introduisant du coup un autre bug…
jeanmarie

Octobre 2019

Salut,

je continue à tester sur SPIP 3.3 et sa nouvelle gestion des images/logos et il y a un changement de comportement de #LOGO_ARTICLE et #LOGO_RUBRIQUE.

Jusqu’en 3.2, #LOGO_ARTICLE insère directement le logo de l’article. A partir de 3.3, ça inclut plugins-dist/medias/modeles/logo.html qui insère le logo.

Conséquence : [(#LOGO_RUBRIQUE|image_responsive{200})] ne fonctionne plus. Pour résoudre le problème, j’utilise un filtre intermédiaire qui ne fait rien mais qui ne passe par l’inclure : [(#LOGO_RUBRIQUE|image_reduire_par{1}|image_responsive{200})]

Je ne sais pas si c’est du côté de medias ou de image_responsive que ça se joue.
jeanmarie

Octobre 2019

Pour info, j’ai précisé le souci avec #LOGO_ARTICLE et #LOGO_RUBRIQUE et posté sur spip-dev : https://www.mail-archive.com/spip-dev@rezo.net/msg67557.html
jeanmarie

Décembre 2019

Suite (à l’approche de la bêta 3.3) : https://www.mail-archive.com/spip-dev@rezo.net/msg67692.html

Les filtres du core |image_recadre et |image_reduire focntionnent, donc à voir du côté de la fonction |image_responsive ce qui coince.
Sam

Janvier 2020

Bonjour,

J’ai trouvé un problème. Si on fait

[(#LOGO_ARTICLE|#URL_ARTICLE|image_reduire_net{200})]

ca génère un code html invalide :

<a href="spip.php?article1" /><i mg class='spip_logo spip_logos' alt="" src="local/cache-vignettes/L200xH113/arton1-60ebc.jpg?1580120090" width='200' height='113' /></a/>

On notera les / à la fin des balises <a et </a (j’ai mis un espace entre i et mg pour pouvoir poster). La fonction image_reduire_net et d’autres (dans image_responsive_options.php ) appelle _image_ecrire_tag avec tag contenant la balise <i mg> mais aussi le <a>. Comme _image_ecrire_tag (dans filtres_images_lib_mini.php) commence par faire un

// fermer les tags img pas bien fermes; $tag = str_replace(">", "/>", str_replace("/>", ">", $valeurs['tag']));

Ca ajoute des / à la fin du <a et du </a

Solution de contournement 1)

<a href="#URL_ARTICLE">[(#LOGO_ARTICLE|image_reduire_net{200})]</a>

Solution de contournement 2)

Que le module prenne en compte (comme image_reduire) la possibilité que le <i mg> soit entre 2 <a>
rjadot

Février 2020

Bonjour,

Où faut il mettre « code>define("_IMAGE_RESPONSIVE_CALCULER", true) ; ? Si je le mets dans mes_options.php, alors j’ai une grosse incompatibilité avec le plugin « Insertion avancée d’image », y compris dans l’interface privée : tout article avec une balise img voit la moitié de ses informations disparaître. Voici à titre d’exemple ce que ça donne dans l’interface privée. Dans l’affichage publique, il manque quasiment tout le contenu. Pas de problèmes pour les autres articles sans balise img cependant.

J’ai testé en désactivant tous les plugins, et commenté au cas où la partie avec xmod_sendfile.c dans htaccess.

Si besoin : Spip v3.1.7, Image responsive 7.8.3, Insertion avancée d’images 1.11.4, PHP 7.1.33, Apache 2.4.41
Sam

Février 2020

Bonjour, J’ai trouvé un 2e problème

Si j’utilise :

(#LOGO_ARTICLE |image_recadre{17:20, -, focus} |image_niveaux_gris_auto |inserer_attribut{class,imghoverfx} |image_responsive{10/500/665,1,0,(max-width:575px)/(min-width:576px) and (max-width: 991px)/} )

l’image n’est pas générée ni affichée. Le ratio d’image de 17:20 en fait une image verticale plutôt qu’horizontale. Aucun problème avec les images horizontales ou carrées. Mais avec les images verticales, j’ai du utiliser : image_responsive{10/500/665,1,1 Or, bien que ce soit une image verticale, je souhaite qu’elle utilise l’intégralité de la largeur du contenu dans lequel elle est et non la hauteur.
jeanmarie

Avril 2020

Salut,

depuis la version 7.7.0 (voir le commit), l’écriture [(#FICHIER|image_responsive{250/500})] n’affiche plus l’image en haute def sur les écrans HD type Retina. Par contre, [(#FICHIER|image_responsive{500})] fonctionne bien (image normale sur écran normal / image x2 sur écran HD).

Voir les code html générés dans les 2 cas : http://spip.pastebin.fr/61793 la seule différence visible est la présence d’un timestamp à partir de la V7.7.0

Une piste ?
julien

Mai 2020

Bonjour, J’utilise le plugin en mode webP en sortie. Tout marche bien, mais est-ce que vous allez ouvrir ce mode à Edge, et à tous les navigateurs maintenant compatibles ? Merci encore pour ce travail, Julien
ARNO*

Mai 2020

Julien, le critère est justement le fait que le navigateur accepte le format WebP. Quand c’est le cas, ça fonctionne. Edge fonctionne donc désormais avec WebP directement, sans modification du plugin.
julien

Mai 2020

Ha ok, bien noté C’est que dans Edge, avec ma page de test, si "j’enregistre l’image sous", il me proposait d’enregistrer un png ou un jpg, d’où ma question... Il doit se baser sur le premier point et non le .webp, ou un truc du genre. Bravo pour la réactivité ! J’en profite : le plugin sera-t-il adapté à SPIP 3.3 ? (j’ai vu une remarque sur ce sujet ci-dessus).
ARNO*

Mai 2020

Chez moi (Mac), quand je fais « Afficher cette image », j’ai bien du WebP. Mais quand je demande à sauvegarder, c’est plus malin, il me propose de sauvegarder au format JPEG (mais visiblement c’est à partir du fichier WebP), donc de faire la conversion avant de sauvegarder (je peux choisir sinon le fichier WebP, mais c’est pas la proposition par défaut). C’est malin, parce que WebP est notoirement difficile à réutiliser sur un ordinateur (pas de logiciels de traitement d’images capable de jouer avec).
julien

Mai 2020

Désolé, encore une question ! J’ai ajouté "Insertion avancé d’image" pour avoir le mécanisme d’image responsive dans les doc> et img>.

Mais dans cette page : https://i187hachmt.preview.infomaniak.website/L-Etat-a-depense-un-million-d-euros-contre-les-antinucleaires-de-Bure?var_mode=recalcul

• le webP n’a pas l’air de fonctionner, j’obtiens un .jpg en responsive, avec un type JPG dans information image, aussi bien sur le LOGO_ARTICLE que sur les doc...

Alors que dans la page de test, les LOGO_ARTICLE sont bien en WebP...https://i187hachmt.preview.infomaniak.website/spip.php?page=test

• pour régler les tailles possibles, on doit modifier les modèles doc.html et img.html ? Pas de config sinon ?

Y a un truc que j’ai loupé...

Julien
ARNO*

Mai 2020

Moi si, je vois bien des WebP dans le corps de l’article.

Et les tailles possibles sont effectivement en dur dans img.html. A priori, il ne faut plus utiliser doc.html, que je ne maintiens pas. Toutes les possibilités de maquette sont dans img.html.
julien

Mai 2020

Même sous Firefox ? (je viens de vérifier sous Chrome, c’est bon). Mais Firefox m’indique du JPG... Ou bien un problème de cache chez moi... étrange.
ARNO*

Mai 2020

Non, pas Firefox, c’est dans le script image_responsive.js.

Idéalement avec ce plugin, on définit les dimensions et des media queries, et du coup ça va fabriquer directement un code HTML super-optimisé. Malheureusement, pour les images dans les articles, je ne peux pas et je me contente de définir des tailles autorisées. Et du coup il y a un javascript maison pour faire le choix des bons fichiers.

Et concernant WebP, il y a la fonction _image_responsive_test_webp_reel qui tente de déterminer, en javascript, si le client est capable d’interpréter WebP. En fabriquant un Canvas et en regardant si on peut y installer une image WebP. Fonction qui ne fonctionne pas avec Firefox.

Donc tant pis, je n’ai pas trouvé d’autre méthode pour l’instant.
julien

Mai 2020

ok je comprends mieux. Mais pourquoi cela fonctionne dans ma page de test ? Sous firefox, [(#LOGO_ARTICLE|image_responsive780)] donne bien un webP, alors que dans la page article, cela ne marche pas... Est-ce que des #INCLURE casse le truc en JS ?
ARNO*

Mai 2020

Parce que quand tu indiques une seule dimension, le plugin fabrique directement le code HTML qui se suffit à lui-même, sans avoir besoin de Javascript. C’est également le cas quand tu indiques plusieurs dimensions, mais dont tu fixes l’utilisation par des media queries. Quand c’est bien fait, tu parviens à fabriquer des maquettes extrêmement responsives, avec des images qui s’adaptent à des quantités de situations, et qui fonctionnent même avec Javascript désactivé (avantage du coup : ça se preload très bien).
ARNO*

Mai 2020

Pour expliquer pourquoi je ne pré-configure pas les conditions d’utilisation des différentes dimensions des <img> : mon utilisation des images responsive se fait quasiment systématiquement avec des maquettes laissées au choix du webmestre, avec une colonne, deux, trois, quatre, de différentes dimensions. Donc je n’ai aucun moyen, au moment de l’affichage de <img>, de connaître la largeur d’affichage.

Pour cela il faudrait des media queries basées sur la taille de la colonne de texte, ce qui n’existe pas.
Mai 2020

Merci Arno pour toutes ces précisions. Je vais tenter une détection du navigateur genre https://www.hugochaume.com/blog/integration-web/javascript-detection-du-navigateur/ dans _image_responsive_test_webp_reel pour avoir des webP dans firefox.

Et encore merci pour tout ce travail.
Graphie

Juin 2020

Bonjour Arno,

Merci pour cet outil très bien pensé et très pointu !!

J’essaie de remplacer une construction d’image qui redimensionne selon la plus grande dimension H/V : [(#LOGO_ARTICLE_NORMAL|image_reduire{600,600})].

Mais je n’arrive pas à trouver une correspondance de « fonctionnalité » équivalente avec image responsive : [(#LOGO_ARTICLE_NORMAL|image_responsive{600})], ne tient compte que de la place disponible en H. J’ai bien noté qu’il y a un paramètre pour forcer le calcul de la place libre en vertical, mais dans mon cas, je ne sais pas quand l’image sera H ou V.

J’ai bien évidement utilisé un bloc englobant qui style max-width et max-height à 600px.

As-tu été confronté à cette question ?

Bien cordialement, françois
Julien

Juin 2020

Encore une question ! Je viens de mettre en production le plugin sur reporterre.net, mais les images affichées sont celles avec un -2 dans le nom, donc pour des écrans rétinas si je comprends bien( je suis sous PC avec Firefox ou Chrome).

Tout se passait pourtant bien sur le site de dév...

Voici par exemple pour une taille unique de 450 pixels :

img class="image_responsive lazy" alt="" src="local/cache-gd2/c9/16d9fb81c90b913edb78ed35ad4008-resp450-2.jpg.webp" data-src="local/cache-gd2/c9/16d9fb81c90b913edb78ed35ad4008.jpg" data-l="1200" data-h="750" data-tailles="[\"450\"]" data-src-lazy="local/cache-gd2/c9/16d9fb81c90b913edb78ed35ad4008-resp450.jpg ?1592377136"

Serait-ce un problème dans le htaccess ? Une autre idée ? Merci de votre aide, Julien
olivier

Juillet 2020

bonjour Arno*, je me suis un peu embêté pour définir les plages pour les variantes d’images avec les media quieries. Et comme tu écris que c’est difficile à dégugger, je me permet de poser cette question : Est-ce que la syntaxe autorise de mettre des expressions de test imbriquées, comme celle-ci : image_responsive0/576/720/980, 0, 0, (max-width : 576px) or ((min-width:981px) and (max-width:1440px)) / ((min-width:577px) and (max-width : 720px)) or ((min-width:1441px) and (max-width:1800px)) / (min-width:1801px) or ((min-width:721px) and (max-width:980px))
ARNO*

Juillet 2020

Olivier, à ma connaissance il n’y a pas de « OR » dans les media queries, donc ça ne devrait pas fonctionner. Dans les medias queries, normalement, le « OR » c’est la virgule. Que tu ne peux pas utiliser ici, puisque la virgule sert de séparateur des variables de la fonction.

En revanche, tu peux tout à fait utiliser plusieurs fois la même largeur dans la première partie (là où tu as mis 0/576/720/980). Et donc avoir des plages différentes pour deux fois la même valeur.

C’est par exemple ce que je fais sur un site, où je recadrer différemment selon la taille, et aussi selon l’orientation :
[<span class="fond_logo" id="logo#ID_ARTICLE"><span class="logo">(#LOGO_ARTICLE_NORMAL|image_responsive{ 0/480/800/1280/1920/480/800/1280/1920, 0, 0, (max-width: 480px) and (orientation:portrait)/(min-width:481px) and (max-width: 800px) and (orientation:portrait)/(min-width:801px) and (max-width:1280px) and (orientation:portrait)/(min-width:1281px) and (orientation:portrait)/ (max-width: 480px)/(min-width:481px) and (max-width: 800px)/(min-width:801px) and (max-width:1280px)/, 2x2.2xfocus/2x2xfocus/3x2xfocus/3x2xfocus/10x5xfocus/10x5xfocus/10x4xfocus/10x4xfocus })</span></span>]
olivier

Juillet 2020

merci. Effectivement, on peut mettre plusieurs fois la même valeur dans le premier paramètre. Cela fonctionne : image_responsive{0/576/720/980/576/720/980, 0, 0, (max-width : 576px) / (min-width:577px) and (max-width : 720px) / (min-width:721px) and (max-width:980px) / (min-width:981px) and (max-width:1440px) / (min-width:1441px) and (max-width:1800px) / (min-width:1801px)}
olivier

Juillet 2020

Cela ne me parait pas voulu que le padding-bottom ne permette pas à la picture de remplir totalement la div, n’est-ce pas ? (7px d’ecart environ selon safari, chrome ou firefox, à différentes tailles de fenêtre - visible Sur la page d’accueil de https://www.grottesdhaiti.org ).
ARNO*

Juillet 2020

Ce n’est pas le padding-bottom qui provoque l’espacement, c’est le display:inline-block. Il faut que tu fasses un style qui va attaquer ces <picture pour forcer display: block;
Pierre-Edouard

Octobre 2020

Bonjour, Tout d’abord merci pour le travail effectué !

J’ai un problème à l’utilisation du plugin pour l’affichage des images. Quand j’inspecte mes images j’ai bien du code de généré : <picture style="padding:0;padding-bottom:44.823906083244%" class="conteneur_image_responsive_h"><img class="image_responsive" alt="" src="local/cache-responsive/cache-120/d5e829348fe934e567b96822971935cc.jpg" data-src="IMG/arton1.jpg" data-l="1874" data-h="840" data-tailles="[\"\"]"></picture>

mais aucune image n’est affichée. De plus, dans les dossiers caches d’image-responsive je n’ai aucune image.

Si quelqu’un a une piste, je suis preneur. Merci d’avance
Román

Novembre 2020

Hey Arno ! First of all : thanx a lot for this great plug-in ! It’s of great help for all of us who work with Spip !

Just wanted to let you know that I use it with effective results extracting the IMG balise from any part of the article. Here’s the code for using it with the image included in the Chapo section of the article :

[(#CHAPO|extraire_baliseimg|extraire_attributsrc|image_responsive)]

Thanx again for the plug-in. And excuse me for writing in English but my French is really bad ! ja !

Cheers from Argentina !
Grep

Juin 2021

Bonjour, La version 9.10 du plugin sous spip 4.0 beta ne semble pas fonctionner avec php 8.0.5 (ma distribution ne supporte que cette version). L’erreur suivante est renvoyée : Erreur d’exécution plugins/auto/medias_responsive_mod/v1.22.0/squelettes/modeles/image.html | File […]/plugins/auto/image_responsive/v9.1.0/image_responsive_fonctions.php Line 481 : Call to undefined function create_function()

le site de php indique : La fonctionnalité est obsolète à partir de PHP 7.2.0 et a été supprimée à partir de PHP 8.0.0

Y a t il un moyen de contourner cette erreur ?

Merci
ARNO*

Juin 2021

Bonjour Grep, merci pour le signalement. Je viens de poster une version 9.2.0 qui remplace l’appel à cette fonction obsolète.
Grep

Juin 2021

Merci ! Les alertes ont disparu, et le plugin est pleinement fonctionnel.
Grep

Juin 2021

Bonjour, Suite à la mise à jour spip 4.0 Beta, j’obtiens cette erreur : Erreur d’exécution squelettes/sommaire.html | File […]/plugins/auto/image_responsive/v9.3.0/image_responsive_fonctions.php Line 412 : join() : Argument #2 ($array) must be of type ?array, string given

en spip 4.0 alpha et image_responsive v9.3.0, pas de probleme
ARNO*

Juin 2021

@Grep : est-ce que tu peux identifier quel est la partie de ton squelette qui déclenche cette erreur ?
Grep

Juin 2021

Ce doit être : [(#LOGO_ARTICLE|image_responsive|image_reduire1200,400,’center center’,’transparent’|sinon#FICHIER|image_responsive|image_recadre1200,400,’center center’,’transparent’|inserer_attribut’alt’,vignette_accueil)]

ou

[(#LOGO_ARTICLE|image_responsive|image_reduire320,250,’center center’,’transparent’|sinon#FICHIER|image_responsive|image_recadre320,250,’center center’,’transparent’|inserer_attribut’alt’,vignette_accueil)]
Grep

Juin 2021

image_responsive_fonctions.php Ligne 412 : //$srcset = join($srcset, ",") ; $srcset = join(",",$srcset) ;

Version Description 8.0.0 Passer le separator après array n’est plus supporté. 7.4.0 Passer separator après les array (i.e. utilisant la signature antérieure) a été rendu obsolète.

mais avec cette modification, seul les gifs sont affichées ... php-gd2
Hervé Le Dantec

Juin 2021

Bonjour,

J’utilise le plugin image responsive depuis plusieurs années et j’en suis très heureux, mais là, je suis confronté à un problème que je n’avais pas encore rencontré :

J’ai suivi les instructions de l’article de contrib.spip.net "Passer un site SPIP sous https://« et j’ai donc ajouté au .htaccess livré avec spip

RewriteCond %{HTTPS} !=on RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Dès que j’ajoute ces réglages : aucunes images ne se charge sur le site, même le logo de spip.

Et si je supprime ces réglages les images reviennent.

Pour essayer de comprendre, j’ai suivi les étapes suivantes :

J’ai testé en désactivant le dossier "squelettes" et les images sont revenues.

Ensuite, j’ai réactivé le dossier "squelettes" et pour tester si cela ne venait pas d’image responsive, j’ai modifié le fichier inclure/header.html en testant l’affichage du logo du site selon image responsive et comme dans squelettes-dist/inclure/header.html, ce qui donne :

<h1 id="logo_madeo">[<div class="logo">(#LOGO_SITE_SPIP|image_responsive{100/200/400/800}|inserer_attribut{alt, #SLOGAN_SITE_SPIP|attribut_html})</div>]</h1> <h1 class="spip_logo_site">[(#LOGO_SITE_SPIP|image_reduire{224,96})]#NOM_SITE_SPIP</h1>

Résultat :

seul le logo spip codé avec image_réduire s’affiche.

Une idée de ce qui cause ce problème ?

Merci d’avance,

Cordialement,

Hervé
jeanmarie

Septembre 2021

(re-)salut,

il semble que le plugin pose problème avec les pictos SVG de SPIP 4 quand on insert un document dans le contenu.

Il essaye de les gérer et ça donne des url de ce type : index.php?action=image_responsive&img=plugins-dist/medias/prive/vignettes/odt.svg&taille=64&1629728164

Est-ce que exclure les SVG d’image_responsive serait une solution ?
Natacha Courcelles

Mars 2022

Bonjour

si le logo (site, rubrique, ou article) est une image svg ça plante : pas d’image juste le halt

que faut il faire pour y remédier ? merci Natacha
delaney

Mai 2022

Bonjour Arno, Merci pour ce plugin que j’utilise avec bonheur depuis des années et que je prévois d’utiliser dans un nouveau site, sauf que je me suis aperçu qu’image-responsive n’était pas compatible avec spip 4.1. Du coup, une question : y a-t-il une raison structurelle à cette incompatibilité ? Dans le cas contraire, je crois qu’il y a un fichier à modifier dans le dossier du plugin pour indiquer sa zone de compatibilité… En tous les cas ,merci !!
nicolas

Juillet 2022

Bonjour, mille mercis pour ce plugin bien pensé.

j’essaye d’appliquer le principe sur un background bootsrap. Visiblement mon approche n’est pas correcte cf code ci-dessous avez vous une idée pour que cela soit fonctionnel ?

[(#LOGO_ARTICLE|background_responsive240/480/600/960/1200/1400/1600/2000|extraire_attributsrc)]

bonne journée !
Sam

Novembre 2022

Hello, j’ai installé la version la plus récente du plugin, et cela me génère ce message d’erreur (qui n’existait pas sur la version 7.8.4 précédemment installée Erreur d’exécution squelettes/sommaire.html | File […]/plugins/auto/image_responsive/v9.7.2/image_responsive_fonctions.php Line 669 : Call to undefined function image_reduire() Une idée de l’origine du problème et de la manière de le règler ?
ARNO*

Novembre 2022

Bizarre : il n’y aurait pas eu une mise à jour de SPIP aussi ?

En tout cas je viens d’uploader une version 9.7.3, qui devrait corriger ça.
Sam

Novembre 2022

Hello, Merci pour la réponse et le correctif ! Il y a effectivement eu une mise à jour spip La version 9.7.3 ne renvoit plus le message d’erreur constatée. Par contre, les images ne s’affichent plus. Est-ce qu’il y a une modification à apporter dans la syntaxe pour appeler les fonctions images_responsive et background_responsive ? Je l’utilise notamment dans une boucle carousel.
superyms

Novembre 2022

bonjour,

depuis la mise à jour du plugin en 9.7.3 le site ’affiche plus les logo des articles dans les articles spécifiques. des miniatures du logo sont bien affichées mais pas le logo une fois sur la page de l’article... alors que ce comportement n’existait pas avant !

je suis sous spip 3.2.16
superyms

Novembre 2022

en fait, le plugin n’arrive plus à créer l’image dans le cache, donc le lien est généré mais pas les images !

exemple ce lien est bien généré dans le squelette de l’article

local/cache-gd2/9f/2c3e252efb239b512d4423aeee3199-resp1000.jpg ?1668632187

mais ce fichier est absent dans le cache hélas donc rien n’est affiché !

est-ce qu’il faut réécrire mes squelettes ou y a t’il un bug ?
superyms

Novembre 2022

au passage, j’ai vider le cache, j’ai désinstaller et réinstaller le plugin (y compris la version 9.6.0) ais rien n’y fait, j’ai le même comportement bizarre !

je confirme aucune image responsive n’est générée... dans l’onglet vider le cache (ecrire/index.php ?exec=admin_vider), dans Images pour responsive, y a aucune image générée (rien à supprimer !)

merci de voir car ça bousille tout le site ! MERCI.
superyms

Novembre 2022

je ne sais pas pourquoi mais tout refonctionne après que j’ai ajouté ces 3 lignes de code dans mes-options.php

// pré-calculer les images pour toutes les tailles define("_IMAGE_RESPONSIVE_CALCULER", true) ; // WebP ok ! define("_IMAGE_WEBP", true) ; // Fixer transparence png et webp define("_IMAGE_CORRIGER_BRUIT_TRANSPARENT", true) ;

après avoir tester, c’est l’option de pré-calcul qui solutionne le problème, donc je suis obligé de le maintenir !

en espérant que cela donne des pistes intéressantes pour une solution plus stable !
ARNO*

Novembre 2022

_IMAGE_RESPONSIVE_CALCULER fait que les images sont calculées une fois pour toutes au moment du premier calcul de la page, puis stockées en cache. C’est le mode à privilégier, puisqu’alors les images intégrées aux pages sont directement les fichiers JPEG, et non un script PHP qui ensuite va chercher le fichier JPG, ça allège donc considérablement le travail du serveur (et sans doute la vitesse de la réponse). Donc dans tous les cas, c’est à privilégier absolument.

_IMAGE_WEBP fait qu’on fabrique aussi une version WebP (et plus seulement JPEG). C’est également conseillé, puisque WebP est plus efficace (fichiers plus légers à qualité d’image équivalente).

En revanche ça n’explique pas pourquoi, en mode « non précaculé » ça refuse de fonctionner. Souvent, de ce côté, c’est un problème avec le .htaccess, que l’on doit avoir modifié avec l’extrait fourni avec le plugin. Par exemple, si tu repasses les URL de ton site en mode « URLs Simples » (de la forme spip.php?page=article&id_article=12), alors le plugin n’utilisera pas non plus les redirections d’image de .htaccess : est-ce que ça résoud aussi le souci (si oui, c’est que le problème vient du .htaccess).
Thomas Clément

Novembre 2022

Je rencontre un problème d’affichage lorsque le fichier original est lui-même au format webp. Voici le code source de la balise picture :

<picture style="padding:0;padding-bottom:176.5%" class="conteneur_image_responsive_h">  <source srcset="plugins/auto/image_responsive/v9.7.3/rien.gif 1x,plugins/auto/image_responsive/v9.7.3/rien.gif 2x" type="image/webp"> <source srcset="plugins/auto/image_responsive/v9.7.3/rien.gif 1x,plugins/auto/image_responsive/v9.7.3/rien.gif 2x" type="image/webp">  <img src="plugins/auto/image_responsive/v9.7.3/rien.gif?1667592678" class="image_responsive avec_picturefill" alt="Fats Navarro par Sylvain Leheu - Couverture" data-src="IMG/logo/fats-navarro.webp" data-l="400" data-h="706" data-tailles="[\"118\"]"></picture>

Le fichier d’origine est bien IMG/logo/fats-navarro.webp comme indiqué dans le data-src, mais les src-set ne contiennent que rien.gif.
Loiseau2nuit

Décembre 2022

Hello ici !
Natacha

Mai 2023

Bonjour comment utiliser image_responsive sur la balise #FICHIER dans une boucle document ?

merci pour votre aide Natacha
ARNO*

Mai 2023

@Natacha : dans les exemples donnés dans l’article, il suffit de remplace #LOGO_ARTICLE_NORMAL par #FICHIER, et le fonctionnement sera rigoureusement identifique.

Par exemple :
[(#FICHIER|image_responsive{300/600/900/1200})]
Natacha

Mai 2023

Merci Arno c’est de ma faute, je transforme du vieux code mon erreur est corrigé Natacha
Tederic Merger

Août 2023

Bonjour, J’ai eu un problème quand j’ai voulu monter à la dernière version du plugin compatible avec SPIP 3.2.19 : L’image ne s’affichait plus (mais l’espace était bien réservé sur la page) dans un cas très particulier : quand la fiche document était dans une base SPIP distante (chez le même hébergeur, accédée par connect ; le fichier image étant, lui, sur une branche différente du même serveur FTP) Pour mieux expliquer la situation : Il y a un site SPIP à la racine et un autre site SPIP sur une des branches de l’arborescence FTP ; chaque site SPIP a sa propre base de données MySQL, mais peut se connecter à l’autre base. En revenant à la version 9.4.2, ça marchait à nouveau ! Bon, j’ai peu d’espoir que ce cas particulier parle à quelqu’un, mais je tente le coup ! Bon courage à tou(te)s !
Teenoo

il y a 2 mois

Bonjour,

je rencontre une problématique dont vous aurez sans doute la solution. Dans l’optique de trier au mieux mes images dans des flexbox, je réalise un tri #SET de cette manière

#SET{photos,#ARRAY} <BOUCLE(DOCUMENTS){id_article}{par rang_lien, num titre}{paysage}{doublons}{par rang_lien, num titre, titre}{vu=non}> #SET{photo, #ARRAY{ image, #FICHIER, type,paysage, titre,#TITRE }} [(#SET_PUSH{photos,#GET{photo}})] </BOUCLE> <BOUCLE(DOCUMENTS){id_article}{par rang_lien, num titre}{portrait}{doublons}{par rang_lien, num titre, titre}{vu=non}> #SET{photo, #ARRAY{ image, #FICHIER, type,portrait, titre,#TITRE }} [(#SET_PUSH{photos,#GET{photo}})] </BOUCLE>

Puis j’affiche de cette manière

<BOUCLE(DATA){source table,#GET{photos}}{par rang_lien, num titre, titre}> [(#VALEUR{image}|image_responsive{480/640/960})] </BOUCLE>

Ça génère des problèmes d’affichage. Sur une page j’ai un blocage au milieu d’un scroll, sur une autre juste une seule image affichée... Qu’est-ce qui est mauvais dans ce code ?

En vous remerciant
Teenoo

il y a 2 mois

J’oubliais, il y a génération systématique d’un padding-bottom de 66% ou 150% comment cela se fait-il ?

Adresse du site pour exemple : Le site
ARNO*

il y a 2 mois

Bonjour Teenoo,

J’ai plutôt l’impression que le souci vient du Javascript de votre page, sans doute dans Masonry. Si je désactive Javascript dans mon navigateur, la page s’affiche parfaitement, toutes les images sont bien là.

Sinon le padding-bottom est calculé en fonction des proportions de chaque image. C’est ce qui permet d’avoir un affichage responsive sur des images qu’on n’a pas encore chargées.

Installation

La fonction image_responsive

Maquetter via les CSS

Emplacement de l’image pré-réservé

Première subtilité : des images réduites plus nettes

Deuxième subtilité : des images haute définition de poids raisonnable

Troisième subtilité : une fonction pour recadrer une image sans la réduire

Retour à image_responsive : fixer des tailles autorisées

Effet de bord induit : on fait travailler PHP sur chaque image

Contrôler le cache du plugin

Avec ou sous sans vignette au chargement de la page

Charger uniquement les images visibles : mode lazyload

Alignement vertical

Le balisage responsive directement en HTML5

Image adaptative, recadrage et direction artistique

Précalculer les images

Créer des liens vers les fichiers d’images

Et pour des images en background ?

Format WebP

Correction du bruit dans la transparence

La fonction `image_responsive`

Retour à `image_responsive` : fixer des tailles autorisées