Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Если изображение сохраняется на сервер в разрешении 500х500, а для некоторой view нужно вывести его же 50х50, как это лучше сделать?
Думаю ресайзить два раза и сохранять в двух папках не лучший вариант?
Или лучше средствами css выводить уменшенное?
Сейчас для вывода использую хелпер:
{{ Html::image() }}Изменено Tarasovych (23.04.2017 12:46:07)
Не в сети
Можно ли в хелпер просто дописать 'style'=>'height:50%'?
upd так и сделал, тему можно удалить
Изменено Tarasovych (23.04.2017 13:06:57)
Не в сети
Попробуй так:
ПисарьHtml::image('image.jpg', null, ['style' => 'height: 50%'])Лучше, конечно же, это в стили вывести и сделать:
['class' => 'some-image-class']Не в сети
Попробуй так:
Html::image('image.jpg', null, ['style' => 'height: 50%'])Лучше, конечно же, это в стили вывести и сделать:
['class' => 'some-image-class']
Спасибо!
Не в сети
Мастер 
- Можно ли в хелпер просто дописать ’style’⇒’height:50%’?
Что же тут хорошего? Вместо 10 Кб вы будете грузить все 100? А если картинок — пара десятков на странице?
Идеальное решение — это пережатие на стороне сервера, а именно nginx. Есть очень полезный модуль image_filter, он тебе и закэширует (в связке с proxy_pass), и разные форматы поймёт, и можно даже пережимать на основании переданных параметров:
# http://site/resize/my/image.jpg?width=50&height=50
location /resize/ {
alias /home/images/;
image_filter resize "$arg_width" "$arg_height";
}
Не в сети
Мастер 
мне не кажется особо удачной идея конвертировать изображения на nginx. во-первых, нужны познания в администрировании линукса чтобы просто пересобрать его с нестандартным модулем, во-вторых, обновляться из репозиториев nginx после этого перестанет – до свиданья секурити фиксы, здравствуй ручная пересборка на каждый новый апдейт (если вообще будет кому этим заниматься), в-третьих, эффективность nginx – следствие его хитрой поточной модели, когда он в одном потоке обрабатывает все соединения. если это расширение блокирует поток на то время пока оно конвертирует изображения – до свиданья производительность.
и напоследок – прошёл по ссылке и на первой же странице написано что он использует старую, тормозную библиотеку gd. там и качество изображений похуже получается и возможностей намного меньше по сравнению с imagemagick. ну и памяти оно кушает побольше.
в общем, спасибо за пост. до этого раздумывал что возможно в каком-то проекте и правда есть смысл использовать ngx_http_image_filter_module. теперь я на 100% уверен, что это вообще не вариант. php_imagick – наше всё.
Не в сети
Мастер
- во-первых, нужны познания в администрировании линукса чтобы просто пересобрать его с нестандартным модулем
Если в документации написано, что этот модуль не нестандартный, а не включен в сборку по умолчанию. Под каждую ОС свои пакеты и во многих (точно — в CentOS) этот модуль включен, как и десятки других.
- если это расширение блокирует поток на то время пока оно конвертирует изображения – до свиданья производительность.
- и напоследок – прошёл по ссылке и на первой же странице написано что он использует старую, тормозную библиотеку gd.
Ну да, imagick с десятками критических багов (RCE), которыми, в частности, взломали один из серверов Facebook — конечно, лучше. И чтобы избежать этого — внезапно — надо тоже настраивать сервер.
Если так смущает использование старой библиотеки — то не смущает, что Laravel сам (был) построен на Mcrypt, заброшенной ещё в 2007, с известными проблемами с реализацией AES и другими недостатками?
Подход к оценке тормозов неверный. Если у тебя на сервере куча статики (миллионы изображений) — то узким местом будет канал. Если наоборот статики мало (пара сотен или тысяч каких-нибудь аватар) — то ни сеть, ни тем более ЦП узким местом не будут — здесь nginx просто помогает избежать ручного разруливания кэшем, для чего он и был создан.
Не в сети
Идея очень интересная, но nginx я бы использовал только, если в команде есть разработчик/админ ответственный за сборку и настройку nginx с нужным модулем. Мне нравится, когда приложение минимально зависит от среды и я на 100% могу контролировать функционал даже при "переезде". Я бы использовал пакет вроде croppa, который также "на лету" создает изображения по размерам, указанным в URL.
Изменено AlexeyMezenin (24.04.2017 11:19:29)
Не в сети
Мастер
- Мне нравится, когда приложение минимально зависит от среды и я на 100% могу контролировать функционал даже при «переезде».
Согласен, если обработка картинок это побочный функционал (как то аватары разного размера на среднем форуме) — тогда да, простота и удобство в смысле что всё зависит только от PHP. А если от картинок хоть как-то зависит производительность (типа сайта с фотографиями, где картинки это основной смысл ресурса) — лучше отдавать статику веб-серверу, а не скриптам — но тут сисадминские руки требуются в любом случае, для балансировки и прочего.
Не в сети
Согласен, если обработка картинок это побочный функционал (как то аватары разного размера на среднем форуме) - тогда да, простота и удобство в смысле что всё зависит только от PHP. А если от картинок хоть как-то зависит производительность (типа сайта с фотографиями, где картинки это основной смысл ресурса) - лучше отдавать статику веб-серверу, а не скриптам - но тут сисадминские руки требуются в любом случае, для балансировки и прочего.
Согласен.
з.ы: с возвращением, Алексей.
Да я вроде здесь. 
Просто загрузка была бешеная.
Не в сети
Страницы 1
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)