Максим

Ответ не такой, который вам нужен, но есть повод задуматься. Если вы умеете работать Query Builder от Yii, а так же умеете применять Join, и понимаете в SQL запросах, то используйте хоть голые SQL запросы или при помощи QB от Yii. Почему? Потому что данные выходят к вам в виде ассоциативных массивах и такой массив вы либо уже загоняете в своё DTO, либо работаете как с обычным массивом, либо переформатируйте этот массив в json. Если вы будете получать данные по связям, то у вас возникнет большая проблема с производительностью и код от этого станет плохим. Это больше касается когда вам нужны данные для вывода списка (index). Если вам данные нужны в (view), то там можно попробовать работу по связям или виджеты.

Yii advanced. Либо возьмите из готового проекта. Можно взять у Елисеева Дмитрия на Github

Странный вы. Зачем вам такой огород?

1. Если у вас 2 разных api и вы с ними не взаимодействуете по общим авторизационным данным - разделяйте их на 2 приложения.
   
   
2. Если у вас 2 разных api использующие общие авторизационные данные - делайте либо их папками в одном приложении, либо два разных с межсайтовой авторизацией.
   

/*css*/
.has-error .control-label {
     color: none;
}
.has-error .form-control {
     color: none;
}

Ваше видение наследования и приведёт к говно коду. В Yii2 и так много наследований и разногласий с SOLID.

1 Форма-фильтр сайта = 1 SearchModel

Сначала поймите что такое SearchModel и вы поймёте её ответственность. Это форма-фильтр, которая принимает данные от пользователя и делает выборку данных по переданным параметрам из базы. Вам будет казаться, что вы дублируете код, но это так. Вы разделяете поисковые модели под определённые задачи.

Пример: На главной странице — вам нужна форма-фильтр по одному/двум полю/ям. В расширенном поиске — форма-фильтр по нескольким полям. Если у вас в разных местах одни и те же параметры фильтрации— вы используете одну форму в двух местах. Если данные разные — создаём новую SearchModel. Их может быть столько, сколько потребуется. Под каждые задачи.

Важный момент, который чаще всего используют в Yii SearchModel - это наследование от основой модели Acrive Record. Этого делать категорически нельзя. Так делают только для быстрой разработки. При такой разработке все поля базы торчат «наружу». Рекомендую все SearchModel наследовать от простой модели (класс Model). Тогда Search Model будет безопаснее и она будет всего лишь формой, а не формой с дополнительными возможностями.

Это не имеет особого отношения к Yii. Это обычная работа с массивами и ООП. А как вы будете сохранять (через AR, Doctrine) и куда (mysql, postgresql) не имеет значения.

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

Пример Сущности.

Чтобы со связями можно было работать так же как с массивами-объектами, то лучше использовать yii2-save-relations-behavior

Команда yiic не найдена.использейте команду yii

1.

// Кэширование запросов для DAO
// Возвращает ассоциативный массив с именами столбцов и значений
$categories = Yii::$app->db->cache(function () {
  return Yii::$app->db->createCommand('SELECT * FROM `category`')->queryAll();
});
 
 
// Кэширование запросов для ActiveRecord (на 1 час)
// Возвращает объект
$categories = Category::getDb()->cache(function (){
    return Category::find()->all();
}, 3600);

2. Кэширование производится при необходимости, а не ради кэширования. У вас проблемы с нагрузкой? Зачем кэшировать?)

На ваш вопрос Александр ответил следующее:

BaseOAuth::defaultReturnUrl() doesn't specify protocol. It means return URL generated matches protocol used at the website. If your website is served via HTTP it doesn't make sense to set return URL to HTTPS.

Подробно можно прочитать тут

Полностью с ним согласен. Но если вам нужен такой костыль, то вот

Вы правильно думаете. Сначала он удаляет, а потом добавляет заново. Это можно найти в коде тут. Если вам интересен этот урок, то он называется Дмитрий Елисеев— yii2 интернет магазин

Можно ещё изменить формат виджета:

<?= $form->field($model, 'category_at')->widget(DatePicker::class, [
        'options' => ['placeholder' => 'ДД.MM.ГГГГ'],
        'pluginOptions' => [
            'todayHighlight' => true,
            'todayBtn' => true,
            'autoclose' => true,
            'format' => 'dd.mm.yyyy',
            'startView' => 'months',//'startDate' => date('d.m.Y'),
        ],
    ]); ?>

И тогда изменить валидацию:
['datetime', 'date', 'format' => 'php:d.m.Y']

Есть ли смысл использовать тригеры и есть ли прирост от этого, а может и наоборот?

Зачем вам логику добавления даты куда-то перемещать?

Если использовать поведения, то есть один из недостатков — у вас сохраняются данные всегда при создании и обновлении.

Например, вы обновили счётчик поросмотров - у вас обновилась дата обновления. Хотя логически она должна изменятся приобновлении какой-то важной информации (контента). Если вы эта дату выводите на страницу, то будут проблемы. Вы обновили только счётчик просмотров контента, но не меняли контент. Такая дата дезинформирует пользователей. При любом просмотре пользователем дата будет обновляться.

Я бы рекомендовал выстраивать логику таким образом, чтобы вы управляли датами на уровне бизнес логики. Если это дата создания, то передаёте дату при создании сущности. Если это дата обновления, то при изменении контента.

Небольшой пример. Есть блог. С полями: заголовок, дата обновления, просмотры. Вы обновляете счётчик посещения - обновляется дата. Это не логично. Дата изменяться должна при обновлении контента.

А теперь сижу и думаю, правильно ли у меня реализована логика?

Не правильно

Есть очень удобное для этого расширение, которое позволяет использовать код более лаконично: yii2-save-relations-behavior

Вы напишите что меняли? Каждый должен сравнивать ваш код с оригиналом?

Как по мне эта часть кода не правильная:

$widgetClass = $widgetConfig['class'];
        if (!(is_subclass_of($widgetClass, AuthChoiceItem::AuthChoice))) {
            throw new InvalidConfigException('Item widget class must be subclass of "' . AuthChoiceItem::AuthChoice . '"');
        }

Должно быть
AuthChoiceItem::class

class Controller 
{
  private $repo;

  pulic function __construct(MissionRepository $repo) 
  {
    $this->repo = $repo;
  }

  pulic function excuteMission($id)
  {
    $mission = $this->repo->find($id);
    $mission->next();
    $mission->save();
  }
}

class Mission
{
  private $progress;

  public function next(): void
  {
    $progress = $this->progress + 10;

    if($progress > 100) {
      throw new DomainExeption('Миссия не может быть выполнена.')
    }
    if($progress = 100) {
      throw new DomainExeption('Миссия уже выполнена.')
    }
  }
}

А вообще используйте тесты и вы сами поймёте что нужно, что не нужно.

Пропробуйте:

$query = Product::find()
        ->joinWith('prices', true , 'LEFT JOIN')
        ->orderBy(['price.price' => SORT_DESC])
        ->distinct();

Используйте NestedSets. Для YIi есть хорошее решение paulzi/yii2-nested-sets

Конечно можно! В чем проблема?) Сделайте так же как в Mailer. Можете хоть HTML там передавать как в mailer. В mailer есть шаблон текста и шаблон HTML.

Создайте php файл. В него вставьте необходимые переменные и доставайте данные из этого файла, заменяя переменные.

Если вам этот вариант не подходит, то вы можете использовать переводы. Других вариантов нет. Да и не зачем)

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

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

При присваивании роли «Администратор» какому-либо пользователю ему становятся доступны все разрешения этой роли. Так же роли можно наследовать. Админ может наследовать роль пользователя и дополнительные разрешения.

Если вы добавили новое разрешение системы, то вы просто присваиваете это разрешение необходимой роли. И всем пользователям этой роли становится доступно это разрешение. Если бы не было ролей - разрешение нужно было бы присваивать всем пользователям.

В небольших проектах можно обойтись ролями без разрешений.

Роль служит для группировки разрешений.

Достаточно понятно описано в Википедии.