Дмитрий Донковцев

Используйте NSNotificationCenter или делегаты, вот общая статья.

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

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

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

Вот этот так же неплох IBM Swift Sandbox.

Вы указываете только у компонента formatter, лучше задавать в целом по системе, т.е. заходите в main.php и одним из параметров:

'timeZone' => 'Europe/Moscow'

+

если у вас какой-нибудь шаблон advanced, т.е. несколько папок на проект (common, console, frontend), то это надо указать во всех конфигах.

Система контроля версий используется? Возможно хакеры изменили какие-то файлы, внедрив туда свой кусок кода, а проявляется не сразу, т.к. идут обращения на какой-нибудь стороний сайт.

По-идее, добавляете в модель публичное свойство, аля public $some_status, дальше в выборке в это свойство пишете ваши вычисляемые значения и дальше можете по нему сортировать.

Вот пример продвинутого запроса:

$query = ModelName::find()
            ->select([
                'outcome_planned.*',
                'COALESCE(SUM(outcome.value), 0) AS public_field_name'
            ])
            ->with('user')
            ->joinWith(['outcomes'])
            ->groupBy('outcome_planned.id')
            ->orderBy(['outcome_planned.date' => SORT_DESC]);

        $dataProvider = new ActiveDataProvider([
            'query' => $query,
            'pagination' => [
                'pageSize' => 100,
            ],
            'sort' => false
        ]);

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

1) Сделайте

$model['product_tech_spec'] = [new ProductTechSpec()];
    for($i = 1; $i < $count; $i++) {
        $model['product_tech_spec'][] = new ProductTechSpec();
    }

вместо

for($i = 1; $i < $count; $i++) {
        $model['product_tech_spec'][] = new ProductTechSpec();
    }

2) Тут ошибка:

Model::validateMultiple($model['product_tech_spec'],true);

Второй аргумент надо убрать.

3) Так же от двух условий

return $this->render('create', [
                'model' => $model,
            ]);

Можно избавиться, просто удалив два else и вставив этот кусок кода в конце.

Тут нету ничего нестандартного, я бы сделал так:
1) Таблица для избранного: пользователь, материал, время и т.п.
Сравнить количество лайков за вчера и сегодня в таком случае не проблема, но, если ваше количество лайков исчисляется десятками тысяч на запись, то можно еще добавить таблицу с агрегированными за день данными по каждой записи и обновлять ее n раз в сутки.

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

Single table inheritance

Из того, что первым приходит в голову:
1) master и slave базы, slave постоянно синхронизируется с master, большая часть запросов на чтение к slave (там где возможно и там, где нету транзакций, в которых читаем и тут же пишем), в свою очередь пишем в master. Таким образом каждая база может быть специальным образом настроена в приоритет чтения\записи.

2) Механизм очередей: парсинг, обработка и прочее делаются не при запросе пользователя, а демонами (по крону), механизм такой:
1. Пользователь создает задачу, задача добавляется в очередь;
2. Демон, который работает постоянно или запускается периодически берет задание из очереди и выполняет, данный шаг может быть разбит на несколько, например один демон скачивает и добавляет в другую очередь, из которой уже второй демон извлекает нужные данные и т.п.

3) Посмотреть в сторону PostgreSQL, а не MySQL, она является более серьезной БД и, вероятно с частью задач справится лучше, чем мускуль.

Это все, непосредственно в коде, а так конечно возможны всякие балансеры, базы на разных серверах (основная база, базы статистики, базы необработанных данных)

public function getReject()
{
  return $this->hasMany(Reject::className(), ['u_id' => 'id'])->onCondition('reject.processing_id = p.id');
}

Как-то так наверно, только вместо p.id название корректной таблицы или алиас.