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

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

У тебя на каждый проект что, админка разная что ли?!

в принципе ДА. 

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

В этом и заключается вопрос.. как мне прийти в однообразию, но при этом не быть "движком-CMS"

Добавлено @ 00:57 
т.е. каковы основы? 

Писать независимыми модулями, т.е. чтоб изменения одного не влияли на другой.

Пишешь пользовательский модуль компонента и административный. Проблем не вижу. Подцепляешь обоих и все.

Грубо... Создаешь папку modules и admin. В них создаешь папки с одинаковыми названиями. В папках - файл index.php и др. файлы необходимые для работы.

Потом в скриптах делаешь include их и так, чтобы модуль не зависел от основного скрипта (никаких общих конфигов и т.д.) - будет проще...

Да и вообще это трудно объяснить, лучше скачать какую-нибудь CMS типа SLAED, Danneo или уже на край PHP-Nuke и посмотри как там устроена модульность.

В общем, сейчас так и пишу ну или пытаюсь писать 

По-твоему на каждый модуль свой конфиг?! Оригинально...

А вообще-то нормально... Согласен что не на все конечно  но на более-меннее самостоятельные, типа рассылка, гостевая и т.п лучше отдельные. Можно гибко и легче рерулировать права. Ну это моё мнение и мне это нравится.. Если честно, подсмотрел такое с Joolma   

Не, ну что касается специфических настроек именно для модуля, то да, я тоже согласен. Ну а глобальные нужно уже глобальными делать 

Ну а что, проще перемешать все в одном месте? В один файл забить параметры кол-ва новостей, типа отправляемых сообщений, маски имен юзеров и т.д.

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

Не вижу проблемы. ООП создавался в тч и для повторного использования кода

Имхо напиши так...

Целиковое ядро (CMS)
и отдельными компонентами этого ядра пусть будут админки всяких мелочей которые будут например инкляйдится и работать в принципе как отдельные классы

Посмтори структуру движка Гуппи, там у них эта проблема как раз разрешена... У них существует скелет сайта который можно дополнять, т.е. копированием файлов в определенные каталоги сайта и их администрирование...