а откуда на aws возьмутся разные размеры одного и того же изображения? Самим подготавливать и заливать заранее?Естественно. Так вы контролируете и нужное качество, и формат обрезки, и настройки ресайза...
Хочется это делать по запросу, без предварительной генерации. Вдруг на фронте решат что аватарки теперь будут не 200 пикселей в ширину, а 100.Пока универсального решения не существует, прегенеренные картинки могут быть не актуальны завтра, а все что делает это "на лету" требует процессора, причем чаще всего хорошо так жрет. Учитывая что запрашиваются они не по 1 штуке обычно, да и генерятся из достаточно больших исходных картинок, памяти и проца откусывается дай бог... По сути выбор между хранилищем и процом, причем чаще всего решения склоняются к варианту хранения набора, так как генерить на каждый запрос 100 картинок или запросить 100 готовых картинок это 2 большие разницы. Крайне редко происходят настолько крутые смены дизайна, чтобы все старые выкидывались или не подходили кардинально, просто берут ближайший подходящий размер и ресайзят средствами хтмл... Ну или создают и записывают новые размеры по мере запросов - нет нового нужного размера - создаем, записываем, отдаем. И так по мере запрашиваемости все потихоньку обновляется...
2) хм интересно. но это опять же, работа с изображениями на своей стороне, хранение на своей стороне.Хранение нет, только обработка. Но за нее вы все равно будете платить процессором и памятью, если не у себя, так у облачного провайдера, бесплатно это не будет. Естественно, готовые нарезки хранить сильно дешевле.
{
user: {
name: nameInput.value,
surname: surnameInput.value,
login: loginInput.value,
email: emailInput.value,
password: repeatPassInput.value,
age: ageInput.value
}
}о, дорогой, я вижу ты агрессивен и не адекватен в приёмах замечаний?Нет, если замечания по делу. Твой комментарий никакой смысловой нагрузки, кроме необоснованного почесывания чсв не нес, что я и отметил. Тебя, я вижу, это задело. Ну, оно и понятно, человек, чистящий свои посты ради рейта, к таким вещам как критика относится весьма отрицательно.
Нахрен name="title", name="description"Да, нахрен. Так как это вообще для другого предназначено, в частности для текстовых браузеров (как задумано изначально) и семантики поиска.
А вот схему мы линкуемИ зачем мне эта информация? Чтобы что? Чтобы рассказать что ты умный? Ок, понял, принял. Садись, пять.
А может лучше не og использовать? Может лучше tw, fb и т. п.?Может. Но работать не будет. Или будет. С og работает точно.
OpenGraph не стандарт, а стандарт схемы.О, спасибо, поправил мою глупую ремарку, ты очень внимателен, и главное сильно помог. Пирожок возьми.
$product->photos и четкого списка полей в бд/миграции.Ты хранишь в одной таблице все данные, соответственно нагрузка минимальнаяО, да, точно, "аптимизация" же, экономика спичек должна быть экономной и вот это все... Ну какая там нагрузка на джоинах двух табличек? Что за погоня за ускользающими микросекундами? С таким подходом проще вообще все в одну таблицу с 50 полями свести и все, профит, все летает (спойлер: нет)... И сложности с какими то там сущностями мутными отпадают...
Страницы установки и предварительной настройки современных популярных cms и в частности nextxloud, выглядят иначе. К сожалению, не будучи специалистом в разработке подобного рода приложений, я не могу сходу диагностировать, что именно. Но страница установки в частном случае не может подгрузить никакие изображения, не работают сценарии.Неверный визуал скорее всего обусловлен неверными настройками, например неверным каталогом установки. По вашему описанию сложно понять что конкретно не так, вам же нужно включить инструменты разработчика браузера (F12), раздел консоль, и посмотреть на ошибки возникающие при загрузке страницы. Тогда будет хотя бы примерно понятно в чем проблема. Не исключено что отсутствуют соответствующие настройки для нжинкса, например файлы статики не исключены из переадресации на единую точку входа...
После отправки данных идет задержка 3 секунды, пользователь может отправить форму много раз.то что человек не очень дружит с построением логичных предложений не повод читать только первое предложение из вопроса.
$product->photos-> ?Емнип прямого добавления через связь там нету, тем более что в результате в $product->photos у вас коллекция, а не объект. С фото работаете как с отдельными сущностями (собсно для этого они и вынесены в отдельную таблицу и модель).$product = Product::create([
'title' => 'custom title'
]);
foreach ($images as $image)
Image::create([
'product_id' => $product->id,
'url' => $image['url'],
]);Это нормальная практика.Нет, это жестко связывает 2 независимые сущности, картинку и объект. Решение такое же "нормальное", как хранение списка категорий в текстовом поле объекта айдишниками через запятую. Для кода уровня вордпресс может и норма, для приличного проекта стыдоба.
<input type="hidden" name="source" value="отправлено со страницы <?=$_SERVER['REQUEST_URI']?>">