Вы можете создать мутатор setUsernameAttribute и в там делать проверку на существование записи, бросая исключение в случае ошибки, так у вас модель всегда будет в валидном состоянии.
Там же всё написано, ошибка здесь https://github.com/laravel/framework/blob/5.2/src/...
Значит переменная $driver у вас пустая. Значит у вас проблема в конфиге для очередей
в .env это QUEUE_DRIVER
и в папке config/queue.php
Вторая проблема тоже с конфигом (там ещё наверное и письмо пытаются отослать из-за этого задержка). Посмотрите что вы накосячили, попробуйте конфиги откатить.
Практика показывает, что основ достаточно, по ходу будете разбираться. При обучении джуниоров я даже форсирую переход к фреймворку, чтобы сразу учили лучшие практики.
Единственно разберитесь загодя с фасадами, чтобы поняли что магические статик методы фреймворка на самом деле не статические и их лучше не использовать, а выбрать явное внедрение зависимостей. И побыстрее начните писать тесты, на этапе обучения они очень помогают.
// в layout.blade.php
@section('search')
@include('search.form')
@endsection
// в шаблоне где вывод не нужно делаем блок пустым
@section('search')
@endsection
Стандартный механизм сессий с куками удобен для браузера, так как не нужно самому передавать токен. Вы можете переопределить методы для Auth чтобы он проверял токен jwt и использовать стандартный мезанизм, чтобы не плодить дополнительные сущности.
Советую посмотреть пакет https://github.com/tymondesigns/jwt-auth/wiki/Auth..., чтобы самому меньше писать пришлось
Связывание происходит рантайм
public function items() { return $this->hasOne(....); } и только в момент вызова ->items модель узнаёт о ней
потому технически невозможно отследить связи
Билдте в отдельную папку, которая зачищается и выкладывается на прод простым механизмом вроде rsync + переключения симлинка. Всякие ноды, гранты, папки с ресурсами и вендоровские тесты - лишние дырки в приложениях, так же как и системы контроля версий на проде (хотя это вопрос посложнее).
Вы при инклуде в скоуп бросаете содержимое элементов, а не переопределяете его. Соотвественно он работает всё с тем же $item и впадает в бесконечную рекурсию.
нужно
@include('tags-closure.widgets.edit-form', ['item' => $item['closureTag']]))
@include('tags-closure.widgets.edit-form', ['item' => $el])
Делай опциональные поля по дефолту null
При выводе простая проверка
@foreach(Transactions::all() as $transaction)
@if (!empty($transaction->transactionable))
{{ $transactions->transactionable->name }}
@endif
@endforeach
При желании можешь воспользоваться наследование, создать модель Donate, а от неё UserDonate и GouestDonate. У первого будет метод user у второго его не будет.
Работать с новыми можно без проблем
создаёте миграцию и работаете с существующей таблицей
Schema::table('users', function ($table) {
$table->string('email');
});
php artisan migrate
Если вы хотите сделать миграции по существующей базе, чтобы можно было заново сидить и рефрешить, то поищите нужный пакет, названия не помню, но они есть.
ИМХО, Lumen это высер обиженного Тейлора после теста на производительность, он взял и поубирал вовсе или в ифы часть laravel. Мой опыт общения с подобными фреймворками подсказывает что рано или поздно придтся тащить остальную функциональность, поэтому лучше иметь сразу готовый фреймворк, слава богу с x64 и гигами оперативки можно уже на заморачиваться микрооптимизацией.
Вот вы писали про авторизацию, типа просто, а в самом laravel в этом месте была критическая уязвимость, там много всего хеширование, соление, восстановление, шифрация кук и т.д.. На практике всё "простые" вещи превращаются в набор граблей по которым в последствии ходить очень больно.
Используйте ORM, а не DB::table, не надо страдать. А так результат правильный, на каждое совпадение у вас лишняя запись и нужно потом группировать по уникальному полю. Возможно сработает - groupBy('products.id')