jazzus,
1. И по этому стоит выучить основное правило - сначала ВСЕ ЗАПРЕЩАЕМ, потом в нужных местах разрешаем. Это азы запиливания доступов. По этому не стесняемся - запихиваем в hidden
2. И этому автору как правильно делать я указал. С ссылкой. Но если проект маленький и ресурсы там избыточны я указал и второй вариант. Автор вопроса теперь знает два варианта. И сможет выбирать
Александр Панков,
1. код всех этих docker-php-сделай это можно посмотреть в гитхабе. там не так сложно и можно понять что они делают
2. ОС которые используются для докера обычно минимальны. Вот просто что бы стартануло. По этому вагон каких библиотек там нет. их приходится ставить
3. Какие где чего ставить - можно скорее всего посмотреть в зависимостях библиотек.
4. pecl может потребоваться для тех библиотек которых нет в пакетах
jazzus,
1. не надо. не надо разбирать. если у нас есть конфедициальные поля - пихаем в hidden. и даже если у вас все в ресурсах и ресурсами погоняет.
2. Без ресурсов сделано вагон проектов и ничего живут, при помощи appends и hidden. И вроде как подают признаки жизни. То что ноне стоит использовать ресурсы я указал сразу же. Но и использование hidden appends крамолой или костылем не является - по моему глубоком убеждению.
3. Если у вас есть желание продолжить бомбить от того что кто то написал - если лень юзать ресурсы юзайте это, то может вы найдете другого человека?
jazzus, открою страшную тайну сериализация нужна не только что бы с апи работать. По этому использование Resource вас от использования appends и hidden не спасает.
jazzus, ресурсы придумали относительно недавно, а до этого с тем что бы не вываливать конфидециальные поля тоже боролись и для этой борьбы придумали свойство $hidden.
lexstile, в случае с appends не имеет смысла менять существующие поля - они и так при сериализации у вас там окажутся. По этому добавить вы их в $appends можете но толку будет ноль. А если вы пропишете getter для существующего поля - он будет при сериализации использовать его. Собственно если зайти в trait HasAttributes в ларке вся эта магия будет видна.
lexstile, в ларки для апи стоит использовать resources к которые позволят вам использовать $model->logo. Но если лень - поглядите в свойство моделей $appends оно ровно и было предназначено для того что бы пришлепывать к атрибутам моделей всякую фигню при сериализации
class Project extends Model{
protected $appends = ['full_logo'];
public function getFullLogoAttribute()
{
return 'https://site.ru/storage/' . $this->logo;
}
}
Только - использовать здесь setter не верно. Что вы будете делать когда домен поменяется? Базу перелопачивать?
Vitsliputsli, ну сделайте эксперимент - считывайте файл с диска в переменную и смотрите сколько раз он будет делать обращение к диск. Вангую что 100 обращений к веб-серверу будут приводить к 100 обращениям к диску
Есть вариант хранить данные уже в php массиве и запихнуть в предзагрузку. Ну это такое себе решение
Vitsliputsli, php-fpm будет держать в памяти то что нужно ему, и сильное подозрение что никакой php-fpm не догадается считанный с диска json файл держать в памяти.
Андрей Мелентьев, я точно сколько у меня чего будет, но вопрос задавал не я. И что там твориться в проекте мне неизвестно, по этому я предпочитаю смотреть на вопрос - там один логотип, к которому надо добавлять путь. А подход: вижу картинку - надо ставить комбайн для работы с картинками - предлагаю считать избыточным.
