Как стать автором
Обновить

Комментарии 26

Вместо выплевывания картинок посредством Laravel, лучше глянуть в сторону nginx x-accel-redirect.

а еще лучше в сторону nginx-http-image-filter, и генерить картинки "на лету" (через проксирующий nginx с кешем). А если прикрутить nginx-let-module, то можно еще и duble density выдавать вместо обычной для ретина-дисплеев (вмысле при запросе картинки 100х100, выдавать картинку 200х200)

Как вариант, при первой загрузке можно в очередь кидать задачу на ресайз, а возвращать обычное большое изображение, чтобы пользователя не заставлять ждать

Неплохая ученическая работа, но вот портить её желтушным заголовком совсем не стоило.

Или проверку наличия файла сделать в .htaccess

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^image-([0-9]+).jpg$ script.php?width=$1 [L]
а в скрипте ресайзить, сохранять и отдавать первый раз.

Не хочется вас расстраивать, но на большинстве профессиональных серверов этот файлик будет бесполезен чуть более, чем полностью.


И в целом непонятно, зачем городить отдельную запись в конфиге веб-сервера, если и без неё всё прекрасно работает.

Это что-то страшное....

А не проще в webp призагрузке складывать картинки и потом уже в очереди их ресайзить? Тем более webp весит намного меньше

Можно взять готовое решение. Например, imgproxy

Всегда удивляет, как люди умудряются писать такую кучу плохого кода. Обычно когда спешишь и говнокодишь, то получается совсем мало кода, но с проблемами в поддержке. А здесь и кода тьма, и качество ужасное, и проблемы с безопасностью.

Подскажите, кто с ларкой работатет плотно. Это нормальный код для проектов на ларавеле или нет? Мне кажется это ужасным, местами лишние методы, переусложнения и вообще индусский код напоминает

Нет понятия нормальный код для 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://habr.com/ru/post/454944/
Если в двух словах, то в функции imagejpeg из вашего кода есть третий параметр, который отвечает как раз за сжатие. Т.е. при одном и том же размере картинка может быть с разной степенью сжатия. Ну и использование GD в 2022, мягко говоря, выбор неоптимальный. Если вам попадутся хорошо оптимизированные картинки, вы будете удивлены, когда уменьшенная в размерах по вашему коду картинка будет весить больше оригинала.

Цитирую из статьи "В репозитории что я прилагаю - 29 картинок суммарным объёмом 20Мб. Попробуем сжать ... В дальнейшем суммарный объём этих изображений не превысит 90Кб.". На мой взгляд здесь нет никакого противоречия заголовка и содержимого. Ресайз, о котором Вы упомянули как раз и привёл к сжатию, имея ввиду снижение траффика.
Считаю, что если есть рабочее решение которое не требует под себя какой-то отдельной инфраструктуры, то оно имеет право на существование.
На счёт оптимального выбора тут можно дискутировать (чего бы мне не хотелось), т.к. слово "оптимальное решение" предполагает какие-то конкретные условия. Скажем, видел здесь в коментах красивый пример использующий методы ларавеля, но был и вариант с докер-образом, который не совместим например с виртуальным хостингом.

Напомню на всякий случай - примеры здесь написаны не для того чтобы сказать что это единственно верный способ. Задача была просто сделать достаточно шутрый механизм обработки Get-запросов по виртуальным путям одновременно превращающий их в реальные для исключения последующей нагрузки. Такого решения лично я не встречал (не надо мне присылать примеры если вы вдруг нашли).
Народ почему-то начал критиковать код, предлагая нагугленые или любимые варианты раздувая дискуссию в совсем иную сторону. Но код только поясняет задачу на случай если для читателя она сформулирована достаточно абстрактно. Сам не люблю когда ставят проблему и начинают растекаться мыслью по дереву не предлагая конкретных вариантов. А так принцип: "не нравится - сделай лучше" - никто не отменял.

Вы опять перепутали солёное с горячим. Я ни слово не сказал ни о качестве статьи, ни о верности способа решения задачи. Я написал только о том, что вы не понимаете сути терминов сжатие и ресайз применительно к файлам изображений. Второй абзац из википедии хоть прочитайте

Алгоритм JPEG позволяет сжимать изображение как с потерями, так и без потерь

и, внезапно, это не про изменение размера. Ресайз не приводит к сжатию, это просто принципиально две разные операции. Да, иногда после ресайза вес картинки может уменьшиться, но это не из-за сжатия. Сжатие можно сделать и без ресайза.

Ну если вы находите в этом противоречие...

Да это не я нахожу. В гугле наберите compress jpg и resize jpg и сравните результаты...
И, повторюсь, если вы кодом из статьи наресайзите оптимизированных jpg-ов, то никакого "сжатия" у вас не будет.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации