DocTypeMaster, что тут может походить или не подходить. будто задача есть) берешь политики и на все запросы к админке кроме админа возвращаешь 404. типа хитрость от хакеров) в документации по моему даже пример с админом есть если не путаю
lavren, так это обычное дело спрашивать почему не работает без кода. он пишет, что при запросе с роута скачивание происходит. ну так во вью, html, blade и тд делаешь прямую ссылку и все. там без разницы откуда, ссылка и ссылка. надеюсь гет роут правильный метод для скачивания)
DocTypeMaster, это решение решает задачу, озвученную в вопросе без оверхеда. если тебе нужна система ролей, учись правильно формулировать вопросы. Для админа и остальных роли не нужны. заниматься лишней разработкой без необходимости и предоптимизацией глупость. на это есть рефакторинг и политики позволят его провести максимально безболезненно.
Sergey Kuzmenko, парсить для created_at не нужно, там и так карбон
$post->created_at->isoformat("D MMMM Y")
И для других дат тоже, если они добавлены в protected $dates модели
А зачем обязательно в одном запросе? бд не от одного запроса сломается чтоли? Три запроса и в кеш. Ну либо коунтер сделать в бд и получай любые цифры в одном запросе.
Андрей, я бы так сделал
если полей этих немного сделать таблицу profiles с hasOne связью к users и там все поля null в перемешку для всех ролей пофиг. Подтягивать, когда нужно. Если полей много и все сложно, то для каждй ролей отдельную таблицу дополнительно к юзеру (client_profile итд) c hasOne связью
Иван, это все извращения, говнокод и геморрой. Есть отличные удобные ресурсы. Создать ресурс для статьи 2 минуты геттеры вызывается там одной строчкой кода
'short_description' => $this->short_description
assertJsonPath