Сам факт использования названия "постгре" кагбы говорит нам, что Postgres'а ты в глаза не видел, и шансов что под ним CMS будет нормально работать --- маловато. Да, а постгрес придётся, наверное, использовать патченный, чтобы понимал кавычки ``?Автор оригинала: d1gi
обёртка БД сейчас очень маленькая и поверхностная, сам работаю только с мускулом, но сделал пока так, чтобы на будущее можно было перепинать драйверок и под другие БД, как минимум на постгрю... в принципе, чтобы народ не смущало, могу подготовить драйверок к постгре, протестить и выложить уже новый релизик с возможностью работы на pgsql![]()

Правильнее всего --- поработать над проектом ещё год-два, потом приходить.а пишу я тут больше обращаясь к сообществу помочь советом, что и как лучше и правильнее делать, чтобы в будущем проект мог перерасти в что-то интересное
А для начала
а) Выкинуть нахрен код, который никогда не будет использоваться, типа самопального "абстрактного доступа к БД";
бэ) Принять вменяемые стандарты именования, например используемые в PEAR / ZF. Потому что класс NewsAdmin, лежащий в includes/Modules/AdminCP/Modules/News/NewsAdmin.php, наследуемый от класса News, лежащего в includes/Modules/News/News.php и наследуемого от класса Module, лежащего в includes/Engine.php (!!!) --- это п-ц;
в) Писать нормальные phpdoc комментарии;
гэ) Для стандартных задач использовать стандартные компоненты, а не изобретать велосипед. Ты пишешь CMS? Вот и пиши CMS, а не 3950256-ю нахрен никому ненужную библиотеку абстрактного доступа к БД и (запланированные) 145352-й класс записи журнала и 453653-й класс пейджинга. Это же относится к проверке прав доступа --- различных стандартных подходов к таковой проверке весьма немного, выбери один и реализуй (или возьми готовую реализацию).
А так подход в CMS вменяемый, у самого близкий используется.