Alex Wells

А вы попробуйте читать официальную документацию — https://laravel.com/docs/5.3/authentication#events, а не всякое старьё.

Это типичный пример, когда люди не сами доходят до паттернов, а начитываются умных книг и суют свои репозитории и ддд без понятия зачем это нужно.
Сколько уже статей видел об использовании репозиториев в laravel, все прдлагают куегкт Model::all() и т.д. Плевать, что возвращают всё тот же Eloquent, который пытаются убрать.

В проектах на symfony даже при наличии doctrine творится такой же ад. То. что люди не умеют делать нормальные репозитории указывает на то, что оно им и не надо было такой абстракции. Для 99% проектов вообще не стоит тащить абстракции вроде репозиториев.

->get()

То что Вы пытаетесь реализовать, называется наследованием таблиц (Table Inheritance) - это такой способ эмулировать наследование классов в реляционных СУБД.

Всего существует несколько известных вариантов решения такой проблемы, например Single Table Inheritance и Class Table Inheritance (это если не учитывать нативную поддержку подобных вещей в некоторых СУБД, например PostgreSQL).

Полиморфные же связи (которые по-дефолту в Laravel) - это не очень хороший способ реализации, потому что не позволяет поддерживать целостность связей на уровне СУБД. Однако можно использовать и его, если Вам эта целостность не очень важна (ее надо будет поддерживать на уровне приложения).

К сожалению Eloquent не поддерживает ни Single Table Inheritance, ни Class Table Inheritance (зато их поддерживает Doctrine из Symfony), поэтому придется писать вручную.

Прежде чем это делать, я бы Вам посоветовал разобраться как Profile относится к User и OrgAdmin.
Является ли Profile подвидом пользователя (из названия честно говоря не понял), или же это просто набор дополнительных полей, которые можно оформить в виде связей?

Если и Profile и OrgAdmin - это подвиды (подтипы) пользователей со своим собственным набором полей, то Вам нужно добавить в общую таблицу отдельное поле type (это называется дискриминатор), в котором у Вас будет проставлен тип пользователя. Например 1 для User, 2 для Profile и 3 для OrgAdmin.
Короче очень похоже на стандартный Polymorphic Relationships из Laravel.

А потом переопределяете у модели User функции newFromBuilder() или newInstance() в которых Вы укажете какие классы моделей создавать для конкретного type. Вот например статья.

Дальше для Class Table Inheritance можно в трейт поместить функцию сохранения и родителя и потомка, потому что сохранять их придется вместе (на уровне БД), в зависимости от измененных свойств. Кроме того, нужно будет позаботиться об отображении (mapping) атрибутов родителя на потомков (__set и __get), на случай если вдруг захочется делать вот так (представьте что атрибут name принадлежит родителю - модели User):

$profile = new Profile();
$profile->name = 'John Doe';
$profile->save();

Короче это гемор в Laravel. Поэтому перед тем как делать, подумайте можно ли решить задачу проще - например через Single Table Inheritance, поместив все атрибуты в одну таблицу, либо делайте через стандартные полиморфные связи.

Когда я решал эту задачу, я все вышеуказанные функции помещал в трейты. Может когда-нибудь дойдут руки запилить отдельную библиотеку или отправить патч в само ядро фреймворка.

Погуглите по указанным ключевым словам (паттернам), может что уже появилось для Laravel.

Добавили, чтобы вы jquery спагетти не использовали. Vue (как и другие js фреймворки) сокращает количество кода на клиенте и уменьшает его запутанность.

Для примера вы создаете админку для магазина. У вас есть следующие варианты:
1. Делать статическую страницу. На клиенте никакой логики, все вычисляет сервер. При новой покупке администратор должен будет обновить страницу.
2. Писать динамический фронтэнд с использованием vue, angular и чего угодно остального. Бэкэнд шлет вам уведомления через вэбсокеты о новых заказах без перезагрузки страницы.
2.1 Вы берете jquery и сначала все идет хорошо. Первые полчаса. Затем ваш код обрастает огромным количеством обработчиков событий. Если товар заканчивается на складе, его надо убрать из таблицы, затем если заказ отменяется, его надо вернуть в таблицу. Вы его вернули, но почему-то кнопка в строке с ним, вызывающая модальное окно перестала реагировать на события, потом еще что-то случилось и еще. Проблемы с jquery растут как снежный ком и вы проклинаете свое решение создать динамическую админку.
2.2 Вы используете современный js фреймворк. Vue в этом плане хорош низким порогом изучения. Вы загружаете определенные обхекты и в зависимости от их свойств vue сам строит таблицы (с проданными и непроданными товарами), скрывает лишние элементы (не показывать такую-то кнопку, если товар всего 1), отправляет плагинам команды на обновление при изменении объектов и следит за тем, чтобы события, которые отваливались при jquery подходе работали.

Я не сказать что спец в javascript, но (именно поэтому) меня vuejs на текущем проекте очень выручает.

Необходимо использовать очереди https://laravel.com/docs/5.3/queues

Более резиновый вариант, используя коллекции и scope функции:

public function scopeFilter($query, $parameters = []){
    $fields = ['visa_type', 'status', 'company'];
    $filter = collect([
      'visa_type' => null,
      'status' => null,
      'company' => null,
      'paginate' => 40,
      'order' => 'id',
      'sort' => 'desc'
    ])->merge($parameters);

    if (!Auth::user()->hasRole('administrator|Manager')) {
      $query->where('user_id', Auth::user()->id);
    }
    
    foreach($filter->only($fields) as $field => $value){
      $query->where($field, $value);
    }

    return $query
      ->orderBy($filter->get('order'), $filter->get('sort'))
      ->paginate($filter->get('paginate'))
      ->toArray()['data'];
}

Использование -

SomeModel::where(...)->filter([
   'visa_type' => '....',
   'paginate' => 20,
   'sort' => 'asc'
]);

Дальше вопрос по string vs char.. что нужно сделать, что-бы заставить laravel нормально работать с char? Умеет ли MySQL автоматически конвертировать string в char? Прийдется ли городить какие-то костыли, и сложнее ли это будет чем string? Если нет, то лучше ли char чем string? Чем?

Во первых, у MySQL нет типа данных "string". Есть varchar.

Видимо, вы мельком пробежались по миграциям, и увидели что-то вроде этого:

Schema::create('...', function (Blueprint $table) {
            $table->increments('id');
            $table->string('name');

Так вот, string == varchar.

Ты имеешь ввиду пакет? Если да, то плохо искал
Laravel-forum maintained by riari
Вообще ставил его себе, при знание фреймворка, можно хорошо допилить, да и под версию переделать не сложно

UPD: Вот еще, на базе фреймворка flarum.org

View composer

Вы это используете в конструкторе контроллера?

https://laravel.com/docs/5.3/upgrade

Session In The Constructor
In previous versions of Laravel, you could access session variables or the authenticated user in your controller's constructor. This was never intended to be an explicit feature of the framework. In Laravel 5.3, you can't access the session or authenticated user in your controller's constructor because the middleware has not run yet.
As an alternative, you may define a Closure based middleware directly in your controller's constructor. Before using this feature, make sure that your application is running Laravel 5.3.4 or above:

https://laravel.com/docs/5.2/views#sharing-data-wi...
https://laravel.com/docs/5.2/views#view-composers

File => Settings => Directories
или
File => Settings => Languages & Frameworks => PHP (окошко Include path)