"Первая система" или "Первый блин комом"

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

В тот момент я делал только первый шаги в web-программировании (по крайней мере, теперь я это отчетливо понимаю, до этого было 7 лет программирования для Windows). Я рассматривал различные фреймверки для ускорения разработки, какие-то казались невероятно сложными, другие были откровенно дубовыми, на счет третьих возникали сомнения в быстродействии. Выбор свой остановил на CodeIgniter.
И начался процесс разработки и одновременно осваивание фреймверка -- граблей нашел много. В тот момент еще не нашел/не заметил русскоязычного сообщества и потому все трудности решал самостоятельно. Путь был тернист, но я его прошел...
Система писалась на удивление легко и быстро.
По сути это было классическое приложение на CodeIgniter со списком контроллеров, моделей, библиотек.

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

Потребовалась библиотека, так называемого, ядра которая фактически собирала все воедино, реализовывала общие методы для всех контроллеров и т.д. Библиотека носила гордое название Kernell. Она занималась установкой/выбором языка системы (для мультиязычных сайтов), заведовала кешем данных (прикрутил кеш из ZF), управляла выводом, меню...

Тогда у меня возникла привычка основную логику запихивать в библиотеки. Т.е. своеобразно модифицировал MVC. Контроллеры разбирались, что именно нужно -- библиотеки делали. Ну... модели и отображение работали как полагается.

В общем, если честно -- организация системы, была ужасной.

Проблемы:

• Всплыла проблема формирования и оформления вложенных, сложных меню... Тогда я уяснил, что меню сайта должно быть отдельным функционалом.
• В движке не было понятия категорий или рубрик -- все документы лежали скопом.
• Фреймверк не совершенен. Я уже тогда модифицировал (путем расширения) ряд библиотек фреймверка. В частности Parser (что изменил), Pagination, Loader, Form_validation, Model -- порылся везде по чуть-чуть..
• Не расширяемость системы без вмешательства в код. Все дело было в нехватке опыта (оглядываясь могу сказать проще -- не знал языка).
• Слабое знание языка + новшество фремверка (для меня) порождали проблемы повторного использования кода. Родилась библиотека ядра, как я уже говорил, которая занималась стандартными вызовами. Таким образом, в каждом контроллере и в каждом методе я делал одни и те же вызовы для инициализации чего-то стандартного для всех типов страниц.
• множественные архитектурные ошибки, которые потом всплыли костылями 

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

Но душа требовала большего и в свободное время началась разработка новой концепции -- минимальное ядро + модули, плагины и т.п.

CMS 1.5 или Не родившееся чудо.

Разработка велась, опять же на базе CI.
Концепция системы заключалась в мифическом ядре которое ничего не умеет кроме как запускать модули, плагины и т.п. примочки формирующие всю систему. Своеобразный конструктор Лего, где ядро выполняло роль связуещего элемента.

Думаю, идея понятна. Ни я первый и не я последний кому пришла в голову эта идея.

Задумывалось ядро в виде библиотеки этого самого ядра и котроллера (куда же без него).
Была придумана API взаимодействия, подключения и событийная модель. Казалось вот-вот можно будет начать штамповать модуля и плагины пачками, но как-то вот не сложилось.

Выбранный подход создал проблему -- каждый модуль/плагин заботился о себе сам. Для модулей и плагинов были свои родительские классы, реализовывавшие рабочий минимум, но не было удобства разработки модулей или плагинов. Т.е. Разработка нового модуля или плагина ставила перед собой довольно много проблем в плане организации самого модуля. Изначально я не предусмотрел, что и для модулей с плагинами очень не повредит применение MVC, как-то не уследил за работой с БД... Т.е. какое-то подобие стандарта прослеживалось, но очень много проблем, которые следовало бы мне предусмотреть изначально, ложились на плечи разработчика самих модулей. Таким образом движек выходил не удобным с точки зрения разработчика расширений.
А хотелось еще иметь микро-ядро для AJAX-запросов... Но вот когда начал его писать, возникла проблема -- нужно все, т.е. получались "те же яйца, но только в профиль".

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

Это как бы воспоминания предыдущих попыток. Чуть позже я постараюсь описать детально трудности, с которыми я столкнулся в тех системах и как их пытался решить.