JhaoDa

Просто игнорируй это поле при проверке «правильности» или проверяй его наличие и то, что значение в принципе UUID, а не точное совпадение.

Написать для него схему и проверять на соответствие ей. Гуглить «json schema».

Или декодить его в массив/объект, ловить ошибки, проверять ключи/свойства.

Или регулярками пройтись по нему.

File → Settings → Editor → General → Smart Keys : Insert pair quote

А почему они должны там остаться после сохранения? Если бы ты не поленился открыть код метода save(), то увидел бы там в самом конце вызов $this->finishSave(), в котором бы увидел вызов $this->syncOriginal(), который и заменяет старые значения на новые.

Используй события моделей либо передавай старые значения в событие явно.

В указанных примерах дополнительных проверок можно не делать.

Сначала сгруппировать по name, потом сложить.

На сайте есть система авторизации, которая позволяет пользователю зарегистрироваться

Это система аутентификации, надо понимать разницу.

Завтра пользователь, зареганный через основную систему, захочет привязать ВК-аккаунт. И что делать будешь? Создавать его дубль? А послезавтра добавятся Одноклассники. Заведешь третью таблицу?

Правильно:
— таблица+модель юзеров;
— таблица+модель соц. аккаунтов с мылом/токеном/аватаркой, связанная с таблицей юзеров.

Если регается через соц.сеть, то создаёшь юзера с пустым/генерируемым паролем, дальше выстраиваешь логику аутентификации.

Нужно ли знать интерфейсы и трейты, регулярные выражения?

Не нужно, так многие делают. Получается полная херня, но они считают, что нормально. Это как сесть за руль, сказав «ПДД обязательно потом буду учить».

Аутентифицировать его.

В чем проблема написать в контроллере пару where, join, мб как-то по хитрому обработать данные?

Завтра появится задача сделать всё то же самое, но в консоли. Потащищ копипасту или начнёшь выносить общий код в реквесты, репозитории и прочие места?

Тогда просто переносим все в модель? зачем плодить репозитории (кроме как абстрагироваться от конкретной ORM) и остальные сущности?

Репозитории актуальны с паттерном DM и не актуальны с паттерном AR.

При всём при этом следует помнить, что паттерны — не догмы. Паттеры для человека, а не человек для паттернов. Если у тебя одностраничник на хайповую тему, который надо сделать быстро и жить ему месяца два, то не парься и пиши всё в контроллерах. Выживет — перепишешь.

Абисняю:
1. Сохраняешь данные в БД — пользователя в одну таблицу, привязку к соцсети в другую.
2. Аутентифицируешь (это не авторизация, когда вы уже поймёте разницу) пользователя по id в своей БД. Как — написано в документации.
3. Надо запрашивать из соцсети ещё и мыло, оно и будет «объединяющим» ключом — редко кто регается в разных соцсетях с разными мылами. Ну а если и так, то ничего не поделать.

Сделать это средствами веб-сервера.

Сохраняй информацию о заказе у себя, с привязкой к пользователю, а потом уже перенаправляй на оплату. Либо, если по API платёжки можно передать доп. параметры, то передавай туда (с пониманием, что это потенциальная дыра).