Do I need to strictly follow PHP standards when developing a CMS?

Question

CMS

THE ESSENCE OF THE QUESTION UNDER THE SPOLERM

spoiler

Добрый день. Разрабатываю для себя собственную CMS систему и решил сделать все по человечески с использованием стандартов PHP. Изучая стандарты наткнулся на такую вещь как размещение файлов с привязкой к namespace по стандарту PSR-0 и столкнулся со следующей проблемой.
Согласно стандарту мои классы должны лежать по следующему адресу:
<путь к папке с библиотеками>/<имя поставщика>//<имя класса>.php
что соответствует классу <имя поставщика>\\<имя класса>
<имя поставщика> как я понимаю это компания которая поставляет библиотеку. Если компания моя, то там должно быть название моей компании, если это сторонний разработчик, то его. И тут меня все устраивает за исключением одного момента.
у меня ядро проекта структурно разбито на папки:

<путь к ядру>/lib/<имя поставщика>/ - тут лежат вспомогательные библиотеки от данного поставщика
<путь к ядру>/components/<имя поставщика>/<имя компоненты>/ - тут лежат классы для работы компоненты от данного поставщика
<путь к ядру>/modules/<имя поставщика>/<имя модуля>/ - тут лежат классы для работы модуля от данного поставщика
<путь к ядру>/plugins/<имя поставщика>/<имя плагина>/ - тут лежат классы для работы плагина от данного поставщика

и в идеале мой namespace должен строится как:

lib\<имя поставщика>\<namespace>\<имя класса>
modules\<имя поставщика>\<namespace>\<имя класса>
components\<имя поставщика>\<namespace>\<имя класса>
plugins\<имя поставщика>\<namespace>\<имя класса>

с точки зрения проекта это было бы лаконично, понятно и удобно в функциональном плане, но как я понимаю PSR-0 предписывает мне создавать другую структуру, следующего вида:

<путь к ядру>/<имя поставщика>/lib/ - тут лежат вспомогательные библиотеки от данного поставщика
<путь к ядру>/<имя поставщика>/components/<имя компоненты>/ - тут лежат классы для работы компоненты от данного поставщика
<путь к ядру>/<имя поставщика>/modules/<имя модуля>/ - тут лежат классы для работы модуля от данного поставщика
<путь к ядру>/<имя поставщика>/plugins/<имя плагина>/ - тут лежат классы для работы плагина от данного поставщика

что соответствует следующим namespace

<имя поставщика>\lib\<namespace>\<имя класса>
<имя поставщика>\modules\<namespace>\<имя класса>
<имя поставщика>\components\<namespace>\<имя класса>
<имя поставщика>\plugins\<namespace>\<имя класса>

все ли я верно понял?
имеет ли смысл в моем случае использовать стандарты PSR-0 или нужно забить на него и просто описать свой стандарт наименования namespace и их размещение в каталогах для разработчиков, ведь по сути файлы в проект будут попадать через инстолятор в админке который будет из архива извлекать файлы согласно XML инструкции и размещать файлы согласно внутреннему алгоритму.
Еще я поглядел в сторону PSR-4 и вроде как там такой проблемы нет, она позволяет реализовать то что я описал выше, но я могу ошибаться, так что про это тоже поясните пожалуйста.
PS: использовать composer не планирую, все библиотеки будут писаться мной, но планируется что для данной CMS системы могут разрабатываться сторонние модули и плагины.
В проекте есть строгая классификация папок, грубо говоря классы модуля должны быть в папке с названием модуля внутри папки modules, но как я понимаю придется мне пересматривать структур своего проекта и эту привязку к папкам или отказываться от PSR-0 стандарта и вводить свой стандарт для разработчиков, в общем жду ваших идей.
PSPS: небольшие пояснения о том что подразмевается под modules | components | plugins
components - генерируют по факту основной контент страницы. На странице обязательно есть один и только один компонент. Подставляется в контентБлок шаблона
modules - генерируют вспомогательный контент, например меню, баннер, блок с контактами и т.д. Подставляются в именные блоки шаблона. В каждом блоке могут отсутствовать модули. Количество модулей в блоке не ограничено.
plugins- не участвуют в генерации контента а выполняют функцию расширения функционала. Например подключение по необходимости JSбиблиотеки или реализация всплывающих окон и т.д. Чаще всего их функционал работает независимо от страницы или используется как зависимость для модуля или компоненты. Например без включенного плагина JQweryLoad не будут работать всплывающие окна написанные на jqwery если они используются в шаблоне модуля.
каждый элемент системы как и сама система будут реализованы на основе MVC

It seems like I came up with the following solution.
The CMS system itself, along with the modules and components reserved in it, is located in the root of the project, and the auxiliary libraries downloaded via composer are in the vendor folder.
If Petya wants to develop his own module, then he writes it, uploads it to the composer and then can register it on the website of our cms system with the settings for his module (entry point and other necessary).
When any user wants to install a module for the CMS, he enters the interface through the admin panel and sees the full list of modules from our server, chooses which one he needs to install, and he receives a configuration file, which first downloads everything necessary through composer, and why, according to the configuration file, data is entered modulo into the system. Since the configuration file is created on our server, it will always be correct, which will make life easier.
If Petya for some reason does not want to register his module with us, then he can download his module through another interface that simply puts packages through composer and then try to define it as a module through another interface, if it meets all the requirements, then the package will be initialized as a module and added to the system.
What can you say about this approach?

Answer 1

Following the PSR is not a dogma if you don't care about the future of your project. However, if you don't want to get confused yourself in a year where and what you have, if you don't want to create a headache for other developers (who will pick up the project after you) - PSR MUST HAVE.
Take a look, for example, here.
https://github.com/yiisoft/yii2-app-advanced
See how everything works there.

Answer 2

TL;DR
You want to spend a lot of time just like that, alas. If you really want to make cms - do it, but take the framework as a basis, Silex for example (Symfony is better, of course, but the entry threshold is quite high there).
-------------------------------------------------- ---------
Use PSR-4 Luke!

and ideally my namespace should be built like:
lib\<provider name>\< namespace>\< class name>....>

Bad idea, really. Namespace is worth doing: < vendor >\< project >\<...>\ClassName
By connecting dependencies through composer, you will find that the path to the final file will be:
And this is regardless of whether your cms is used or not. The path will be the same everywhere.
Don't repeat the foolishness of CodeIgniter. Your cms is a dependency under your vendor, it should not be mixed with a project on that cms.
Well, don't be stupid. Autoload and dependency management is a solved problem. Your version will not be better, take it as the original.
What prevents you from making a configuration system for each module? Rigid file/directory positioning is like aligning people in height with a circular wheel))
Your classification, to put it mildly, is not obvious. Usually a module is some large part of the system, consisting of components. In your classification, a plugin and a module are one and the same, just in different words.
From my point of view, this division makes no sense. These are still some dependencies of your cms-based project, they just may not be portable, but developed for a specific project.
And here division on MVC would be quite not bad. Don't forget about console execution.
If I understand correctly, this will turn out to be something like HMVC. If so - you will have to turn inside out, what would be AND flexible AND productive AND supportable.