Comments 26
Вместо выплевывания картинок посредством Laravel, лучше глянуть в сторону nginx x-accel-redirect.
Почему бы не использовать уже готовые решения? Например https://github.com/cshum/imagor
Как вариант, при первой загрузке можно в очередь кидать задачу на ресайз, а возвращать обычное большое изображение, чтобы пользователя не заставлять ждать
Неплохая ученическая работа, но вот портить её желтушным заголовком совсем не стоило.
Или проверку наличия файла сделать в .htaccess
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^image-([0-9]+).jpg$ script.php?width=$1 [L]
а в скрипте ресайзить, сохранять и отдавать первый раз.
Это что-то страшное....
А не проще в webp призагрузке складывать картинки и потом уже в очереди их ресайзить? Тем более webp весит намного меньше
Можно взять готовое решение. Например, imgproxy
Всегда удивляет, как люди умудряются писать такую кучу плохого кода. Обычно когда спешишь и говнокодишь, то получается совсем мало кода, но с проблемами в поддержке. А здесь и кода тьма, и качество ужасное, и проблемы с безопасностью.
Вот пример с глайдом, всего пару строк, если не хочется морочиться с конфигурированием сервера https://glide.thephpleague.com/2.0/config/integrations/laravel/
Нет понятия нормальный код для X фреймворка или нет. Фигню как и качественный код можно писать практически на любом фреймворке. Минус лары скорее в том что документация особо не склоняет к написанию правильного и чистого кода.
Мой вопрос опять был составлен не совсем корректно.
Минус лары скорее в том что документация особо не склоняет к написанию правильного и чистого кода
Соглашусь.
Если вовремя поймать этот момент можно исправить кучу косяков или недопустить их.
Этот код от наших соседей из индостана.
Он плох и избыточен. + страдает проблемой безопасности... Можно не изобретать велосипед, а пользоваться готовыми решениями, которые не требуют настроек сервера.
Здесь сам Ларавел практически не используется. Поэтому этот код плох вне зависимости от фреймворка. Похоже, сюда просто запихнули какое-то древнее решение с СО.
Например, $this->renderable
при false в любом из 3 условий не вернёт ничего разумного, да?
Посмотрите на нормальный код Laravel-style ниже у @toratoda : лаконично, понятно, без велосипедов.
Просто Ларавел популярный и простой для входа, поэтому его используют все подряд.
use Illuminate\Filesystem\FilesystemAdapter;
use Illuminate\Support\Facades\Route;
use Illuminate\Support\Facades\Storage;
use Intervention\Image\Facades\Image;
Route::get('/image/{width}/{height}/{filename}', function (int $width, int $height, string $filename) {
/** @var FilesystemAdapter $disk */
$disk = Storage::disk('public');
$filename = basename($filename);
$path = "image/{$width}/{$height}/{$filename}";
if (!$disk->exists($path)) {
Image::make($disk->path("image/base/{$filename}"))
->resize($width, $height)
->save($disk->path($path));
}
return $disk->download($path);
});
можно ещё проверять является ли файл изображением, ну думаю "и так сойдёт"
https://glide.thephpleague.com/
Эта штука мгновенно генерит
Кликбейт детектед! Автор, разберитесь с понятиями сжатие и ресайз.
Просветите
Тут вам гугл с википедией лучше помогут. На хабре есть статьи https://habr.com/ru/post/454944/
Если в двух словах, то в функции imagejpeg из вашего кода есть третий параметр, который отвечает как раз за сжатие. Т.е. при одном и том же размере картинка может быть с разной степенью сжатия. Ну и использование GD в 2022, мягко говоря, выбор неоптимальный. Если вам попадутся хорошо оптимизированные картинки, вы будете удивлены, когда уменьшенная в размерах по вашему коду картинка будет весить больше оригинала.
Цитирую из статьи "В репозитории что я прилагаю - 29 картинок суммарным объёмом 20Мб. Попробуем сжать ... В дальнейшем суммарный объём этих изображений не превысит 90Кб.". На мой взгляд здесь нет никакого противоречия заголовка и содержимого. Ресайз, о котором Вы упомянули как раз и привёл к сжатию, имея ввиду снижение траффика.
Считаю, что если есть рабочее решение которое не требует под себя какой-то отдельной инфраструктуры, то оно имеет право на существование.
На счёт оптимального выбора тут можно дискутировать (чего бы мне не хотелось), т.к. слово "оптимальное решение" предполагает какие-то конкретные условия. Скажем, видел здесь в коментах красивый пример использующий методы ларавеля, но был и вариант с докер-образом, который не совместим например с виртуальным хостингом.
Напомню на всякий случай - примеры здесь написаны не для того чтобы сказать что это единственно верный способ. Задача была просто сделать достаточно шутрый механизм обработки Get-запросов по виртуальным путям одновременно превращающий их в реальные для исключения последующей нагрузки. Такого решения лично я не встречал (не надо мне присылать примеры если вы вдруг нашли).
Народ почему-то начал критиковать код, предлагая нагугленые или любимые варианты раздувая дискуссию в совсем иную сторону. Но код только поясняет задачу на случай если для читателя она сформулирована достаточно абстрактно. Сам не люблю когда ставят проблему и начинают растекаться мыслью по дереву не предлагая конкретных вариантов. А так принцип: "не нравится - сделай лучше" - никто не отменял.
Вы опять перепутали солёное с горячим. Я ни слово не сказал ни о качестве статьи, ни о верности способа решения задачи. Я написал только о том, что вы не понимаете сути терминов сжатие и ресайз применительно к файлам изображений. Второй абзац из википедии хоть прочитайте
Алгоритм JPEG позволяет сжимать изображение как с потерями, так и без потерь
и, внезапно, это не про изменение размера. Ресайз не приводит к сжатию, это просто принципиально две разные операции. Да, иногда после ресайза вес картинки может уменьшиться, но это не из-за сжатия. Сжатие можно сделать и без ресайза.
Уменьшение трафика за счёт сжатия изображений. На примере Laravel