Сергей Мочалов

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

• С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
  

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

Имхо, оптимальным решением будет получить у того же рег.ру статус партнера и партнерские расценки: и переносить не придется и расходы существенно сократятся.

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

• ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы.
• ГОСТ 34.601-90. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания;
• ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплексность и обозначение документов при создании автоматизированных систем;
• РД 50-34.698-90. Методические указания. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.

https://gist.github.com/

www.freecodecamp.com

При повторной потере мотивации алгоритм следующий:
1) Идем высыпаемся. По-нормальному так, без будильников. Чтоб глаза вообще больше не закрывались.
2) Если мотивация не вернулась (возвращается в 70% случаев) - берем велик (хотя можно и пешком) - и на улицу. Если есть приличный парк в городе - находим пару нестандартных физ. упражнений (можно боевых), пытаемся выполнить. Работа с телом и физические нагрузки - это совершенно другая часть вашего сознания, про нее нужно не забывать.
3) Если мотивация не вернулась (уже где-то 85% случаев) - берем случайную книгу (не техническую), в идеале - из жанра который вам нравится. Читаем. Спокойно, страницы не считаем.
4) Если не вернулась, повторить с п. 1 до пяти раз, не думая о времени и выполняя только самые важные дела (срочные задачи по учебе, работа, если есть), можно даже попросить родных/знакомых помочь по дому и бытовым делам, чтобы себя разгрузить.
5) Если не помогло после 5 раз, задаем новый вопрос на тостере, подробно описываем что делали).

Хотя бы один из п. 1-3 выполняем для профилактики каждый выходной.
P.S. в принципе плохо сравнивать себя с кем-то - для "сравнения" на свете есть всякие соревнования и состязания, где есть правила и контекст. В жизни правил нет, один учится в MIT, другой учится в колледже в России - какие могут быть сравнения? Вы думаете тут большинство людей за один год все узнало и всего добилось? Вы глубоко заблуждаетесь) PHP-шники-выскочки не в счет, у них искаженное представление о реальности.

1) Нет. Обычный сайт - это одно короткое соединение на один запрос к серверу. Время жизни соединения ограничено одним request (пришёл запрос - соединение создалось, отдали ответ - оно умерло). Выигрыша по сравнению с обычными синхронными фреймворками нет. А так как нода - однопоточная, то может случиться так, что соединение, в котором выскочила ошибка убьёт всё приложение.
2) Нет. Бери любой развитый MVC-фреймворк на любом языке, так легче.
3) Для тех, где нужна асинхронность: прикрутить вебсокет-чат для готового сайта, работа с очередями сообщений (чтобы принимать их в неблокирующем режиме), рассылка уведомлений, запись в БД без блокировок, и т.д. Т.е. обычно его используют там, где надо держать много одновременно открытых соединений, каждое из которых не требует много процессорного времени, но может тормозить из-за IO.

У Polylang есть свои собственные маленькие функции, полезные для таких целей. Конкретно в этом случае, есть 3 варианта:

1. Локализация строки обычным методом WordPRess - в шаблоне находим где этот текст и оборачиваем его в функцию _e() или __(). После этого делаем перевод строки в POedit, Как обычно.

2. Локализация строки точно так же, как в п.1, только вместо внешнего POedit ставим плагин Loco Translate и переводим строку прямо в админке.

3. Вместо функций _e() или __() используем функции pll__(), pll_e() вместе с pll_register_string() и переводим в админке WordPress на странице настроек Polylang. Документация.

В любом случае, придется ковыряться в коде.

Фреймворками решаются задачи, которые с использованием CMS решать сильно не оптимально и чаще приходится постоянно бороться со стандартами самой CMS, чем использовать что-то готовое из неё.

Например, для RSS-читалки вроде https://feedly.com/ CMS использовать нет никакого смысла.

Выбирай PhpStorm, в нем практически все тоже самое что и в WebStorm + собственно поддержка php, фреймворков и некоторых cms на нем написанных.