Laravel ImageTools : arrêtez de casser le cache CDN avec des images stables et pilotées par des requêtes
Chaque version est bloquée sur les images. Les CSS/JS suivent déjà les règles - noms de fichiers masqués, cache CDN de longue durée, déploiements prévisibles. Les images restent un risque manuel : quelqu'un renomme un fichier et envoie un e-mail 404, le CDN met en cache "ce qu'il peut", le S3/R2 n'est pas cohérent et les mêmes cultures se répètent dans les modèles

GitHub :isap-ou/laravel-imagetools
Pourquoi ImageTools est important
Lorsqu'une équipe demande "juste une dernière retouche" à une image de héros, le rayon d'action peut être plus grand que les pixels ne le suggèrent. Un nouveau nom de fichier se glisse dans un modèle, un e-mail est envoyé avec l'ancienne URL, les cartes Open Graph affichent le mauvais aperçu pendant des jours et le cache CDN ressemble à un jeu de pile ou face. Le front-end a résolu ce problème il y a des années avec des actifs hachés et une mise en cache immuable. Les images méritent la même prévisibilité, et c'est exactement ce qu'ImageTools apporte à Laravel.
Au lieu de créer des noms de fichiers à la main ou de s'appuyer sur un pipeline de construction que vous ne contrôlez pas entièrement, vous décrivez ce dont vous avez besoin avec une simple URL : le chemin vers la source avant le point d'interrogation, et quelques options claires après celui-ci. ImageTools transforme cette intention en un véritable fichier avec un nom déterministe (pensez à <name>--<hash>.<ext>), le stocke sur le disque de votre choix et vous renvoie une URL publique stable. Le hachage ne change que lorsque la source ou les options changent, ce qui vous permet de vous appuyer en toute confiance sur la mise en cache CDN à longue durée de vie et d'arrêter de rechercher des liens cassés après chaque publication.
Il ne s'agit pas d'une route proxy qui transforme les images à chaque requête HTTP. Il s'agit d'une génération côté serveur que vous contrôlez depuis Blade ou PHP : un coût unique la première fois qu'une variante est nécessaire, puis des réponses instantanées par la suite. Un petit manifeste PHP se souvient de la correspondance entre une requête canonisée et le chemin du fichier stocké, de sorte que le deuxième, le troisième et le millième appel sont aussi peu coûteux que la lecture d'une chaîne de caractères.
Comment cela fonctionne-t-il en pratique ?
Vous appelez ImageTools avec une source et des options. Le paquetage canonise la requête (les clés sont triées), calcule un hachage à partir de la source et des options, effectue la transformation, écrit le résultat sur votre disque de stockage et renvoie une URL publique. Comme le nom de fichier inclut le hachage, la mise en cache immuable "fonctionne" : modifiez l'image ou ses paramètres et une nouvelle URL apparaîtra automatiquement ; ne changez rien et l'URL restera valide pendant des mois.
Des options de requête que vous connaissez déjà
Utilisez un petit vocabulaire familier : w et h pour les dimensions (px), fit pour la géométrie (à partir de Spatie\Image\Enums\Fit), q pour la qualité et format pour le type de cible (jpeg, png, gif, webp, avif). Sous le capot, ImageTools utilise spatie/image-Imagick est recommandé ; GD est disponible comme solution de rechange. La canonicalisation signifie que ?h=630&w=1200 et ?w=1200&h=630 sont la même requête et produisent la même URL.
Exemples Blade et PHP
<img
src="{{ ImageTools::asset('public/images/hero.jpg?w=1200&h=630&fit=contain&format=webp&q=82') }}"
width="1200"
height="630"
alt="Hero"
/>Vous pouvez également résoudre le service à partir du conteneur en PHP. Dans tous les cas, le premier appel construit la variante et la stocke ; les appels suivants sont simplement des recherches de manifeste et des retours de chaîne. Par défaut, les fichiers atterrissent à quelque chose comme image-tools/hero--a1b2c3d4e5.webp, et le manifeste à bootstrap/cache/image-tools.php.
Stockage et CDN
ImageTools fonctionne avec n'importe quel disque Laravel - local public, Amazon S3, Cloudflare R2, et autres. Le changement de stockage est un changement de configuration, pas une réécriture de modèle. Comme les noms de fichiers sont basés sur le hachage, vous pouvez appliquer des TTL longs et des politiques de mise en cache immuables à la périphérie du CDN sans vous soucier du contenu périmé : la clé de mise en cache est intégrée au nom.
Là où il brille
Les pages marketing et les blogs conservent des images OG et des images de héros stables d'une version à l'autre. Les modèles d'e-mails ne se cassent plus car les URL ne dérivent pas avec les versions. Les piles mixtes - lame et SPA - peuvent partager le même appel côté serveur. Et les migrations entre les backends de stockage deviennent opérationnelles, et non pas développementales : passez de public à S3/R2 dans la configuration et continuez.
Comparaison : ImageTools par rapport à d'autres approches
League Glide (transformateur HTTP)
Glide expose un point final public comme /img/{path}?w=...&h=... qui transforme les images par demande, souvent avec des URL signées pour plus de sécurité. C'est très pratique lorsque vous avez besoin d'un service HTTP universel. ImageTools prend un chemin différent : il écrit un fichier physique avec un hachage dans son nom et renvoie une URL statique. Pas de route proxy, pas de travail par requête, et un ajustement naturel pour la mise en cache CDN immuable et les intégrations statiques comme les vues Blade, les emails, et les images OG.
vite-imagetools (temps de construction)
vite-imagetools transforme les actifs pendant la construction de Vite (Sharp). Si chaque image passe par des importations JS/TS, cela peut être idéal. Mais si vous effectuez un rendu avec Blade, envoyez des courriels ou souhaitez simplement un contrôle côté serveur dans Laravel, ImageTools vous offre une expérience de développement similaire - options de requête, noms de fichiers déterministes - sans lier votre flux de travail à un pipeline frontal.
Meilleures pratiques
Commencez avec WebP et évaluez AVIF sur un ensemble d'échantillons pour la taille et la fidélité visuelle - certaines photos avec des dégradés lisses nécessitent un examen plus approfondi. Gardez la génération sous le contrôle de votre application et mettez sur liste blanche les chemins d'accès valides à la source ; définissez les droits d'écriture sur le disque cible. Une fois les noms de fichiers basés sur le hachage en place, activez la mise en cache immuable et à longue durée de vie sur votre CDN et laissez le vidage de cache se faire automatiquement lorsque le contenu change vraiment.
Résolution des problèmes
- Classe introuvable : exécutez
composer dump-autoload. - Imagick/GD : installez/activez Imagick (recommandé) ou passez à GD.
- Géométrie :
fitnécessite à la foisweth; ne transmettez que des valeurs numériques. - Disque public 404 : assurez-vous que
php artisan storage:linkest configuré.
Contactez-nous
Besoin d’aide avec Statamic?
Faites-nous part de votre contexte et du résultat que vous souhaitez obtenir, et nous vous proposerons l'étape suivante la plus simple.