Дмитрий

Когда вы получаете данные для отображения, вы можете вообще не использовать модели.
\DB::table('order_dishe')
->join('orders', 'order_dishe.order_id', '=', 'orders.id')
->where('order_id', $oid)
->get();

PS: Весьма странным выглядит то, что вы запоминаете время оплаты за каждое блюдо в рамках одного заказа. Не приходит в голову случай, при котором такое может понадобиться... И почему это именно один заказ, а не несколько...

Вы должны помнить, что когда запускается метод verify - это совершенно новый запуск вашего приложения, никак не связанный с предыдущим, когда выполнялся метод store. В связи с этим запоминание чего бы то нибыло в памяти бесполезно. Каждый запуск приложения Laravel (и любого другого серверного скрипта) - это запуск с чистого листа.
В связи с этим, если вы хотите работать с какой-то информацией (пользователем например), вам нужно ее откуда-то получить. Таким образом если вам нужен пользователь, то вам нужен id пользователя и в verify нужно получить из БД этого пользоателя по id. Ну а дальше сравнивайте что хотите.
Это значит что id вы должны либо передать через форму вместе с verification_code, либо, если он есть в роуте, просто воспользоваться Route Model Binding (как это сделано в store). Короче вам нужно понять откуда взялся $user в store, и тогда вам станет легче, но понять это можно только читая документацию.

Вам не кажется, что вы пытаетесь изобрести один запрос для решения нескольких совершенно разных задач? Вряд ли это положительно отразится на скорости работы приложения.
1. Когда вы отображаете список отелей, то вряд ли вам нужен полный список удобств, да еще сгруппированный... Просто где вы их собираетесь отображать? Может достаточно кол-ва или каких-то важных, заведомо выбранных удобств (бесплатная парковка, например)?
2. Когда вы будете искать отели по критериям, то там будет совершенно другой запрос.
3. Все эти удобства нужны только при отображении одного отеля. Так почему не сделать несколько запросов?
$amenities = $hotel->amenities()->with('groups')->get();
а потом с помощью методов Collection сгруппировать их так, как вашей душе угодно.

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

Модели (и отношения соответственно) нужны в том случае, когда вы собираетесь работать с ними как с моделями, т.е. изменять, сохранять, использовать другую "магию". Но если вам нужно получить данные, которые вы не собираетесь изменять (отобразить, посчитать, использовать в других запросах), то используйте для этого обычный Query Builder (https://laravel.com/docs/8.x/queries) и делайте любые join'ы, какие заблагорассудится.
Имейте в виду, что не всякий запрос возможно (или удобно) делать с помощью Eloquent, особенно когда речь идет о функциях агрегирования.

Каждая кнопка "Создать запись" у вас должна быть внутри отдельной формы, в каждую такую форму вставляйте скрытый input с id рубрики. Это если хотите использовать POST.
Можно, как вы написали, с помощью route('user.post.create', ['rubric' -> $rubrics->id]). Суть та же.
Главное:
В методе контроллера, возвращающем форму, получаете id рубрики и передаете ее скрытым input'ом в саму форму.

Laravel. Иерархический RBAC для самых маленьких

Еще ни разу у меня не было повода сделать редактирование роли в админке... Дать тупому юзеру редактировать роль? Не думаю что в проектах масштаба "Laravel" стоит этим заморачиваться.

Вы можете воспользоваться глобальным обработчиком исключений App\Exceptions\Handler и отображать все, что вам заблагорассудится на любое исключение.

Подробнее можно прочитать в этой бесплатной книге:
https://github.com/adelf/acwa_book_ru/blob/master/...

Дело в том, что объект Request создается "пустой". Нет объекта Session, который был бы связан с запросом. Поиск текста ошибки по исходникам легко приведет вас к месту ошибки, а оттуда нетрудно добраться и до инициализации.

Может вам проще воспользоваться способом, описанным в документации:
https://laravel.com/docs/5.8/http-tests#session-an...

https://phpunit.readthedocs.io/ru/latest/writing-t...

Только не забудьте, что вызывать этот метод нужно до вызова метода, который может поднять исключение.

updateOrCreate предназначен для обновления одной записи, а не массива.
А кроме того, вы ее еще и используете неправильно:

updateOrCreate(<атрибуты поиска>, <обновляемые значения>)

Если эти 29 полей связаны с филиалами, то может часть перенести в соответствующие таблицы?

А вы уверены что это именно в таком контексте должно использоваться?
Мне кажется что последовательность здесь примерно такая:
1. Из SPA с помощью например ajax посылается запрос на длительную операцию.
2. Через определенные промежутки времени через ajax посылается запрос о состоянии задачи. Сервер отвечает 102, если задача еще выполняется, а в теле например процент выполнения.
3. При очередном запросе состояния сервер отвечает 200, говоря о выполненной операции. SPA меняет интерфейс соответствующим образом.

MySQL считает все значения null разными. Из этого и исходи.

Laravel 5. Иерархический RBAC для самых маленьких

Вы можете хранить номер записи с отступом в 10 или даже 100 пунктов и вставлять новую запись в середину между двумя соседними (т.е. присваивать номер 15 между 10 и 20).
Таким образом полностью перестраивать нумерацию вам придется только если промежуток для вставки новой записи уже отсутствует, а это будет гораздо реже чем при +1.

Я правильно понимаю что user_notifications ты заполняешь до create? Ну так вот поэтому последнее сообщение и не попадает туда.

Политики Лары хороши всем, кроме того, что отсутствует понятие "роль", т.е. получается что все политики будут применяться ко всем пользователям без исключений. Но в реальных системах одним пользователям нужно что-то разрешить, а другим - запретить и без ролей становится грустно...
После появления в Ларе политик и гейтов я написал небольшой модуль h-rbac - обертку над гейтами, который позволяет использовать абсолютно все стандартные фишки, но в контексте наличия ролей.
Статья о модуле: Laravel 5. Иерархический RBAC для самых маленьких

Может вам все-таки не хранить темплейт в базе? А хранить путь к вьюхе:

return view($page->template_name, compact('page'));

Ну и сделать общий темплейт с seo секцией, а от него наследовать используемые для страниц.