Максим

Вам нужно запускать команду от исполняемого PHP php yii migrate. При этом у вас должено быть в директории два файла: yii и yii.bat. Важно запускать скрипт именно из той директории, где эти файлы лежат. Если у вас файлы лежать в bin/yii или app/yii, то вам нужно перейти в эту директорию

cd app
php yii migrate

echo $form->field($model, 'content')->widget(Widget::className(), [
     'options' => [
         'value' => '123'
     ]
])

<?= $form->field($model, 'parent_id')->dropDownList(ArrayHelper::map(SocialNetwork::find()->where(['parent_id' => $PARENT_ID])->all(), 'id', 'name'), ['disabled' => true])->label('Выберите услугу') ?>

Вот есть ещё от картика

В таком случае у вас получится бешенный контроллер, который отвечает за все запросы по ajax. Хорошо, если у вас будет там 3-4 метода. А если их со временем станет 20 или 100? Такой контроллер никому не нужен.

Если уж идти по такому пути, то создавайте папку ajax и туда помещайте разные контроллеры. ajax/BlogController. При необходимости можно сделать ещё одну вложенность ajax/blog/PostsController. А что если ajax заменить на api? api/blogs/posts Вот и получили простой api. Зачем придумывать что-то новое) Api можно сделать таким простым, как ваш контроллер ajax, только он будет наследован не от web controller и вам не нужно постоянно переформатировать данные.

А если таких ajax запросов много - возможно вам стоит подумать над js фреймворком на frontend. Делать из yii2 js фреймворк такая себе затея.

Тут много нюансов и ответить однозначно сложно. Как уже написал Иван Шумов фреймворк - это инструмент. Каждый инструмент подбирается под конкретную задачу:

• СMS - система управления сайтом (Wordpress, Joomla и т.д.). Создан для простого и удобного управления сайтом (контентом). Как правило, доступен для работы простому пользователю, без знания языков программирования. Подойдёт для: простых сайтов, блогов, там где не требуется нагрузка и безопасность.
  
• RAD framework (Yii2) - фреймворк для быстрой разработки. RAD Фреймворк имеет, монолитную и связанную архитектуру. Он является антипаттенрном и позволяет вам делать всё что угодно, лишь бы вы быстро собрали свой проект. (Используется паттерн Table First - спроектировали базу и по схеме сгенерировали модели данных). При этом Вам никто не говорит, что он не может использоваться для серьёзных проектов. Например, DNS..
  
• Компонентные фреймворки (Symfony, Laravel). Это фреймворки, которые разделены на независимые компоненты, которые вы можете подключать к своему проекту при необходимости. В самом фреймворке заложен только необходимый минимум, а всё остальное вынесено в компоненты. Эти компоненты могут использоваться (или не использоваться). Могут использоваться для другого фреймворка (сам Yii2 использует компоненты симфони). Doctirine, которая позволяет вам забыть о базе данных и сосредоточиться на коде. Фреймворк задаёт вам некий стиль, некую структуру и типизацию и требует более хорошего и обдуманного кодинга. Например, при использовании twig вы не сможете сделать запрос в view. Чего нельзя сказать про Yii. Вы там можете построить хорошую бизнес логику, что и встречается...
  
• Микрофреймворки (Slim). В таких фреймворках заложен самый минимум, а всё остальное программист должен искать или писать самостоятельно, выстраивать свою архитектуру приложения. Он легкий и простой. Кто-то и Symfony относит к микрофреймворкам. Тут меня многие могут упрекнуть. Подойдет для очень простых, гибких, легких приложений, например, микросервисов. Фреймворк не задает вам никаких правил и архитектуры. Вы должны сами продумать все детали приложения. Где-то используете twig, где то Data Mapper, где-то ActiveRecord. Для работы с таким фреймворком требуется много знаний и опыта. Так как вам всё придется делать самому. Здесь за вас никто не подумал.
  

Что же для чего выбрать?
Решать вам исходя из конкретной задачи. Здесь нет понятия хуже/лучше. Чтобы что-то выбрать нужно на каждом попробовать собрать пару проектов. Тогда и будет понимание когда и что выбирать. Это как автомобиль. Какой лучше BMW или LADA? Оба автомобиля, но каждый для своей аудитории, по своим потребностям, для своих задач.

Почему другие говорят что Yii2 плохой?

• 2 версия морально устарела. Это не значит что ВЕСЬ фреймворк плохой, просто им давно никто не занимался. Сейчас идет разработка Yii3, которая многократно лучше 2 версии, но 3 версия доступна только в демо. Поэтому, если хочется писать НОВЫЙ проект на Yii, то я бы не стал выбирать 2 версию. Можете подождать Yii3, но никто не знает когда будет релиз. Можете начать писать используя Yii3-demo, но там может всё поменяться к моменту релиза.
  
• Он монолитный. Если вам требуется сделать проект используя много приложений с разными компонентами, то пойдёте по пути Advanced шаблона, где каждое приложение будет папкой: backend, forntend, console. Однако при большой нагрузке вам потребуется разносить приложения. Тогда ваш core будет дублироваться во всех приложениях. Там будет то, что вам даже не требуется. Потому что Yii2 монолит.
  
• В Yii2 используется Actvie Record. AR - это не плохо. Его многие любят, многие ценят и хвалят. Но для больших проектов он предоставляет неудобства. Например, при изменении поля в базе данных - приходится менять все свойства и надеяться что везде поменяли, так как в GrigView используется магия, при получение значений из модели 'value' => 'profile.last_name'. Так же нельзя сделать свойства модели (сущности), приватными. Из-за чего состояние модели можно изменить где угодно и вы никак не проконтролируете это.
  
• Много абстракции, которую не распознает редактор. Например, вы можете вызвать в контроллере Yii::$app->user->id. Вам приходится делать докблок, что User это common/auth/Identity, а не yii/web/User
  

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

Раз вы говорите о проблеме работы в разных средах, то очевидна проблема в среде.

В коде не увидел как вы обрабатываете zip.

Предполагаю, что фреймворк тут не причём, а проблема кроется на стороне сервера. Смотрите логи на сервере. Возможно проблема именно в самом расширении zip php или настройках php init. На локалке оно стоит, а на сервере нет. Но не понятно почему у вас в логах ничего. Может вы не замечаете...

Если не хотите пользоваться готовыми расширениями есть статья, которая пошагово рассказывает как организовать мультиязычность на сайте.

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

Вам в чём помочь? Разобраться в вашем коде и научить фреймворку? Может быть научить программировать? Настраивать сервер? Или вы ждёте что вам опишут всевозможные сценарии с решениями, а вы выберите подходящий? Нет. Такого не будет)

Ответ на ваш вопрос - идите: на фриланс, в документацию, к программистам на консультацию или приводите вопрос в порядок.

Здесь вам помогут только с правильно поставленным вопросом. В конце концов в advanced шаблоне есть готова реализация. Посмотреть и скопировать проще простого.

Можно задать размер страницы:
/goods?per-page=1000

При запросе /goods выполняется yii\rest\IndexAction, который возвращает

ActiveDataProvider(['query' => $modelClass::find()])

Т.е. объект Pagination там дефолтный

$pageParam = 'page'
$pageSizeParam = 'per-page' 
$pageSizeLimit = [1, 50]

А дефолтный yii\data\Pagination пытается забрать параметры из $request->getQueryParams().

Ваша задача переопределить через DI лимит пагинации у пагинатора $pageSizeLimit = [1, 1000]

PS: 60000 будет многовато. Даже у такого мощного сервиса как ВКонтакте API максимум 1000 по умолчанию 100. Я бы тоже рекомендовал сделать именно так.

Abstract Class yii\mongodb\Migration

class m160719_140557_dialogs extends \yii\mongodb\Migration
{
    public function init()
    {
        $this->db = Yii::$app->mongodb;
        parent::init();
    }

    public function up()
    {

        $this->createCollection('dialogs',['users_id' => [],'settings' => []]);
        $this->createIndex('dialogs',['users_id']);
    }

    public function down()
    {
        $this->dropCollection('dialogs',['users_id' => [],'settings' => []]);
    }
}

Если разные DB можно в init указывать с какой работать.

А зачем вам такое? Это сделано для того, чтобы у вас можно было сделать несколько форм разных сущностей и они без проблем сохранялись. В формах есть такой метод ->formName() переопределите его и возвращайте своё название или пустоту

Ваша таблица employee не может быть базовой для пользователей. Пользователи != сотрудники. Сотрудник может существовать без логина и пароля. Клиент может существовать без логина и пароля.

В вашем случае проще создавать таблицу users и роли создавать там. В этой таблице хранить информацию об аутентификации. Придётся часть данных из Employee перенести в User. Можно переименовать таблицу employees в users и добавить роли. Но тут уже вам решать как лучше. С точки зрения системы хранить все три сущности раздельно хорошая практика.

То что вы выбрали employees как пользователей не совсем верно. Если у вас только сотрудники и все сотрудники пользуются системой, то такой вариант может подойти. Но, как правило, сотрудники могут существовать и без логина и пароля.

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

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

Это у вас все наоборот. В реальной жизни роль объединяет в себе полномочия. Вы даже сами сначала роль, потом разрешение.

role: admin
permission: canAdmin

А в таблице делаете наоборот.

Директор может иметь доступ к админке, а клиент нет. Админ может управлять контентом, а пользователь нет. Если это перевернуть, то получается разрешение управлять контентом может иметь доступ к админу. Где же тут логика?

Роль - это группа разрешений.

Вы можете присваивать разрешения напрямую пользователю, любо объединять их в группу и присваивать группу (роль) пользователю. Иначе никак. Надеюсь понятно.

Если вы хотите при установке создавать свою виртуализацию, то Docker или Vargan в этом вам помогут. Далее с помощью Makefile или SH скриптов прописываете все команды и создаете одну главную init по которой идет запуск всего проекта. Что делают это две вещи? Собственно ничего особенного. Они просто запускают написанные вами команды в нужном порядке. Думаю, что вам это нужно. А использовать это в связке с докер вопрос другой. Вот рабочий пример.

Не существует свойства is_templat в frontend\modules\employer\models\VacancySearch

Не существует колонка. Все же написано. Если она фактически существует, то тогда отключите кэш схемы или почистите кэш.

У вас проблема с множеством переадресацией. Я так полагаю, что у вас этот index является главной страницей. А в контроллере /admin/site/login у вас переадресация на goHome(). Что в итоге получается? Вы попадаете на главную страницу вас редиректит на логин, логин редиректит на домашнюю. И вот у вас цикл. Подозреваю что это так

Нет. На Doctrine такая возможность есть. Но на Yii только расширения искать.

1. Используйте Webpack. Затем сбилденный файл подключайте к фреймворку.
2. Расширение