davidnum95

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

Любой

Реализуйте модель формы с помощью класс \yii\base\Model и внутри нее уже помещайте логику сохранения Ваших двух моделей

Откройте учебник математики, класс этак за четвёртый - пятый. Там где-то должно быть написано, как делить целые числа и как находить остаток от деления.

Посмотреть по стектрейсу, где null, и понять, почему он там.

Как сделать фильтрацию и сортировку по связанным данным довольно подробно описано в документации
что касается конкретно Вашей ошибки - то тут ничего удивительного у Вас есть свойство $balance и реляция с таким же именем, которая так же доступна как свойство. В результате у Вас получается два свойства с одним именем - одно объявленное Вами, второе - "магическое" на основе реляции.
Выход: или переименуйте реляцию или свое свойство

У меня бренды одежды в разных таблицах(nike and adidas)

Что это за костыль? Вы лучше базу переработайте по нормальному, а не просите изобрести костыль для Вашей задачи

Как в React + Redux обмениваться данными между компонентами?

Обмен данными происходит через один общий объект состояния store.
Вам нужно "приконнектить" оба компонента с помощью:

connect(mapStateToProps, mapDispatchToProps)(ComponentName)

и тогда они у вас будут слушать изменения в сторе (за счет, того, что вы передадите в функции mapStateToProps), а так же смогут уметь передавать изменения в стор (с помощью dispatch функции, которую вы будете вызывать внутри mapDispatchToProps).

К сожалению, объяснение очень сухое и может быть не понятным, но и ваш вопрос выглядит как: ребята, объясните мне (желательно кодом) как работает redux. Лучше пройти какоий-нибудь туториал внимательно и такой вопрос сам по себе отпадет.

Если немного упростить, то вам нужно будет:
из компонента Settings вызвать action creator (через dispatch)
в компоненте User это дело поймать (поймаете с помощью редьюсера, на который будет "натравлена" функция mapStateToProps)

Во первых логирование - это сквозной функционал, а размещать сквозной функционал в коде модели (в afterSave) ни разу не тру. Лучше уж сделать отдельное поведение которое будет цеплять на событие сохранения модели и заносить необходимые данные в базу.
Во вторых зачем вообще Вы используете модель лога при логировании? Вам то по сути дела нужно просто сформировать данные и записать их в базу и все. Нет смысла тратить ресурса на модели не используя их функционал, поэтому лучше заносить прямым запросов в базу.

Эмпирическим путем, лично для себя я выяснил, что для работы отлично подходят игровые ноутбуки. Я не шучу, они как правило сбалансированы для нормальной производительности под нагрузкой, плюс с заделом на будущее их делают, плюс матрица, как правило, хорошая стоит . Стоят недешево, но прослужит долго.

swagger

Добрый день.
Всё, что Вам нужно изложено здесь, а ещё здесь.

Ну нихрена ж себе