Сергей delphinpro

почему вы всегда забываете, что блоки вы можете плодить как угодно и где угодно. вкладывать блоки внутрь блоков тоже сколько угодно.
в твоем случае, если у тебя меню получается слишком громоздким, то сделай из него отдельный независимый блок.
который даже к header может не относиться. т.е. внутри .top-header у тебя будет блок .main-navigation или .main-menu
и использовать уже сможешь его не только в хедере, а где угодно.

$post->author->username, если у вас отношения в моделях нормально описаны.

А вся проблема в том, что ты не понимаешь, что делает "твой" код.
И следовательно, не можешь его отлаживать.

Это к вопросу о том, как легко и приятно быть программистом, когда код за тебя пишут другие.
Ну вот оно тебе и прилетело в обраточку, это "приятно"

Исходная задача алгоритмически примитивная
И чтобы её не решить, надо совсем уж не годиться в программисты.

Поэтому тебе надо сейчас либо собраться и решить задачу самостоятельно, продумав алгоритм и реализовав его простыми средствами - циклами и условными переходами. Без всяких красивых слов типа array_diff, array_filter и прочих. Потому что использовать синтаксический сахар можно только тогда, когда ты понимаешь, как он работает внутри. Если не понимаешь - то код надо писать руками, а не волшебными функциями.
И после этого, понимая как работает твой код, ты сможешь заняться отладкой, запуская его, и выводя промежуточные результаты.
Либо, если не выйдет, то продать компьютер и идти работать в макдональдс.

А вот это вот как у тебя сейчас - "ой мне один добрый дядя написал кодик, но он ниработаит, давайте другой добрый дядя мне его починит" - это не будет работать. Два раза тебе помогут, но постоянно жить чужим трудом не получится. А "программист", который не умеет писать код сложнее уровня "вайл муэскуэль фетч эррей" никому не нужен.

что такое array_filter? Это реализация примитивного цикла,

foreach ($array as $key => $value) {
    if (!условие фильтра) {
        unset($array[$key]);
    }
}

что такое array_diff? Это реализация чуть более сложного алгоритма, когда мы перебираем первый массив, и смотрим, есть ли такой же элемент во втором. Если нет - то записываем это значение в третий.
И так далее.

window.addEventListener('online', () => {
  // связь есть, скрыть уведомление
});

window.addEventListener('offline', () => {
  // связи нет, показать уведомление
});

Для того чтобы правильно писать catch, надо писать осмысленный код.

А здесь мы наблюдаем очаровательный пример карго-культа.
Узнав, что "толстый контроллер - это плохо, а сервисы - это хорошо", автор небрежным движением руки замел весь мусор под ковёр перенёс весь код из контроллера в "сервис". Ну а что? Контроллер худой, весь код в сервисе!
Тот факт, что сама кривая структура проекта осталась, по сути, той же самой, нас не смущает.
Как и то, что сервис вдруг начал выполнять функции НТТР контроллера и кидать почему-то НТТР исключения. Что с этими исключениями делать в случае, если тот же сервис будет вызван из консольной команды - загадка.

Но самое забавное, что при всём при этом контроллер всё равно пытается выполнять работу модели. Казалось бы, какое отношение интерфейс для обслуживания НТТР запросов имеет к транзакциям в базе данных? А вот поди ж ты!

Чтобы сделать этот код осмысленным, контроллеру всё-таки придется потрудиться, и выполнить какую-то работу самому, а не перекладывать на "сервис". А так же отдать модели то что ей принадлежит.

В общем транзакцию перекинуть в createDefault. причём не напрямую, а ещё ниже - в слой для работы с БД. Стартовать транзакцию до валидации данных - это как бы *не совсем логично*, мягко говоря. И в итоге, как по волшебству, весь этот говнокод исчезнет как страшный сон.
При этом в параметрах передавать не НТТР реквест чохом, а осмысленный набор параметров, вынутый предварительно из реквеста!
В частности, если модель сама проверяет права доступа, то и передавать ид пользователя из авторизации.

При этом модель не должна кидать НТТР исключения. Она должна кидать исключения бизнес-логики. Которые контроллер уже может ловить и транслировать в хттп. Но тут видимо уже сложнее, поскольку это ж ларавель судя по всему.

В любом случае, уж catch (Exception $e)-у тут точно не место

Но это если рассматривать твой конкретный случай.
В общем же случае правильный код написал Илья.

То есть внутри трая операции с БД и коммит.
в кетче роллбэк и перевыброс исключения. Только ловить надо Throwable

try {
  DB::beginTransaction();
  // запись в БД
  // запись в БД
  // запись в БД
  DB::commit();
} catch (\Throwable $e) {
  DB::rollBack();
  throw $e;
}

Внимательно прочитайте htmlbook.ru/css/border-radius и посмотрите на странице все примеры использования

Какие используете единицы измерения при верстке?

Подходящие!
Для решения разных задач используются разные единицы измерения

console.log(new Intl.NumberFormat().format(130000.3948));
// "130 000,3948"