Максим Федоров

Фабрика сделана правильно, но нужно смотреть код где она используется. Поскольку Ваша фабрика отвечает за создание нескольких разных объектов есть риск нарушения принципа разделения интерфейсов

1) Я ее могу реализовать в одном view через tab-pane, но как валидировать формочки от перехода одного таба к другому... Или вообще другое решение есть?

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

2) Мне посоветовали сделать по типу "actionCreate", но после удачного сохранения сделать редирект на следующий шаг заполнения анкеты,

Тут все зависит от устройства Вашей системы. Если система предусматривает что пользователь может бросить заполнение анкеты, а через пару дней вернуться к месту на котором он остановился (и все ранее введенные им данные будут загружены) - тогда такая реализация имеет место. Если же подобной схемы не предусмотрено лучше избежать подобной реализации т.к. получите кучу не консистентных данных

ох что-то Вы намудрили, должно быть что-то типа такого

SELECT
	*
FROM
	clients
INNER JOIN customer ON clients.customer = customer.id_customer
INNER JOIN size_lower_body ON clients.size_lowe_body = size_lower_body.id_lower_size
INNER JOIN size_upper_body ON clients.size_upper_body = size_upper_body.id_upper_size
INNER JOIN messengers ON clients.primary_messager = messengers.id_messenger
INNER JOIN social_networks ON clients.primary_network = social_networks.id_network

Запрос делал для того, чтобы выводить значения вместо id

Лучше Вам использовать LEFT JOIN вместо INNER_JOIN

В моделе объявлена реляция Status? + в моделе Status объявлена реляция Vacancy?
Если да, тогда можно сделать так:

$query->joinWith(['status s', 'status.vacancy v'])->where([
    'like',
    's.id_vacancy',
    $this->idVacancy
])->andWhere([
    'like',
    'v.title',
    $this->titleVacancy
]);

Между прочим:
1. У Вас что идентификаторы в виде строк хранятся? или причем здесь like?
2. $q->where('status.id_vacancy LIKE "%' . $vacancy_id . '%"'); - поздравляю! Вы только что сделал дыру в безопасности сайта, про SQL-injection не слышали?

Рекомендую Вам потратить небольшое количество времени и посмотреть вот это видео вроде бы в нем все понятно разжёвано

В функции aggregator над каждой строкой выполняются многочисленые действия, после чего разные части строк записываются по таблицам.

Плохо, метод должен отвечать только за реализацию одного логического действия, а не за все и сразу

Меня интересует как можно накопить записи в массив в функции aggregator,

По нормальному никак ... можно например использовать global или аналогичные варианты - но это будет плохой код

Лучше разделите ответственность методов, например так:

class MyClass
{
    public function uploader($rows)
    {
        $items = [];
        foreach ($rows as $row => $data) {
            $items[] = $this->aggregator($data);
        }
        $this->save($items)
    }

    public function aggregator($data)
    {
        // выполнение нужных операций над данными
    }

    public function save($items)
    {
        // сохранение массива данных, аля batchInsert
    }
}

Не нравятся мне всякие Yii::$app->params['site_title'] массивы для настроек.

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

ну типа чтоб в шаблоне было $this->settings->get('site_title');. Нормально не?

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

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

Нужно сделать столбец, который будет описывать очередь к этому пользователю.

Это плохая идея, раз уж Вы используете реляционную СУБД тогда стоит придерживаться правил ее построения.

В очереди будут id других пользователей. Как реализовать?

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

папка environments содержит скелет для настроек приложения зависимых от окружения. Тоесть по факту, когда Вы разворачиваете проект в определенном окружение и выполняете команду init происходит копирование конфигов из папки environments в соответствующие папки и уже в них Вы указываете все параметры которые зависят от окружения (доступы к БД и т.п.). Соответственно в конфигах /common/config/main.php и т.п. указываются настройки не относящиеся к окружению (список компонентов и т.п.)

Как без лишних костылей сделать разные конфиги для БД в Yii2 advanced?

итого Вам нужно:
1. Выполнить инициализацию проекта с помощью init
2. Заполняете данные доступа в конфигах с префиксом -local

Ссылку можно сформировать например так:

<?= GridView::widget([
    'dataProvider' => $dataProvider,
    'columns' => [
        [
            'attribute' => 'id',
            'content' => function ($model, $key, $index, $column) {
                $url = \yii\helpers\Url::toRoute(['url', 'id' => $model->id]);
                return Html::a($model->id, $url);
            }
        ]
        'name',
    ],
]) ?>

вместо URL - должен быть адрес контроллера отвечающего за вывод информации о товаре

Как мне в этом файле обратится к моделе компаний например?

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

но при выводе результата я не вижу полей которые там должны присутсвовать

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