Dos

1. Прежде всего нужно понимать, что любой Framework, в руках хорошего разработчика будет жить долго и хорошо.
   
2. Framework — это инфраструктура. Framework не предоставляет Вам готовый код и не задаёт архитектуру, он предоставляет Вам низкоуровневые инструменты или их быструю интеграцию, в которых нет необходимости писать с нуля под каждый проект. Хотя, ради практики, было бы не плохо попробовать это сделать, чтобы разобраться в данном вопросе, но сейчас не об этом. Исходя из этого Ваш код должен быть независим от какого-либо Фреймворка. Устарел Yii2 framework —поменяли контроллеры, немного инфраструктуры и код работает уже на Symfony или Laravel. Это касается не только Фреймворков, любая сторонняя библиотека должна быть изолирована от прямого использования. Это позволит Вам быть более гибче и сделает Ваш код менее связанным и зависимым.
   
3. Оба Фреймворка популярны и имеют право на существование. У всех разный порог входа, разное сообщество и разные решения. На Symfony код пишется чуть сложнее и дольше, так как нет привычных фасадов. Многие компоненты и Фреймворки используют компоненты Symfony в виде своих обёрток. Однако, нужно понимать, что Фреймворк задаёт немного стиля в разработке, у Symfony этот стиль более правильный и строгий. Поэтому, использование Symfony интуитивно подталкивает Вас к написанию более чистого кода, без погружения в различные паттерны.
   
4. Doctrine — это НЕ тот же Eloquent. Это совершенно разные вещи!
   Eloquent —это анти паттерн Active Record, а Doctrine это паттерн Data Mapper. Если речь идёт о быстрой разработке и не долгоживущем или небольшом проекте, то можно взять и её, однако на долгий срок лучше использовать Data Maper типа Doctrine, Cycle. При таком подходе ваши поля «не торчат» напрямую из базы данных в код. При изменении столбца в БД — его не придётся менять по всему проекту. Для Data Mapper подход — Code First (Вначале код), а для Active Record — Table Fist (Вначале таблицы). При использовании Data Mapper мы не думаем как будут храниться наши данные в БД, не думаем какая будет БД, что не скажешь по AR.
   

Тема фреймворков на Q&A поднимается очень часто. Лично мне приходилось много раз отвечать на подобные вопросы. Вы можете сами в этом убедится по моим ответам:

• Актуален ли Yii2 Фреймворк в 2020?
  
• Какой подход программирования на PHP выбрать в 202...
  
• Переход к PHP-фреймворку. Какому?
  

Поэтому, серьёзно к таким вопросам здесь не относятся. Чтобы понять разницу — Вам, очевидно, нужно попробовать оба Фреймворка в разных ситуациях. Со временем Вы сами всё поймете. А если Вас устраивает Laravel и не предвидится какого-то большого развития — пользуйтесь. Пару строк кода можно написать и без какого-либо Фреймворка. Главное — результат и правильно подобранный инструмент.

В современном мире действительно стоит разделять backend и frontend. Везде есть свои фреймворки которые стоит использовать для облегчения разработки. Бакенд обычно имеет только api и этого бывает достаточно. А шаблонизатор twig применяют в этом случае для email писем.

Frontend сейчас разнообразен. Это сейчас больше чем CSS+HTML и небольшой функционал на JS. Более того на Frontend сейчас тоже можно делать микросервисы. Одна страница может работать сразу на нескольких JS фреймворках. Например, меню на Vue, а Navbar на ReactJS.

С точки зрения поддержи и развития вы тоже проигрываете. Ведь большой проект требует узких специалистов, в том числе и фронтенд. Если Ваш фронтенд будет на PHP, то на фронтент уже потребуется фул стек разработчик, что дороже и проблематичнее. Значит сложнее масштабирование и развитие. Да и возникают проблемы монорепозитория, куда все изменения с frontend и backend поступают в один репозиторий, без возможности отделения их. Таким образом ко всем разработчикам сразу попадает готовый проект, который легко скопировать и украсть.

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

Фабричный метод — это порождающий паттерн проектирования, который определяет общий интерфейс для создания объектов в суперклассе, позволяя подклассам изменять тип создаваемых объектов.

В PHP, в отличии от других некоторых языков конструктор один. Из-за чего объект нельзя создать несколькими способами, с другими бизнес правилами. Поэтому принято конструктор делать приватным, а объект создавать через фабричные методы вроде create(), requestJoinByEmail(), joinByNetwork() и другие.

Возьмём всем известных User-ов, которые могут появиться в нашей системе по-разному:

1. Создание пользователя Администратором через метод create().
2. Регистрацией пользователя по Email через метод requestJoinByEmail().
3. Регистрацией пользователя через социальную сеть через метод joinByNetwork().

Таким образом наш объект становится более гибким и содержит в себе разные бизнес требования к состоянию в зависимости от способа его создания.

Чтобы хорошо понять суть рекомендую прочитать полезный ресурс — Refactoring Guru - Фабричный метод.

Как вы поняли, на этот вопрос сложно ответить кратко. В программировании, на любом языке большой список материалов изучения, который постоянно пополняется. Всё зависит от Ваших задач и задач Ваших клиентов. Для кого-то главный фактор - быстрота разработки. Для кого-то — простота. Для кого-то стоимость разработки. Для кого-то важна развиваемость проекта написаного кода. Например, есть люди, зарабатывающие настройкой и поддержкой проектов на Wordpress. Поэтому я бы выделил такой путь программиста на PHP:

1. Самописный код
   
2. CMS (Wordpress, Joomla)
   
3. Разработка на фреймворке
   
4. Разработка на микрофреймворке
   

Так как Вы раньше использовали подходы CMS Wordpress, то Вам стоит пойти на следующий этап — разработка на фреймворке. В этом Вы совершенно правильно мыслите.

Фреймворк (framework, «каркас», «конструкция») — это динамически пополняемая библиотека языка программирования, в которой собраны его базовые модули. Фреймворки создаются для упрощения процессов разработки приложений, сайтов, сервисов. Чтобы не писать модуль в приложении с нуля, гораздо проще обратиться к готовым шаблонам фреймворков, которые и формируют рабочую среду разработчика.

Достоинства PHP-фреймворков:

• Производительность. Фреймворки ускоряют разработку. Например, PHP-фреймворк избавляет вас от необходимости писать запросы к базам данных. В фреймворках реализованы базовые функции CRUD, которые необходимы для работы с базами данных.
  
• Масштабируемость. Написанные на фреймворках приложения легко масштабируются.
  
• Удобство. Код фреймворков лаконичный, поэтому с ним просто работать. Поддерживать легче проект на фреймворке, чем на нативном PHP.
  
• Простота. В PHP-фреймворках используются шаблоны проектирования (например, MVC). Это значительно упрощает разработку, делая процесс быстрее.
  
• Безопасность. Приложения на фреймворках лучше защищены, чем приложения на чистом PHP.
  
• Экономичность. В фреймворках реализован принцип DRY. Это позволяет разработчикам писать меньше кода.
  

Какие есть PHP фреймворки для новичков?

Конечно, PHP фреймворков больше, но не все подходят новичкам. Поэтому, можно выделить два популярных фреймворка у новичков:

1. Laravel
   
2. Yii2
   

Путь к изучению фреймворка:

1. Почитать документацию PHP. Начиная изучение с прочтение документации у вас отложится в подсознании какие-то «якоря», которые будут у вас всплывать в процессе изучения и которые помогут быстро находить в документации нужную информацию. Как минимум вы будете знать, что такое есть, а то некоторые узнают о функциях php спустя многие года. Это позволит вам использовать полноценно функционал, а не ограничиваться пару функциями из примеров.
   
2. Изучить ООП. Программировать на PHP можно двумя подходами: функциональным и объектно ориентированным. Последний более популярный и распространенный. Фреймворки написаны используя этот паттерн. Поэтому, перед изучением фреймворка нужно иметь понимание этого подхода. Посмотрите «Неделя ООП» от Дмитрия Елисеева и попробуйте написать свой ООП-код
   
3. Установить фреймворк. Начните с установки фреймворка и попробуйте разработать что-то простое, например, Блог или Новости. Yii2 совсем не сложный. Читая документацию, даже без знаний программирования можно сделать что-то простое.
   
4. Задаваться вопросами и находить на них ответы. Дальше у вас будет возникать много вопросов. Постарайтесь сначала самостоятельно находить на них ответы: гуглите, смотрите документацию, а уже потом спрашивайте у сообщества.
   
5. Перепишите сайт на другой фреймворк. Попробуйте созданный на Yii2 проект переписать на другой современный фреймворк: Laravel или Symfony. Вы получите хорошую практику и навык, который Вам так же поможет в будущем.
   

Почему Yii2 подойдёт новичку?

• Потому что в Yii2, за последние 5 лет, ничего не поменялось. С одной стороны — минус, для изучения — плюс. Ответов и решений полно и они не устарелые, а значит рабочие. Вы хоть что-то сделаете без особых знаний и навыков. Для учебы Yii2 хватит, но не для нового проекта. Как подрастете — возьмёте современный фреймворк или перепишите на Yii3 который будет в конце 2020 или начале 2021.
  
• Потому что Yii2 — это RAD фреймворк (для быстрой разработки). Это значит, что в этом фреймворке заложены принципы простоты и быстроты разработки. Для сложных проектов это проблема, а для Вас же — плюс.
  
• Потому что он монолитный. Вам не придётся устанавливать кучу дополнительных пакетов, включая библиотеку UI на Bootstrap, jQuery . Вы сможете быстро установить и начать пользоваться Yii фреймворком
  
• Потому что Yii2 может сгенерировать код по базе данных используя UI. В Yii2 есть Gii генератор, который прямо по схеме базе данных генерирует вам код в визуальном режиме, поэтому программисты работают быстрее, что не только экономит время, но и уменьшает стоимость разработки.
  
• Потому что Yii2 имеет большое русскоговорящее сообщество и целую толпу ярых фанатов.
  
• Потому что Yii2 быстрый и безопасный. В этом инструменте также заложен принцип Don't repeat yourself, т.е. неповторения кода. А с помощью Ajax и JQuery фреймворк облегчает создание высокомасштабируемых веб-приложений. Хотя и jQuery в 2020 году устарела.
  

Критика в сторону Yii2:

• Тенденции 2020 года — писать чистый код на голом PHP с переносимыми компонентами, не привязываясь к канонам какого-то конкретного фреймворка. Чтобы в итоге не стать заложником одного фреймворка. Yii2 не следует этим канонам. Фреймворк внутри на 99% противоречит SOLID.
  
• Yii2 вышел в 2014-ом году как немного переписанная версия Yii1.1 из 2011-го. Он до сих пор ориентируется на PHP 5.4. Все шесть лет он архитектурно не развивался. С 2018-ого его разработка заморожена. Так что сейчас Вы начнёте практиковаться на заброшенном два года назад фреймворке шестилетней давности, написанном по канонам Yii1 девятилетней давности. Если выйдет Yii3, то там многих из этих канонов уже не будет. Если это одноразовый проект, который один раз написали и забыли, то делать можно на чём угодно и как угодно. Но если проект делают надолго, то чтобы обезопасить себя от сложности таких постоянных переписываний выбирают сразу более свободные и независимые подходы.
  
• Для классического frontend — фреймворк всюду тащит свои встроенные ассеты с jQuery. И чтобы перейти на WebPack надо это из всех мест вычищать. А если делать отдельный JS-фронт, то для построения API половина фреймворка оказывается не нужна.
  
• Если вам хватает технологий Yii, JQuery и PHP 5.4 шестилетней давности, то получайте удовольствие. Если нравится свежий подход с настоящим DI-контейнером, типами PHP 7.4, PSR и свежим JS/TS с WebPack.
  
• Версии Yii 2.1 фреймворка не планируется. Всё обратно несовместимое в 2.0 не проходит. Переход на Yii будет очен затруднён или вовсе невозможен.
  
  

Подитожим. Ваши знания находятся примерно на уровне 2015-2016 годов, как мне кажется. И тут Вам придется решать самому: либо пойти по плавному развитию, пробуя сначала Yii2, со старыми подходами, но ближе к вашим знаниям, а потом перейти на Laravel или Symfony, либо сразу пойти в 2020 год и использовать Laravel или Symfony, которые соответствуют современным подходам, но дальше от Ваших знаний. Можете попробовать установить все и решить для себя на каком фреймворке будете проходить изучение.

Рекомендую к прочтению:

• Актуален ли Yii2 Фреймворк в 2020?
  
• Где найти ссылки на хорошие yii2 проекты, где можно изучить хороший код?
  
• Архитектура приложения. Как сделать независимые модули (сервисы)?
  

$now = new DateTimeImmutable();
$date = $now->setTimestamp(1597252860);
$dateFormat = $date->format('d.m.Y');
echo $dateFormat; //12.08.2020

Нет, нельзя.

На хостинге делается база данных, где лежат диапазоны паролей. Распределённые машины делают SQL-запрос "забрать любой свободный диапазон и пометить его взятым". По окончании перебора этого диапазона - надо "пометить диапазон как обработанный".

Раньше таким образом делали различие в коде для приватных свойств/методов/констант, которые не должны вызываться публично (извне).

Сейчас же есть public, protected, private.

Раньше: function _vk()
Сейчас: private function vk()

Ansible

Убрать подчеркивание.
Или LIKE ESCAPE

s_t_u_v_w и нажимаю найти, мне должно вывести все строгие совпадения с этим ником

SELECT * FROM teleg WHERE nik = 's_t_u_v_w'
Или

SELECT * FROM teleg WHERE nik LIKE 's!_t!_u!_v!_w' ESCAPE '!'

В данный момент из-за того что символ _ заменяется, я не могу найти ники с его участием.

SQL сервер ничего не заменяет.

поставил в ячейках ентеры, из-за этого ничего не находило

SELECT * FROM teleg WHERE nik = 's_t_u_v_w' + CHAR(13)

Или

SELECT * FROM teleg WHERE REPLACE(nik, CHAR(13), '') = 's_t_u_v_w'

Не во всех ячейках есть какой-то символ (или что это такое).

SELECT CONVERT(VARCHAR, CAST(nik AS binary), 2) FROM teleg

Находите ваш неправильный символ. Например, CHAR(13) или CHAR(0x0D) и удаляете его

UPDATE teleg SET nik = REPLACE(nik, CHAR(0x0D), '')

TRIM не срабатывает, так как пробел CHAR(0x20) не последний символ.

MySQL:
SELECT HEX(nik) FROM teleg

UPDATE teleg SET nik = REPLACE(nik, CAST( 0x0D AS CHAR ), '')

Судя по исходнику, объект можно привести к строке и получится то, что Вам нужно.

$bytes = (string)$arr['file_reference'];

Ошибка в миграции Version20200628093518
Она не выполняется из-за того, что в ее инструкции описано добавление поля, которое уже есть в БД...

[error] Migration DoctrineMigrations\Version20200628093518 failed during...

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

Вам нужно привести БД в консистентный вид с миграциями таким образом, что схема бд должна совпасть с выполненными инструкциями, которые есть в таблице с отмеченными миграциями

Вам нужно создать свой Производственный календарь.

Производственный календарь – это специальный календарь, который составлен с учетом праздников и выходных дней на текущий год. Он составляется на основе постановлений правительства Российской Федерации. На основании этого календаря специалисты кадровых служб составляют рабочие графики, определяют число рабочих часов за месяц и начисляют заработную плату. Производственный календарь показывает достоверную и точную информацию о том, какие дни являются выходными, праздничными, либо сокращенными рабочими.

Данные можно хранить в базе данных в виде таблицы holidays (Календарь праздничных и переносимых дней). Пример. Чтобы не придумывать велосипед и каждый раз вбивать эти дни, то в интернете есть много решений, которые предоставляют эти данные:

1. Открытые данные России. Скачиваете последнюю версию, пишите свой конвектор, записываете к себе в базу. Имеется готовый парсер.
   
2. isDayOff() - публичный api по Производственному календарю. Вы можете передать дату и получить всю информацию. Пример: Получение данных за год.
   
3. Xmlcalendar - Производственный календарь в виде XML. Имеется готовый парсер 1 и парсер 2.
   
4. Консультант плюс - Производственный календарь. Имеется готовый парсер 1, парсер 2 и парсер 3.
   

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

Вы можете случайно нажимать два раза на перезагрузку. Браузер при потере соединения пытается сам перезагрузить. Может быть цикл кто-то есть. Функция mail тут не причём. Вариантов много, данных мало.

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

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

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

Я бы сделал так:
- Таблица Приход (ДатаВремя, FK Приходная накладная, FK Номенклатура, Кол-во, Цена);
- Таблица Расход (ДатаВремя, FK Расходная накладная, FK Номенклатура, Кол-во, FK Цена);
- Таблица Списание (ДатаВремя, FK Акт списания, FK Номенклатура, Кол-во, Причина);
- Таблица Остатки (ДатаВремя, FK Номенклатура, Кол-во). Таблица будет хранить всю хронологию изменения остатков (можно будет посмотреть остатки на любой момент времени в прошлом);
Чтобы данные в таблицах были согласованы, необходимо писать в них транзакциями. Например, если на склад поступило 10 карандашей, то внутри транзакции будет сделана запись в таблицы Приход и Остатки. Теоретически можно обойтись и без таблицы Остатки, так как как остатки на любой момент времени могут быть вычислены из других таблиц, но с точки зрения снижения нагрузки на сервер, я бы её оставил.

Как написано в документации:

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

Исходя из определения Модули (микросервисы) существуют для изоляции разных частей сайта друг от друга. Благодаря слабой связанности и сопряженности Модуля, можно менять одну часть сайта на другую без поломок других. При этом нужно учитывать, что база данных таких модулей тоже должна быть независима, а общаются такие модули между друг другом через API или события приложения, когда модули на одном сервере.

При поломке одного модуля — не ломается все приложение. На эту тему можно прочитать статью Как проектировать табуретку?. Когда-то отвечал на подобную тему на Toster.

Архитектуру Модулей в приложении вы можете придумать сами. Главное, чтобы доменный слой был независимым. Под модули можете сделать отдельную корневую папку с названием модуля:

- Backend
- Frontend
- Shop
- Blog

Или же сгруппировать:

- Backend
- Frontend
- Modules
- Modules/Shop
- Modules/Blog

Контроллеры и вид при этом будут просто разделены по папкам модулей:

- Backend/Controller/Shop
- Backend/Controller/Blog
- Frontend/Controller/Shop
- Frontend/Controller/Blog

Например,

так или так. Разделение в Models делите все по папкам модулей:

Model/Shop
Model/Blog

Подведя итог:
1. Модуль служит для изоляции отдельных частей приложения на разные детали. При поломке двигателя не сломается шасси. Шасси можно поменять на шасси от другого авто, при этом двигателю всё равно на каком шасси автомобиль.
2. Модуль можно переиспользовать в других проектах или выложить в отдельный репозиторий и подключать в composer.
3. Хорошо структурированный, читаемый и понятный код. Сопровождаемость.
4. Тестируемость
5. Горизонтальное масштабирование.
и др.

Разделение модулей происходит по папкам следуя стандартам PSR7.

Полезные статьи на схожую тему:
1. https://toster.ru/q/659155
2. Мой вопрос на форуме
3. Организация независимых модулей на Yii2

bbb