En local (XAMPP de base) tout roule comme sur des roulettes, les versions de PHP sont identiques et a priori j’ai bien toutes les bonnes libs sur la prod (GD & co.).

J’ai mis l'hébergeur sur le coup (coucou @alwaysdata ❤️) qui semble dire que le processus réclamerait trop de RAM et s’arrêterait en route, et m'a conseillé d’uploader directement les images que j’ai en local dans /media… mais ça ne fonctionne toujours pas.

Mastodev, fais ta magie ? 🙃

(2/2)

@STPo @pixenjoy si je comprends bien ton hébergeur dit que ça peut prendre beaucoup de ram. Est-ce que tu as accès à des logs d'erreur ?
Si c'est en effet cela le problème tu devrais avoir une erreur du genre "Fatal error: Allowed memory size of x bytes exhausted"

Si tu as accès la config PHP/Apache tu peux essayer d'augmenter la limite "memory_limit". Poser un phpinfo() en local et en ligne pour voir si ce paramètre est le même sur les deux pourrait aider

@Julianoe @pixenjoy Merci pour tout ça, j’avais déjà testé pour memory_limit, j’ai forcé à 512 mais ça ne change rien…

J'ai bien accès aux logs mais je n'y comprends pas grand-chose… En gros il y a du timeout et du brun sur « mod_fcgid », et aussi du « fatal Error Unable to create lock file: Disk quota exceeded » (peut-être ça ?).

Merci pour le lien du forum, je redoutais de bricoler avec ImageMagick…

@STPo tu as vérifié avec memory_limit mais max_memory_limit est de combien ?

Mais ça ne me semble pas être ça de ce que tu me dis sinon tu aurais des erreurs en référence à cela dans les logs.

@Julianoe C’est vraiment du Kirby basique a priori :

<img src="<?= $cover->crop(1000, 750)->url() ?>" alt="<?= $cover->alt()->esc() ?>">

@STPo @pixenjoy sans pour autant savoir l'origine du bug
J'ai fait 3 tests avec ton fichier.

$backgroundImage = $layout->image()->toFile();
echo '<img srcset="'. $backgroundImage->srcset([300, 800, 1024]) .'">';
echo '<img src="'. $backgroundImage->crop(1000, 750, ['quality' => 90,'crop' => 'center'])->url() .'" alt="'. $backgroundImage->alt()->esc() .'">';
echo '<img src="'. $backgroundImage->crop(1000, 750)->url() .'" alt="'. $backgroundImage->alt()->esc() .'">';

@STPo @pixenjoy la fonction crop() est juste un raccourci pour la fonction thumb de toute manière donc ton crop est équivalent à :
echo '<img src="'. $backgroundImage->thumb(['width'=>1000, 'height'=>750, 'crop'=> 'center', 'quality'=>90])->url() .'" alt="'. $backgroundImage->alt()->esc() .'">';

NOTE : si je retire 'quality' j'ai le bug. Si je le mets, ça marche.
Essaie en précisant quality, en utilisant soit crop(), soit thumb() et ça devrait marcher

@Julianoe @pixenjoy Ah merde non ça le fait encore j’ai parlé trop vite…
https://hpaa.alwaysdata.net/projets

Bon maintenant elles s’appellent …-1000x750-crop-q90.jpg 😀

Grmlb.

@STPo @pixenjoy Avec la mémoire à laquelle tu disais avoir accès sur le serveur je suis très circonspect.
J'ai checké sur l'un de mes sites Kirby créé récemment (donc Kirby 4-5, PHP8.4+) j'ai carrément dit au client de balancer ses .jpg de 25mo et l'algo les mange sans soucis pour les compresser et resize avec srcset() et thumb().

On y rerécléchissant et en regardant tous les cas où j'ai absorbé des grosses images, le problème vient de ton hébergement

@STPo @pixenjoy soit la config du serveur, soit de la mémoire, soit autre chose, mais ça n'est pas possible autrement.

Pas des milliers d'options :

- tester en utilisant imagemagick sur le serveur et kirby pour la compression (mais si c'est un problème de serveur qui choke.. peut être uqe ça ne suffira pas)

- sinon uploader des images moins grosses

- compresser les images dans le dossier /content
Perso c'est ce que je ferais. Les images sont safe en local, tu compresses un petit peu & retest